Subject: [sieve] Sieve reject and Disposition-Notification-To header field

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Aug 2010 11:42:11 +0200

I got a private question about whether Disposition-Notification-To 
header field should be honoured when generating MDNs with "reject". 
Should it be ignored?

---

From: [email-masked]
Date: Wed, 04 Aug 2010 08:05:17 -0700 (PDT)

> header field should be honoured when generating MDNs with "reject".

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?

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 06 Aug 2010 12:16:40 +0200

> resson why we shouldn't be honoring it for these MDNs?
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>.

---

From: [email-masked]
Date: Fri, 06 Aug 2010 07:23:16 -0700 (PDT)

> > 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.

OTOH, this behavior has always been an intentional difference between DSNs and
MDNs.

> 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:?

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.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 09 Aug 2010 09:24:06 +0100

> with an MDN will send the response to the disposition-notification-to 

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 

Yes, but I don't think this argument applies in this case, as reject is 
[mis]using MDNs for a very specific purpose.

> /*How is this any different than "sender A sends a spam message to 
> user B and
> */

Right.
However I am not convinced that handling of 2 cases in antispam engines 
is going to be identical.

> ressonable. Reject, not so much.

Agreed.

---

From: [email-masked]
Date: Mon, 09 Aug 2010 08:56:21 -0700 (PDT)

> benefits of sending MDN rejections to disposition-notification-to address?

The obvious benefit is that you're sending the MDN to the place the message
originator said MDNs should be sent to. The associated use-case would be
something like a sender having a special address they use for MDN processing.

> hear some motivation for having it.

Not exactly. It's a parameter on an internal API - when a particular sort of 
report is generated (which includes but is not limited to MDNs) there's a bit
that specifies whether or not to look at disposition-notification-to. The case
where we don't look at the header is for Sieve notify, which isn't an MDN case.

> [mis]using MDNs for a very specific purpose.

The problem here is fundamental - there are a range of places, starting with
just before final delivery and continuing through pretty much any store
operations, where sieve can be used. The earlier in the pipe the more message
rejection should be using SMTP-level or DSN notifications. But additionally,
the futher you get from final delivery, the more appropriate MDNs, with all
their semantics, become.

So, while it arguably a misuse of MDNs to generate them before final delivery,
it is also a misuse (and this one's inarugable, I'm afraid) to use DSNs long
after final delivery has taken place.

> is going to be identical.

Which matters because ... ?

				Ned