--On Thursday, January 19, 2017 21:07 +0900 Christian Balzer <[email protected]> wrote:
> > Hello, > > On Thu, 19 Jan 2017 06:30:24 -0500 John C Klensin wrote: > > [snip] >> >> There are also some complex questions as to whether a server >> is ever permitted to refuse to accept mail with a >> backward-pointing address of "<>". Unless tied to either the >> identifying information in EHLO/HELO or the client's IP >> address, it would imply that the server never accepts bounce >> messages or MDNs of any sort. I have probably missed some >> cases, but think that would be a terrible practice and would >> certainly violate assorted assumptions of SMTP. >> > You're missing for example this: > http://slett.net/spam-filtering-for-mx/exim-sign.html > > Which is something we use/offer here. > > And the client IP address (RBL, locally listed) is another > factor. Sigh. See below. > RCPT TO might be ineffective, but I don't see me exposing > VRFY/EXPN ever. I have tried to be careful to explain what the standard says and to indicate that which of these things to enable is a local option (something else the standard says, in different words). I do encourage implementations to make those decisions matters of local configuration rather than believing that one size fits all; Exim has always done well on that dimension. I have defended and will continue to defend the right (perhaps even obligation) of a site to defend itself against attacks and to define what it interprets as an attack. The "rational operational behavior" language in RFC 5321 (See Section 7.5 in particular) is not a accident. However, in our enthusiasm for fighting spam, I think we often forget a very fundamental assumption of Internet email and its predecessors, which is that it is a "deliver or notify" service, not "a deliver if you can and otherwise quietly drop" or something else equivalent to an unreliable but reasonable best efforts service. It could have been designed the latter way, but it wasn't and none of the efforts to make that transition have gotten any traction. The text in SMTP about handoff of responsibility for messages and not quietly dropping either messages or MDNs are not accidents either. You will have to decide (and obviously have) whether the risk of losing many, perhaps most, legitimate non-delivery messages from sites that don't even know your rules about them is a good idea. My opinion on that isn't worth much -- I don't know your circumstances or your users and have no particular authority in that matter to which you should pay attention. I'd just urge you to think about the tradeoffs. One other observation and then I'm going to drop out of this thread. It would be perfectly reasonable to propose defining and standardizing SMTP extensions that announce "if a message sent to this site is undeliverable, it will be discarded" and/or "if an NDN or MDN (or anything else with a null address) is sent here and is not signed in such-and-such a way, it will be quietly discarded". That would give a would-be sending system the ability to decide whether to accept your conditions and entrust mail traffic to you, to ask for delivery receipts if you offer that option, or to advise its users about the risks. If there were particularly careful and sophisticated spammers out there, it might give them notice to leave you alone (although the number of those is probably small enough to make that not a major consideration). However, to my knowledge, no one has proposed either extension, leaving senders guessing as to whether you will deliver messages and why you might not. That is actually another reason to support VRFY, one that I failed to mention on my earlier notes. Precisely because it does not require setting up a mail session, it is easy and rational for a user (or MUA) that is worried about non-deliverability to open a telnet connection to the relevant port and send a VRFY command to see if a particular mailbox exists and to which messages will is delivered. If the answer is "no", then maybe the origination user should try something else, like the post or smoke signals. Or course, if you decide to not support VRFY, or to require a mail session, that option disappears. Only you and that hypothetical sender can decide how you feel about the tradeoffs. best, john -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
