Re: [Asrg] 6. Proposals: LMAP - Forwarding Comment and Recommended Changes

["Jon Kyme" <jrk@merseymail.com>]

> 
> 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@client.example.com comes to
us. Then, in the aliasing, a *new* message for
localpart@clients.isp.example.net is generated.
That is to say, mail to info@client.example.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@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg