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
