Question FormMail.PHP won't send emails

[schemer]

I have tried everything I know (not enough I presume) to fix this issue with my form forwarding script from Tectite (Free) named formmail.php. I do all the tests that are available with the app and they seem to pass but yet no mail gets sent to my email on my IONOS server where I run a Linux VPS. I try to send one email to one of my domains and one to my home email. I played with all the spam settings and nothing seems to help. I have all the ports open that need to be too. Can anyone help point me in the right direction on how to fix this? I can post the 2 test scripts and the php file can be downloaded from:

Free PHP FormMail - Contact Form Processor, Hosted Contact Forms, Form Encryption

FormMail: PHP Contact Form Script. Hosted Contact Form Processing. FormMailEncoder/Decoder: Encryption Software. Secure, anti-spam contact form, free D-I-Y setup or low-cost Wizard.

www.tectite.com

Thanks in advance,
Dave

 

[Bitpalast]

Please check your maillog at /var/log/maillog (CentOS, RedHat) /var/log/mail.log (Debian, Ubuntu) what really happens when you send the mail.

 

[Kaspar]

Like @Peter Debik mentions the maillog of your server is always the best starting point to investigate email issues. Assuming you administer your own server. (If not, contact your administrator of web host support.)

However, before looking at the maillog you might want to check if email from your server is functioning at all. (If you havent checked already). Simply by sending a couple of test emails from a mailbox you've created on your server to an external email account (for example gmail, outlook, ect). If that doesnt work there is probably an issue with the email configuration on your server. If that DOES work try creating a simple PHP script to test sending email. For example this should work:

<?php
$message = "Hello world";
$subject ="PHP test email";
$to = "your-external-email-account@gmail.com";

// Send
$response = mail($to, $subject, $message);
var_dump($response);
?>

If to code above works (i.e you receive the test email) than your server is probably configured correctly to send email, but there is likely something wrongly configured with the formmail.php script.

Looking at your maillog however is the only way to find out what is exactly wrong.

 

[schemer]

Hi and thanks for the replies. I have tried sending me a test mail from my server and I am the admin of my own server here. The mail goes through fine. I will try that php script in a minute but my mail is being rejected and here is part of the log:

Nov 26 12:21:27 eager-pike postfix/smtp[761052]: connect to cxr.mx.a.cloudfilter.net[18.209.118.139]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761051]: connect to cxr.mx.a.cloudfilter.net[18.209.118.139]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761057]: connect to cxr.mx.a.cloudfilter.net[18.209.118.139]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761053]: connect to cxr.mx.a.cloudfilter.net[35.162.106.154]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761057]: connect to cxr.mx.a.cloudfilter.net[34.212.80.54]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761053]: connect to cxr.mx.a.cloudfilter.net[34.212.80.54]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761052]: connect to cxr.mx.a.cloudfilter.net[35.162.106.154]:25: Connection refused
Nov 26 12:21:27 eager-pike postfix/smtp[761053]: A854147A32: to=<myemailaddress@cox.net>, relay=none, delay=256149, delays=256148/0.03/1/0, dsn=4.4.1, status=deferred (connect to cxr.mx.a.cloudfilter.net[34.212.80.54]:25: Connection refused)

 

[schemer]

Like @Peter Debik mentions the maillog of your server is always the best starting point to investigate email issues. Assuming you administer your own server. (If not, contact your administrator of web host support.)

However, before looking at the maillog you might want to check if email from your server is functioning at all. (If you havent checked already). Simply by sending a couple of test emails from a mailbox you've created on your server to an external email account (for example gmail, outlook, ect). If that doesnt work there is probably an issue with the email configuration on your server. If that DOES work try creating a simple PHP script to test sending email. For example this should work:

<?php
$message = "Hello world";
$subject ="PHP test email";
$to = "your-external-email-account@gmail.com";

// Send
$response = mail($to, $subject, $message);
var_dump($response);
?>

If to code above works (i.e you receive the test email) than your server is probably configured correctly to send email, but there is likely something wrongly configured with the formmail.php script.

Looking at your maillog however is the only way to find out what is exactly wrong.

The test shows bool(true) on the webpage when I run it but I get no email.

 

[schemer]

See post above

 

[Bitpalast]

