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?
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.
As your implementation has an option to control this, I would like to
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.
> 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.
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.
>> 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.
Which matters because ... ?
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve