On 09/Mar/10 21:02, Nathan Eady wrote: > Non-resolvable HELO names are *certainly* in straightforward violation of the > clear intent of the RFC: > > # 3.5. OPENING AND CLOSING > # [...citation of RFC 821...]
RFC 5321, which is going to replace that official standard, says more or less the same thing (except using EHLO rather than HELO.) > If<domain> is not resolvable, then the sending host has not identified > itself in any meaningful way. Correct, the client MUST --according to RFC 5321-- give a resolvable FQDN, if possible, or else fall back to an address literal. However, that RFC further specifies that An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis. > 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 [...] That's also the stance of RFC 5451, which defines the Authentication-Results header field that a server taking the responsibility to accept a message would add. The header describes the result of various checks, given in a uniform syntax. Besides SPF and DKIM, it provides for an "iprev" authentication method, described as matching [r]DNS queries, but without going down to the actual implementation details. In the Glorious Future, mail clients will check that header field... ------------------------------------------------------------------------------ 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