Please check your maillog at /var/log/maillog (CentOS, RedHat) /var/log/mail.log (Debian, Ubuntu) what really happens when you send the mail.

mail.ERR is not the place to look at. You want to look into the regular mail log to see what is logged when you try to send a mail.

 

[schemer]

mail.ERR is not the place to look at. You want to look into the regular mail log to see what is logged when you try to send a mail.

Ok, I will edit that second post but the first one is from the regular mail log.
Thanks

 

[Bitpalast]

The relevant line from the first post is:
Nov 26 12:21:27 eager-pike postfix/smtp[761053]: A854147A32: to=<myemailaddress@cox.net>, relay=none, delay=256149, delays=256148/0.03/1/0, dsn=4.4.1, status=deferred (connect to cxr.mx.a.cloudfilter.net[34.212.80.54]:25: Connection refused)

The server with the ip address 34.212.80.54 does not want to talk to your server. Have you verified that your own server, the sending ip, is not blacklisted?

MultiRBL.valli.org - Blacklist, Whitelist and FCrDNS check tool

Free multiple DNSBL/RBL lookup and FCrDNS check tool. Test the IP (IPv4 or IPv6) of your mailserver on more than 200 blacklists and whitelists.

multirbl.valli.org

 

[schemer]

When I check my domain on that link you posted I get no problems as far as black listing but I get this:

DNSBL Blacklist Test Summary	54 of 54 tests done.
Results	Not listed: 52	Blacklisted: 0	Brownlisted: 0	Yellowlisted: 0	Whitelisted: 0	Neutrallisted: 0	Failed: 2
Processing	All done
DNSBL Combinedlist Test Summary	6 of 6 tests done.
Results	Not listed: 6	Blacklisted: 0	Brownlisted: 0	Yellowlisted: 0	Whitelisted: 0	Neutrallisted: 0	Failed: 0
Processing	All done
DNSBL Whitelist Test Summary	7 of 7 tests done.
Results	Not listed: 7	Blacklisted: 0	Brownlisted: 0	Yellowlisted: 0	Whitelisted: 0	Neutrallisted: 0	Failed: 0
Processing	All done
DNSBL Informationallist Test Summary	1 of 1 tests done.
Results	Not listed: 1	Blacklisted: 0	Brownlisted: 0	Yellowlisted: 0	Whitelisted: 0	Neutrallisted: 0	Failed: 0
Processing	All done

DNSBL Blacklist Test

Failure:

DNS request failed: The name server was unable to process this query due to a problem with the name server.

And now that I did some quick research it looks like being a noob may be the issue as I found my DNS ZONE TEMPLATE with this in it:

	<domain>.		NS	ns1.<domain>.
	<domain>.		NS	ns2.<domain>.

So I guess I have some more learning to do as I assume I have to edit a bunch of stuff in there or at least the name servers.

 

[Bitpalast]

Many recipient servers check DNS and rDNS of the sender. So indeed if the host name is not properly configured or there is no DNS resolution for your sender domain or no reverse DNS resolution, mails won't be accepted at many places.

 

[schemer]

Many recipient servers check DNS and rDNS of the sender. So indeed if the host name is not properly configured or there is no DNS resolution for your sender domain or no reverse DNS resolution, mails won't be accepted at many places.

Well, at least I am getting closer to figuring this out. Where and how do I set these up? I used CPanel before switching over to a new hosting service and Plesk. Is all of this in the Plesk Help Manual?
Thanks

 

[schemer]

Ok, after more reading and research I read where another guy on this forum had a similar situation. He said he ended up fixing it by making sure his domain records in IONOS matched with the records in Plesk. Plesk has a lot of dns record entries whereas IONOS only has about 5. So does it make sense these records have to be equal in both places?
Thanks

 

[Bitpalast]

It depends what nameservers you have entered into your domain at the registrar. When you have entered your own server IP(s) as nameservers at the registrar, then only your own Plesk server servers nameserver requests and there is no need to have your routes registered anywhere else. If you have registered your domains with different nameservers, then these different nameservers do the transation. In that case you do not need to care about any nameserver settings in your Plesk server, because that won't ever resolve anything. In that case you could even deinstall the module.

Here are some tools where you can check what nameservers are set for a domain, how they are responding to domain name resolution requests etc.:

intoDNS: checks DNS and mail servers health

intoDNS checks the health and configuration of DNS and mail servers.

