[Sending a notification to an address that generates a bounce]
(1) Require that when the envelope from on the triggering message is blank
that the message be checked to see if it is a DSN/MDN and if it is look
at the third part to see if it contains an auto-submitted header.
I'm afraid that's something for an ideal world.
(2) Use the same trick we required on redirect: When the triggering message
contains an empty envelope from require that any notifications it
generates
also have an empty envelope from.
I mention (1) only because of its cuteness - IMO it isn't going to be reliable
enough, if for no other reason than the widespread existance of DSNs and MDNs
using nonstandard formats. (Thank you qmail...) That leaves (2). I don't like
it much but I don't see any real alternative.
Indeed.
2). Something I remember from a previous conversation with you: are you
happy with the requirement on the Notify action to preserve Received
headers from the original message?
No I'm not. As currently defined it's quite simply wrong to do this. The
original message is what garnered those trace field values, not the
notification. Someone attempting to trace the message path using this
information could easily end up being very confused.
Personally, I would be more confused on not having "Received:" from the
triggering message, but that may just be me.
It is also bound to trip
any loop detection logic that has been set to fairly tight tolerances. And
there's also the spam filter issue - one check I've seen made is to compare
the
dates on the Received: fields with the Date: field. A Date: field that's in
the
future relative to the first Received: field could raise flags and cause
problems. (Mind you, I don't see a reason to cater to broken filter criteria
but that's not sufficient justification for ignoring the issue completely.)
I never thought of the date issue, and although I don't use a check like
that, "Date:" being in the future looks really ugly to me.
Unfortunately there are no really good ways to solve this problem. I see the
following possibilities:
(1) Rely on auto-submitted being preserved as a loop check and don't do the
Received: line copy at all.
I am less afraid of trouble in the real world, but if that choice is
going to cause trouble with approval, it isn't one.
(2) Classify the Auto-submitted: field as a trace field and require that it
appear above the copied Received: fields as a sort of boundary between
the old set of Received: fields and the new.
(3) Same as (2) except make the trace field some newly defined thing.
Depending on the order of different fields relative to each other
sounds like asking for real trouble to me.
(4) Same as (2) except use a specially formatted Received: field as the
boundary.
I never saw "Received:" being reordered. It's ugly, but anything apart
from (1) is, and to me it sounds best among all options.
(5) Make the Received: line copy a SHOULD rather than a MUST. Add some
discussion that the separation between old and new Receieved: fields
can usually be determined by comparing the dates with the those on the
Date:
field.
(6) Add the discussion mentioned in (5) but ignore the problem otherwise.
It is bad enough "Date:" is sometimes being "fixed" or accepted although
being wrong. Knowing that and trying to assign relevance to it is not
an option to me.
Notifications are really a new kind of message, an odd mix somewhere
between redirected and vacation messages, so all this is not just relevant
to Sieve. I consider it important to reach a consensus, no matter how
much work it may still take, because anything we screw up now probably
can't be fixed later.
Thanks a lot for your review!
Michael