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