intodns.com

DNSViz | A DNS visualization tool

Free online network tools - traceroute, nslookup, dig, whois lookup, ping - IPv6

Free online network tools, including traceroute, nslookup, dig, whois, ping, and our own Domain Dossier and Email Dossier. Works with IPv6.

centralops.net

 

[schemer]

Thanks Peter, I can use every bit of help I can get. By the looks of it I need to get some GLUE to fix my problems but tell me if I am on the right track. I will add a text file as an attachment as it is easier to read ( it won't allow a txt file). Here is what the first tool listed:

intoDNS

Work in progress!

Follow IntoDNS on Twitter


Category     Status     Test name     Information
send feedback
Parent     Info     Domain NS records     Nameserver records returned by the parent servers are:

ns1041.ui-dns.de.   ['217.160.80.41'] (NO GLUE)   [TTL=172800]
ns1081.ui-dns.org.   ['217.160.83.81'] (NO GLUE)   [TTL=172800]
ns1107.ui-dns.biz.   ['217.160.81.107'] (NO GLUE)   [TTL=172800]
ns1025.ui-dns.com.   ['217.160.82.25']   [TTL=172800]

a.gtld-servers.net was kind enough to give us that information.

Pass     TLD Parent Check     Good. a.gtld-servers.net, the parent server I interrogated, has information for your TLD. This is a good thing as there are some other domain extensions like "co.us" for example that are missing a direct check.
Pass     Your nameservers are listed     Good. The parent server a.gtld-servers.net has your nameservers listed. This is a must if you want to be found as anyone that does not know your DNS servers will first ask the parent nameservers.
Info     DNS Parent sent Glue     The parent nameserver a.gtld-servers.net is not sending out GLUE for every nameservers listed, meaning he is sending out your nameservers host names without sending the A records of those nameservers. It's ok but you have to know that this will require an extra A lookup that can delay a little the connections to your site. This happens a lot if you have nameservers on different TLD (domain.com for example with nameserver ns.domain.org.)
Pass     Nameservers A records     Good. Every nameserver listed has A records. This is a must if you want to be found.
NS     Info     NS records from your nameservers    NS records got from your nameservers listed at the parent NS are:

ns1107.ui-dns.biz  ['217.160.81.107']   [TTL=86400]
ns1025.ui-dns.com  ['217.160.82.25']   [TTL=86400]
ns1081.ui-dns.org  ['217.160.83.81']   [TTL=86400]
ns1041.ui-dns.de  ['217.160.80.41']   [TTL=86400]

Pass     Recursive Queries     Good. Your nameservers (the ones reported by the parent server) do not report that they allow recursive queries for anyone.
Pass     Same Glue     The A records (the GLUE) got from the parent zone check are the same as the ones got from your nameservers. You have to make sure your parent server has the same NS records for your zone as you do according to the RFC. This tests only nameservers that are common at the parent and at your nameservers. If there are any missing or stealth nameservers you should see them below!
Information     Glue for NS records     INFO: GLUE was not sent when I asked your nameservers for your NS records.This is ok but you should know that in this case an extra A record lookup is required in order to get the IPs of your NS records. The nameservers without glue are:
217.160.81.107
217.160.83.81
217.160.80.41
217.160.82.25
You can fix this for example by adding A records to your nameservers for the zones listed above.
Pass     Mismatched NS records     OK. The NS records at all your nameservers are identical.
Pass     DNS servers responded     Good. All nameservers listed at the parent server responded.
Pass     Name of nameservers are valid     OK. All of the NS records that your nameservers report seem valid.
Pass     Multiple Nameservers     Good. You have multiple nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7. Having 2 nameservers is also ok by me.
Pass     Nameservers are lame     OK. All the nameservers listed at the parent servers answer authoritatively for your domain.
Pass     Missing nameservers reported by parent     OK. All NS records are the same at the parent and at your nameservers.
Pass     Missing nameservers reported by your nameservers     OK. All nameservers returned by the parent server a.gtld-servers.net are the same as the ones reported by your nameservers.
Pass     Domain CNAMEs     OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
Pass     NSs CNAME check     OK. RFC1912 2.4 and RFC2181 10.3 state that there should be no CNAMEs if an NS (or any other) record is present.
Pass     Different subnets     OK. Looks like you have nameservers on different subnets!
Pass     IPs of nameservers are public     Ok. Looks like the IP addresses of your nameservers are public. This is a good thing because it will prevent DNS delays and other problems like
Pass     DNS servers allow TCP connection     OK. Seems all your DNS servers allow TCP connections. This is a good thing and useful even if UDP connections are used by default.
Pass     Different autonomous systems     OK. It seems you are safe from a single point of failure. You must be careful about this and try to have nameservers on different locations as it can prevent a lot of problems if one nameserver goes down.
Pass     Stealth NS records sent     Ok. No stealth ns records are sent
SOA     Info     SOA record    The SOA record is:
Primary nameserver: ns1041.ui-dns.de
Hostmaster E-mail address: hostmaster.1und1.com
Serial #: 2017060103
Refresh: 28800
Retry: 7200
Expire: 604800   1 weeks
Default TTL: 600
Pass     NSs have same SOA serial     OK. All your nameservers agree that your SOA serial number is 2017060103.
Pass     SOA MNAME entry     OK. ns1041.ui-dns.de That server is listed at the parent servers.
Pass     SOA Serial     Your SOA serial number is: 2017060103. This appears to be in the recommended format of YYYYMMDDnn.
Pass     SOA REFRESH     OK. Your SOA REFRESH interval is: 28800. That is OK
Pass     SOA RETRY     Your SOA RETRY value is: 7200. Looks ok
Pass     SOA EXPIRE     Your SOA EXPIRE number is: 604800.Looks ok
Pass     SOA MINIMUM TTL     Your SOA MINIMUM TTL is: 600. This value was used to serve as a default TTL for records without a given TTL value and now is used for negative caching (indicates how long a resolver may cache the negative answer). RFC2308 recommends a value of 1-3 hours. Your value of 600 is OK.
MX     Info     MX Records    Your MX records that were reported by your nameservers are:

10   mx00.ionos.com   74.208.5.3 (no glue)
10   mx01.ionos.com   74.208.5.21 (no glue)

[These are all the MX records that I found. If there are some non common MX records at your nameservers you should see them below. ]
Pass     Different MX records at nameservers     Good. Looks like all your nameservers have the same set of MX records. This tests to see if there are any MX records not reported by all your nameservers and also MX records that have the same hostname but different IPs
Pass     MX name validity     Good. I did not detect any invalid hostnames for your MX records.
Pass     MX IPs are public     OK. All of your MX records appear to use public IPs.
Pass     MX CNAME Check     OK. No problems here.
Pass     MX A request returns CNAME     OK. No CNAMEs returned for A records lookups.
Pass     MX is not IP     OK. All of your MX records are host names.
Pass     Number of MX records     Good. Looks like you have multiple MX records at all your nameservers. This is a good thing and will help in preventing loss of mail.
Pass     Mismatched MX A     OK. I did not detect differing IPs for your MX records.
Pass     Duplicate MX A records     OK. I have not found duplicate IP(s) for your MX records. This is a good thing.
Pass     Reverse MX A records (PTR)     Your reverse (PTR) record:
21.5.208.74.in-addr.arpa ->  mx01.perfora.net
3.5.208.74.in-addr.arpa ->  mx00.perfora.net
You have reverse (PTR) records for all your IPs, that is a good thing.
WWW     Info     WWW A Record     Your www.soapcalculator.com A record is:
www.soapcalculator.com  [198.71.56.243]
Pass     IPs are public     OK. All of your WWW IPs appear to be public IPs.
Pass     WWW CNAME     OK. No CNAME

Processed in 0.227 seconds.
© Hosterion - web hosting | VPS hosting by IntoVPS
Made with Python, Django & jQuery

 

[Bitpalast]

Looks good as it is. Do not add glue records. Unnecessary.

The point is now that you see that your Plesk server is not the name server that is registered in the domain data set. Instead, all your routes are configured in
ns1041.ui-dns.de
ns1081.ui-dns.org
ns1107.ui-dns.biz
ns1025.ui-dns.com

So whenever you change something (e.g. IP address) or when you want to point your domain to your server, you need to edit the records in these nameservers. This can normally be done in an interface at your domain provider (where you lease the domains from).

Getting back to your initial post: Look into these nameserver entries what MX and A records are configured and if all are pointing to your server.

 

[schemer]

Looks good as it is. Do not add glue records. Unnecessary.

The point is now that you see that your Plesk server is not the name server that is registered in the domain data set. Instead, all your routes are configured in
ns1041.ui-dns.de
ns1081.ui-dns.org
ns1107.ui-dns.biz
ns1025.ui-dns.com

So whenever you change something (e.g. IP address) or when you want to point your domain to your server, you need to edit the records in these nameservers. This can normally be done in an interface at your domain provider (where you lease the domains from).

Getting back to your initial post: Look into these nameserver entries what MX and A records are configured and if all are pointing to your server.

Thank you for hanging in there with me. I really appreciate it. I will see if I can figure it out as I know where the interface is to see and add the records. If I get confused while I am trying I will surely post my results.
Thanks again,
Dave

 

[schemer]

The mail name servers look properly defined in all the domains according to these instructions on the host:

The MX records in the Domain Name System (DNS) determine the servers responsible for receiving email for a specific domain. From  14 September 2020, there will be country-specific MX servers for the IONOS mail system. The following instructions show you how to check your existing MX records and adapt them if necessary.
Note:

    The DNS settings described here apply to IONOS.com customers. Different settings apply to customers with IONOS contracts in other countries.
    Please note that as of 14 September 2020, receiving emails will only be possible using the correct MX record entries mx00.ionos.com / mx01.ionos.com (alternatively mx00.1and1.com / mx01.1and1.com).

Determine name server

For further verification of your MX records, it is first necessary to determine the name servers in use.

If you use the IONOS name servers, you can make the adjustments in your IONOS account. If you use alternative name servers, you have to change the configuration with the respective provider.

To determine the name servers of your domain proceed as follows:

    Use your Internet browser to access a DNS lookup service, such as dns-lookup.com.
    Enter your domain name in the search field and start the search with Lookup.
    Check the entries in the NS (name server) data section. If they contain the string .ui-dns., you are using the IONOS name servers.

Changing MX entries when using IONOS name servers

If you use the IONOS name servers, change the MX records as follows:

    If you have not yet done so, please log in to your IONOS Customer Account.
    Click on the tile Domain and SSL. An overview of your domains is displayed.
    Expand the gear icon of the desired domain and select the option DNS.
    Expand the gear icon of the first MX record and select Edit Record.
    Change the value in the field Points To into mx00.ionos.com and complete your entry with Save.
    Repeat steps four and five for the second MX record. Adjust the value in the field Points to into mx01.ionos.com. Complete your entry by clicking Save.

Changing MX entries for non-IONOS name servers

If you use the name servers of another provider, the DNS settings are not managed in the IONOS customer account, but with your provider. You must therefore change the MX records with this provider. The exact procedure depends on the provider you are using. Usually you will find a separate section for domain administration or DNS settings in the customer login area of your provider. Use mx00.ionos.com and mx01.ionos.com as MX records.

Below you will find the relevant help pages for a selection of providers:

    Wix: Adding or Updating MX Records in Your Wix Account
    Enom: Add, View, or Edit MX records
    GoDaddy: Change an MX record
    Name.com: Adding an MX Record
    Namecheap: How can I set up MX records required for mail service?

Note:

In special cases, it may take up to 72 hours before your changes will be available globally. For more information, see the article Time Required for DNS Changes.
Did this article help you?
YesNo

But if I try to add a CNAME to match what records the primary domain has in it, it gives and error message saying that can only be added to subdomains. I will add an image with my DNS settings for the main domain and an image of one of the other domains I am having the php script problem with.
Thanks

 

[schemer]

Well, I was thinking...even though I am somewhat a noob at this, I thought "hey! maybe I need to edit my php.ini file" to allow the script to work. So after a long search I found the one for my domain and looked at it in Notepad++ but the first thing I read was "Do Not Edit This File As You Will Lose All Of The Edits The Next Time It Is Autogenerated". That said, do I need to edit some file to allow this script to run? When I look at my server info it shows VHosts as a protected folder and that is where Plesk adds the files when you set up a new website. I can send mail back and forth through the IONOS email server just fine.
Just hard at it trying to figure this thing out.
Thanks

 

[Bitpalast]

Are you sure that mx00.ionos.com can be the correct MX entry? Should that not point to your server instead?