

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
6 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: 417 SPF error...| From | Sent On | Attachments |
|---|---|---|
| Jerry Amundson | Mar 30, 2006 7:40 am | |
| Bill Taroli | Mar 30, 2006 11:17 am | |
| Jerry Amundson | Mar 30, 2006 1:11 pm | |
| Bill Taroli | Mar 30, 2006 1:51 pm | |
| Dave Platt | Mar 30, 2006 2:34 pm | |
| Sam Varshavchik | Mar 30, 2006 3:20 pm |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [courier-users] Re: 417 SPF error user@cogeco.ca: DNS MX lookupfailed.? | Actions... |
|---|---|---|
| From: | Dave Platt (dpl...@radagast.org) | |
| Date: | Mar 30, 2006 2:34:44 pm | |
| List: | net.sourceforge.lists.courier-users | |
Personally, I have found BOFHCHECKHELO causes too many delivery problems for me. It got to be an increasingly full time job to monitor log reports, add manual exceptions to the rule, and follow up with admins who couldn't apparently figure out how to get their MTA's and DNS'es to agree... and some of these weren't small (like Yahoo). In the end, I left this check turned off and let my other filters catch mail.
I had the same experience.
The biggest single culprit seems to be a technically-illegal hack that many sites (including Yahoo, which means SBC/PacBell) are now using. These sites have outbound-mail-relay hosts which are used (directly or indirectly) by their registered customers, but which never originate email themselves. That is, there's never any legitimate email with (e.g.) anyt...@relayhost.domain.com in its envelope or header address.
Such systems seem, increasingly, to have a deliberately-invalid MX record - most commonly, one of "0." (zero). This causes any attempt to mail to "anyt...@relayhost.domain.com" to fail quite rapidly, without ever opening an SMTP connection to relayhost.domain.com (and I suspect that's the point).
Because the MX record is deliberately mangled, Courier's esmtp daemon rejects connections from such hosts if BOFHCHECKHELO is enabled.
I'm not sure what the "right" solution to this is. As far as I know, these hosts *are* breaking the RFCs for what an MX record is supposed to hold, since there's no legitimate host named Zero (reminds me a bit of an old Rocky & Bullwinkle sequence set in Mucho Loma). And, because the DNS-validity check in esmtpd is performed prior to any of the site's own filter scripts running, there's no simple way to override this one test. I found BOFHCHECKHELO blocking too many legitimate emails, from sites such as Yahoo which are so big that I have no hope that they'd be willing to change ther behavior to comply with the RFCs unless they see it in their own short-term best interest :-(
I miss BOFHCHECKHELO, as it's a great way of blocking a fair percentage of spam - a lot of spamware identifies as "localhost" or "friend" or my system's own IP address or a big negative integer. However, in the end, I couldn't use it due to the rate of blocking of email that I wanted.
I added the localhost/friend/numeric-address checks to my sitewide rcptfilter, and they work just fine there.
Perhaps the BOFHCHECKHELO filter tests might be made a bit more user-selectable, so that (e.g.) hosts with a legitimate A record but a mangled MX record could be allowed to pass?







