Alessandro Vesely <[email protected]> writes: > 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.
Eh? What's the point of having a standard if you aren't allowed to refuse to support things that don't comply with it? Do we also have to accept messages with multi-thousand-character header lines? No. We should try to be liberal in what we accept when we can, but when a particular violation of the standard creates too many problems, we tell the other host to go jump in a lake (and then they either fix their implementation to comply with the standard, or they communicate only with a subset of the internet, their choice). In the case of email, not being able to check the identity of the sending host can be a fairly significant source of problems. Besides that, whether to accept mail from any given host is a matter of site policy. The role of the RFC is to provide the communication framework so that everyone is speaking the same language, so that when the receiving server says "Yes, we will deliver that message for you" or "No, we won't deliver that" or "Not now maybe later", the sending server can understand the response and know things like whether it should try again, notify the user of a failure, or consider the message delivered. Deciding who we should accept mail from is most definitely NOT the role of the RFC. That's between me, my users, and the people we want to communicate with by email. If we want to only accept mail from specific whitelisted hosts, that's our business. >> in the Glorious Future when the software does everything... > > 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... I'm not totally in full agreement with that, either. If the message is going to be rejected, it should be rejected as early as possible. If a message can be rejected before the DATA stage, it should be. Even if it goes to the DATA phase, if you then know that the user isn't going to be looking at the message, it should be rejected as soon as you know this. Among other things, issuing an error response during the SMTP session allows the sending mail server to immediately notify the user that the message was not delivered. In the event that a real user was actually trying to send the message, this is something they want to know. (Third-party bounce messages are no longer worth anyone's time to read these days because five nines of them are spam, but when your own mail server tells you that a message you tried to send couldn't go out, that's different.) I'm not saying such a header can't be useful. It can, obviously. Sometimes the same mail server has to support both users who get a trainload of spam and want as many ways to reduce the flood as possible, and also users who are paranoid that they might miss an important message. And it isn't always practical to let the users install policies on the server. ISPs for home users are a good example here. In such cases, a header can be useful, as it allows individual users to be more strict in what they'll read than the server can be in what it'll accept. Sure. But not all mail servers are in that situation. -- 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
