On 10/Mar/10 21:09, Nathan Eady wrote: > 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?
A standard only describes common usage. > Besides that, whether to accept mail from any given host is > a matter of site policy. Yes, and the SMTP standard provides for rejecting due to policy reasons. However, reliability concerns call for avoiding that each site has its own incompatible idiosyncrasies. >> [...RFC 5451, which defines the Authentication-Results header field...] >> 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. Agreed. However, rejections based on fuzzy classifications don't improve reliability. A policy has to be worth its name. > 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. You assume the receiving users don't want to know. While in most cases this is true, it doesn't help a collective understanding. Here we're talking about the remote host's name. I think it's fine that a server tells to a message's author to submit via the relevant service --that's what SPF rejection does. However, there is not much sense in asking for a change in the client's name. A spammer by any other name would smell as bad. > 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. A-R header fields potentially provide also for supporting an alternative to filtering: complaining. This used to be the prime action for coping with abuses. Then, spammers proved to be able to change client hosts faster than recipients could complain. Giant mailbox providers reacted by automating abuse reporting: They provide this-is-spam buttons, and possibly forward users' complaints to the originating sites via feedback loops. A-Rs might be used in much the same fashion, as they identify the server responsibe for accepting a message, a MUA might send an automated complaint to it. This server, in turn, might forward complaints via FBLs. (I've been as concise as I can, see http://wiki.asrg.sp.am/wiki/Abuse_Reporting for more.) ------------------------------------------------------------------------------ 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
