Jim Fenton wrote:
I'd like to explain the basis for what's currently in the draft.
[...]
Thanks. I try to explain my issues with this approach: When
the former MARID WG tried to "unify" SPF and "CallerID" (an
XML-over-DNS predecessor of SenderID/PRA) some folks strongly
objected, because a non-empty envelope sender address isn't
guaranteed to be the same as the PRA.
E.g. not all MSAs implement option 8.1 in RFC 4409, and even
if they do it's far from clear if they get it right for mails
with Resent-* header fields. There are other corner cases,
simple implementations of moderated newsgroups etc., where a
PRA cannot work as expected.
Nevertheless PRA is the best best possible solution after the
dubious decision to ignore the envelope sender address. In
years of discussions on the "SPF discuss" list all attempts
to outsmart PRA with other ideas failed miserably, and of
course "2822-From" was one of those ideas.
Likewise all attempts to remove Resent-* from the picture in
2822upd on the rfc822 list failed miserably. In other words
we are either stuck with PRA, or we try Dave's proposal to
ignore Resent-* anyway (arguably in line with 4409 8.1), and
ignoring Resent-* means "take 'sender' as defined in 2822upd".
A clarification of "sender" in 2822upd is currently discussed
on the rfc822 list. NOW would be a good time to chime in for
folks having their own ideas (not limited to "first author").
What that's about is simply that ordinary users consider one
or more of the From-addresses they use as "their" address.
These users won't let domain owners overrule this slightly
erroneous view. It was already tough to convince stubborn
users (among others) that there is no such thing as "their"
envelope sender address, to be used whereever they like it.
If "SSP strict" is bound to the "first author" it's DOA. :-(
I fail to see why we should create an RFC only working for
PayPal & Co. - especially while they are still too timid to
use FAIL in their SPF or PRA policies. SSP "first author"
would be far more restrictive than anything SPF or PRA do.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html