--On Thursday, January 19, 2017 21:07 +0900 Christian Balzer
<chibi@???> 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
