Steve Shockley <[email protected]> writes: > On 3/3/2010 4:28 PM, Nathan Eady wrote: >> * non resolvable HELO names are blocked > >> * HELO names that don't share at least the top couple of >> levels with the actual FQDN are blocked (so, for instance, > > Just as a curiosity, are either of these violations of RFC?
Non-resolvable HELO names are *certainly* in straightforward violation of the clear intent of the RFC: # 3.5. OPENING AND CLOSING # # At the time the transmission channel is opened there is an # exchange to ensure that the hosts are communicating with the hosts # they think they are. # # The following two commands are used in transmission channel # opening and closing: # # HELO <SP> <domain> <CRLF> # # QUIT <CRLF> # # In the HELO command the host sending the command identifies # itself; the command may be interpreted as saying "Hello, I am # <domain>". If <domain> is not resolvable, then the sending host has not identified itself in any meaningful way. Additionally, a non-resolvable name does not in any way help to ensure that the receiving host is communicating with the host it thinks it is. The case for names that mismatch on reverse-lookup is more arguable, which is one of several reasons it ought to be possible to turn on one of the checks and not the other. > My work outbound servers (not Courier) send HELO as > internalservername.example.com, but rdns for the extenal address > would be mxo1.example.com (which does resolve to the same IP). Well, that matches at example.com, which is two levels. So you would pass the proposed less-drastic checks, even though you would fail the somewhat more rigorous check that occurs if BOFHCHECKHELO=1 I think a lot of mail servers are in this boat, which is why I think the less extreme checks would be more useful in practice than the current all-or-nothing check. > By the same token, we have multiple domains, so the server might > resolve as mxo1.example.com, HELO as internal.example.com, and > deliver a message for [email protected], where domain.com lists > mxo1.example.com among its MX records. Yeah. Ultimately, what I would really want, in the Glorious Future when the software does everything I can imagine it should do, is to have a collection of checks, score each message based on how many of them it passes, and use its score to decide whether to reject outright, accept outright, or graylist. So then passing the "sender is an MX for that domain" check would be worth something and help offset the "HELO domain doesn't match From domain" check. Depending on the other properties of the message and how paranoid the receiving mail server's admin is, passing the MX check might get your message accepted immediately, or it might only mean a shorter greylist delay. But that's more ambitious than what I was talking about above. -- Nathan Eady Galion Public Library ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
