Ned Freed wrote:
Ned Freed wrote:
>> I got a private question about whether Disposition-Notification-To
>> header field should be honoured when generating MDNs with "reject".
>> Should it be ignored?
> We honor it in this case. It would be trivial to switch it off, but is
> there a
> resson why we shouldn't be honoring it for these MDNs?
Having thought about it some more, the only reason I can come up with
to change
this is consistency: A reject that's handled at SMTP time is effectively
sending a DSN response to the MAIL FROM address, whereas one that's
handled
with an MDN will send the response to the disposition-notification-to
address.
Yes.
I would also like to ask the question in a different way: what are the
benefits of sending MDN rejections to disposition-notification-to address?
As your implementation has an option to control this, I would like to
hear some motivation for having it.
OTOH, this behavior has always been an intentional difference between
DSNs and
MDNs.
Yes, but I don't think this argument applies in this case, as reject is
[mis]using MDNs for a very specific purpose.
I am concerned about spamming third parties with rejection notices, i.e.
if the sender A sends a spam message to user B and specifies
Disposition-Notification-To: <userC>.
/*How is this any different than "sender A sends a spam message to
user B and
specifies MAIL FROM:<userC>" - a case which, I can assure you, is a
lot more
common than spammers bothering with inserting
Disposition-Notification-To:?
*/
Right.
However I am not convinced that handling of 2 cases in antispam engines
is going to be identical.
This group tried to make reject as safe as possible to use in a
spam-filed
environment. However, there's a difference between making reject "mostly
harmless" so that accidental application of it to spam is less likely
to result
in blowback, and making reject a reasonable tool to use to actualy
handle known
or suspected spam. The latter was, given the semantics of email and the
compatibility requirements placed on reject, a goal that was simply
impossible
to achieve, and changing it so Disposition-Notification-To: isn't
used isn't
going to help in any appreciable way.
Which brings us to ereject, which avoids the MDN destination issue
since it
uses DSNs. Ereject is an attempt to do a reject type of action that
_can_ be
used to handle spam. But even though we pushed it to the limit, there are
unavoidable cases where an ereject will result in DSN generation. So
it still
isn't completely safe, but as long as the ereject is done on the initial
ingress MTA, ereject, unlike reject, is a legitimate tool for handling
known
spam.
Ned
P.S. My personal belief is that criticisms of silently dropping email
notwithstanding, the Sieve tools of choice for dealing with spam are
either
fileinto "spamfolder" or discard. But as I say, use of ereject is also
ressonable. Reject, not so much.
Agreed.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve