| > | 3. Request: forward adds Resent-* headers.
| >
| > This should be context dependent. If the Sieve filter is run
| by the system
| > administrator, and forwarding is caused for site administrative reasons,
| > then the Resent headers probably should not be inserted.
| >
| > On the other hand, if the Sieve filter is run by a user, causing a
| > forwarding, then the Resent headers should be added.
|
| I don't understand the difference. Typically Sieve scripts are run by
| the system at time of mail delivery, which falls into neither of the
| above cases.
Many ISPs run filters on all incoming mail. Sometimes, forwarding takes
place because of infrastructure changes, system changes, etc., on a
per-domain basis, especially in a managed messaging environment. Resent
headers should not be inserted because of these system-wide, system-imposed
filtering rules.
On the other hand, when a user forwards a piece of mail, unconditionally or
not, Resent often should be added.
As I said, it depends on the context.
I think defining a "Resend" action with the additional semantics of
inserting headers is better than imposing the headers on "forward".
| I believe the right thing to do is to always add Resent headers, despite
| the possible efficiency gains of not doing so. I believe the benefit of
| trace informaton outweighs the benefits of efficiency gains, especially
| given that forward is going to cause mail loop headaches.
I view Resent- headers as informational only. Tracing should rely on
Received headers, not Resent headers.
--
Alan K. Stebbens <alan(_dot_)stebbens(_at_)software(_dot_)com>