Hi; I have an email form that worked fine until now. For some reason, if I send an email to an email address at a domain that I control, I can receive the email TTW no problem. However, if I try and push it to, for example, this gmail account, I never get it. It's not even in the spam filter. What could this be? TIA, Susan
Susan Day sent a missive on 2010-05-21:
Hi; I have an email form that worked fine until now. For some reason, if I send an email to an email address at a domain that I control, I can receive the email TTW no problem. However, if I try and push it to, for example, this gmail account, I never get it. It's not even in the spam filter. What could this be? TIA, Susan
You should check the logs on the sending mail server and also do a tcpdump of the conversation between the mail server and google. You'll find out what the problem is that way.
Rgds Simon
Susan,
Susan wrote:
I have an email form that worked fine until now. For some reason, if I send an email to an email address at a domain that I control, I can receive the email TTW no problem. However, if I try and push it to, for example, this gmail account, I never get it. It's not even in the spam filter. What could this be?
Sounds like your MTA isn't getting out to the 'Net. Could a firewall rule have been changed somewhere?
mark
On Fri, May 21, 2010 at 11:13 AM, m.roth@5-cent.us wrote:
I have an email form that worked fine until now. For some reason, if I send an email to an email address at a domain that I control, I can receive the email TTW no problem. However, if I try and push it to, for example, this gmail account, I never get it. It's not even in the spam filter. What could this be?
Sounds like your MTA isn't getting out to the 'Net. Could a firewall rule have been changed somewhere?
Which MTA are you using? sendmail, postfix, ...
If it is sendmail and if you had manually edited sendmail.cf, there is some good chance that the customization was wiped clean by the latest sendmail update. I saw this behavior -- there was no .rpmnew or org file created by sendmail. Of course, one is not supposed to manually edit the .cf file. Still, this is not the way sendmail used to update the conf file.
Akemi
Do you know that it's going out with valid headers, a "legal" helo address, and the like? Many mail systems will use these as reasons to reject connections when they're wrong. In the case of bad helo values, often it won't get as far as the spam filter, since that's sent through before the message.
If stuff worked before but now doesn't, another question is whether your sending IP is in a range recently blacklisted, if your ISP has been hosting spammers.
Whit
On Fri, May 21, 2010 at 02:03:04PM -0400, Susan Day wrote:
Hi; I have an email form that worked fine until now. For some reason, if I send an email to an email address at a domain that I control, I can receive the email TTW no problem. However, if I try and push it to, for example, this gmail account, I never get it. It's not even in the spam filter. What could this be? TIA, Susan
Do you know that it's going out with valid headers, a "legal" helo address, and the like? Many mail systems will use these as reasons to reject connections when they're wrong. In the case of bad helo values, often it won't get as far as the spam filter, since that's sent through before the message.
If stuff worked before but now doesn't, another question is whether your sending IP is in a range recently blacklisted, if your ISP has been hosting spammers.
Yeah, that's another possibility. I *REALLY* DISLIKE this blacklist attitude of "oh, well, that's out of this DNS host, so we'll block *all* of their emails, from all the domains they host".
Do try to telnet to port 25 for google mail, and see if it'll talk to you, or if you can get through at all.
mark
Replies to all replies:
Richard asks:
is the "domain you control" on the same machine as the form submission site?
Yes.
was this machine recently upgraded to 5.5? [the 5.5 upgrade included sendmail and as a result could have had an impact on your sendmail.cf (depending on what your sendmail.mc looked like).]
No.
In general, the place to start is the maillog on the site with the form.
Here are what the logs have to say:
@400000004bf6cfc4383bc65c delivery 6217: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6cfc4383c5eb4 status: local 0/10 remote 0/255 @400000004bf6d51e34d61d8c starting delivery 6218: msg 97881531 to remote suzieprogrammer@gmail.com @400000004bf6d51e34d6449c status: local 0/10 remote 1/255 @400000004bf6d51e37303e14 starting delivery 6219: msg 97881555 to remote suzieprogrammer@gmail.com @400000004bf6d51e373078ac status: local 0/10 remote 2/255 @400000004bf6d51e373143cc delivery 6218: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6d51e373241b4 status: local 0/10 remote 1/255 @400000004bf6d51e37807d0c delivery 6219: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6d51e3780bf74 status: local 0/10 remote 0/255
Mark asks:
Sounds like your MTA isn't getting out to the 'Net. Could a firewall rule have been changed somewhere?
No. I've been able to get email to the account I control through the same firewall.
Do try to telnet to port 25 for google mail, and see if it'll talk to you, or if you can get through at all.
I've never been able to successfully do that, but the same form gets the email to the address I control.
Whit asks:
Do you know that it's going out with valid headers, a "legal" helo
address,
and the like? Many mail systems will use these as reasons to reject connections when they're wrong. In the case of bad helo values, often it won't get as far as the spam filter, since that's sent through before the message.
Yes. It goes through qmail, and everything worked before.
If stuff worked before but now doesn't, another question is whether your sending IP is in a range recently blacklisted, if your ISP has been
hosting
spammers.
I checked the blacklists and all looks well.
Akemi asks:
Which MTA are you using? sendmail, postfix, ...
qmail
Mr. Gabriel asks:
Also, do you use srv records? Has anything here changed?
Don't use srv
TIA, Susan
Susan Day sent a missive on 2010-05-21:
Here are what the logs have to say:
@400000004bf6cfc4383bc65c delivery 6217: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6cfc4383c5eb4 status: local 0/10 remote 0/255 @400000004bf6d51e34d61d8c starting delivery 6218: msg 97881531 to remote suzieprogrammer@gmail.com @400000004bf6d51e34d6449c status: local 0/10 remote 1/255 @400000004bf6d51e37303e14 starting delivery 6219: msg 97881555 to remote suzieprogrammer@gmail.com @400000004bf6d51e373078ac status: local 0/10 remote 2/255 @400000004bf6d51e373143cc delivery 6218: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6d51e373241b4 status: local 0/10 remote 1/255 @400000004bf6d51e37807d0c delivery 6219: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6d51e3780bf74 status: local 0/10 remote 0/255
Extract from: http://nixforums.org/about25455-Help-Diagnosing-CNAME_lookup_failed_temporar ily.html
"The likely cause of this is qmail's inability to handle large DNS packets. The most-recommended solution is to install dnscache (from djbdns), which trims off some unnecessary data and usually makes these packets small enough for qmail to handle. The more correct solution is to apply the "oversize DNS packets" patch to qmail (see qmail.org). A hackish-but-fast solution is to choose one of Earthlink's MXs, and put it in your smtproutes file. Not good long-term, but it will get the mail out of your queue while you work on a better solution."
I wouldn't put earthlinks mx in your smtproutes but you could put in you isp's if you wanted to as a quick and dirty fix.
HTH
Simon.
Simon Billis sent a missive on 2010-05-21:
Just to correct something I wrote:
Susan Day sent a missive on 2010-05-21:
Here are what the logs have to say:
@400000004bf6cfc4383bc65c delivery 6217: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6cfc4383c5eb4 status: local 0/10 remote 0/255 @400000004bf6d51e34d61d8c starting delivery 6218: msg 97881531 to remote suzieprogrammer@gmail.com @400000004bf6d51e34d6449c status: local 0/10 remote 1/255 @400000004bf6d51e37303e14 starting delivery 6219: msg 97881555 to remote suzieprogrammer@gmail.com @400000004bf6d51e373078ac status: local 0/10 remote 2/255 @400000004bf6d51e373143cc delivery 6218: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6d51e373241b4 status: local 0/10 remote 1/255 @400000004bf6d51e37807d0c delivery 6219: deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/ @400000004bf6d51e3780bf74 status: local 0/10 remote 0/255
Extract from: http://nixforums.org/about25455-Help-Diagnosing- CNAME_lookup_failed_temporar ily.html
"The likely cause of this is qmail's inability to handle large DNS packets. The most-recommended solution is to install dnscache (from djbdns), which trims off some unnecessary data and usually makes these packets small enough for qmail to handle. The more correct solution is to apply the "oversize DNS packets" patch to qmail (see qmail.org). A hackish-but-fast solution is to choose one of Earthlink's MXs, and put it in your smtproutes file. Not good long-term, but it will get the mail out of your queue while you work on a better solution."
I wouldn't put earthlinks mx in your smtproutes but you could put in you isp's if you wanted to as a quick and dirty fix.
It's been a long day, I'd not do the smtproutes but instead patch qmail or install the djb dnscache - the issue is caused by large udp (I think) packets being returned by the dns to qmail. I think that you could also use a smart smtp host instead of sending the mail out directly (if you have access to an smtp host that is working).
HTH
Simon.
With regard to Richard's comments, I will get in touch with my server farm (or garden, small company) that handles the same.
Regarding Simon's comments, these DNS packets have got to be teeny tiny. This is plain text and very little of that. Your response was full of terms I didn't understand and of course can look up and will if necessary, but I think you're seeing a size that isn't merited. I'll await your response before proceeding. TIA, Susan
Susan Day wrote:
With regard to Richard's comments, I will get in touch with my server farm (or garden, small company) that handles the same.
Regarding Simon's comments, these DNS packets have got to be teeny tiny. This is plain text and very little of that. Your response was full of terms I didn't understand and of course can look up and will if necessary, but I think you're seeing a size that isn't merited. I'll await your response before proceeding. TIA, Susan
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi Susan,
The records that Richard was talking about was not that of your actual mail, but the Domain Name Service (DNS) records required to find the destination server and for that server to look up your server to verify that the mail comes from a valid address. I recall a discussion earlier this month about the root DNS servers being updated to a new version of DNS software that would increase the size of the DNS records. This would then take a while to filter through the "tree" of DNS servers and eventually software that could not handle these larger records would fail.
I hope that this sheds some light.
ChrisG
On Sat, May 22, 2010 at 6:42 AM, Chris Geldenhuis chris.gelden@iafrica.com wrote:
The records that Richard was talking about was not that of your actual mail, but the Domain Name Service (DNS) records required to find the destination server and for that server to look up your server to verify that the mail comes from a valid address.
Right so far ...
I recall a discussion earlier this month about the root DNS servers being updated to a new version of DNS software that would increase the size of the DNS records. This would then take a while to filter through the "tree" of DNS servers and eventually software that could not handle these larger records would fail.
You're thinking of the DNSSEC changes to add security information to the packets. That should only affect software that actually asks for DNSSEC packets, which presumably excludes any software that isn't prepared to handle those responses.
I'm not familiar with the qmail bug that was previously mentioned, but from the description it appears to be related to CNAME records, not to DNSSEC.
On Sat, May 22, 2010 at 1:02 PM, Bart Schaefer barton.schaefer@gmail.comwrote:
On Sat, May 22, 2010 at 6:42 AM, Chris Geldenhuis chris.gelden@iafrica.com wrote:
The records that Richard was talking about was not that of your actual mail, but the Domain Name Service (DNS) records required to find the destination server and for that server to look up your server to verify that the mail comes from a valid address.
Right so far ...
I recall a discussion earlier this month about the root DNS servers being updated to a new version of DNS software that would increase the size of the DNS records. This would then take a while to filter through the "tree" of DNS servers and eventually software that could not handle these larger records would
fail.
You're thinking of the DNSSEC changes to add security information to the packets. That should only affect software that actually asks for DNSSEC packets, which presumably excludes any software that isn't prepared to handle those responses.
I'm not familiar with the qmail bug that was previously mentioned, but from the description it appears to be related to CNAME records, not to DNSSEC.
Oops.Forgot to clean this up. The problem was that named shut down and I
didn't catch it. Susan
-
Akemi Yagi -
Bart Schaefer -
Chris Geldenhuis -
m.roth＠5-cent.us -
Simon Billis -
Susan Day -
Whit Blauvelt