ietf-mxcomp
[Top] [All Lists]

RE: towards a compromise

2004-04-21 10:56:35

My concern with this specific point is that the sender really 
has no way 
of knowing what the receiver is going to do with the information. 
Therefore, in order for the sender's mail to go through, the 
sender has 
to make sure that both 2821 and 2822 identities are valid 
which imposes 
higher costs on the sender. For example, a forwarding service 
may only 
be interested in setting the 2821 identity correctly but 
ignore the 2822.

The sender has no control over what the receiver does with the
information, and neither does this group.

The only real corner case sender for either the 2821 or 2822 
cases seems to be the forwarder. Mailing list and Postcard sites
both work fine setting Sender. [I think that it would be fine
for Cagle cartoons to say 'From Cagle on behalf of Phill']

The identity that the forwarders seem to have most difficulty
setting 'correctly' seems to be the 2821 From, that then requires
them to store state to correctly route bounces.

I think we should work on the forwarding case and work out a
comprehensive solution for that one case since it seems to 
be the corner case each time. It may be complex technically,
but it is pretty simple from a deployment standpoint since
there are very few forwarders to deal with [.forward is a
somewhat different problem].


I don't think it would be unreasonable to require MARID 
receivers to check for a forwarding relationship before
issuing fail on either 2821 or 2822 from.

Proof of sender is pretty easy to implement.

                Phill