The usage for ENVID that we are considering would break rules specified
in RFC 1891:
(a) Any ENVID parameter included in the MAIL command when a message was
received, MUST also appear on the MAIL command with which the
message is relayed, with the same associated esmtp-value. If no
ENVID parameter was included in the MAIL command when the message
was received, the ENVID parameter MUST NOT be supplied when the
message is relayed.
Relays should be adding ENVID parameters, though they MUST NOT.
In multihop forwards, we would be replacing, not preserving the ENVID.
Careful consideration of the consequences is needed before we break
these rules!
If the message has a new envelope then it's a new message. Even if it has
the same *body* as another message. So we're not really relaying when we do
this kind of forwarding - we're injecting a *new* message into the MTS. So
why not create an ENVID?
Consider mail forwarding for some hosting clients. Their MXs point to one
of our machines which just has a bunch of aliases to shove the mail on to
whatever their "real email" is. So mail to
info(_at_)client(_dot_)example(_dot_)com comes to
us. Then, in the aliasing, a *new* message for
localpart(_at_)clients(_dot_)isp(_dot_)example(_dot_)net is generated.
That is to say, mail to info(_at_)client(_dot_)example(_dot_)com is addressed
to an entity
which is responsible for generating new messages actually to the client -
it's not relaying as such, because the envelope is new.
--
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg