Hector Santos wrote:
Sender predates PRA so how can PRA regulate it?
List owners can decide that they wish to support PRA checks based
on RFC 4406 (or based on an IESG note repeated in "other" RFCs ;-)
Example: Charles + Scott as authors (2822-From) post an answer
to a mailing list (with 2822-Sender Scott), what's the mailing
list software supposed to do if it doesn't support a 4406 PRA ?
[...]
No, for a mailing list, Sender: is generally the mailing list's
"Pseudo Admin Agent", like for this list IETF-DKIM message:
Sender: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
or like in our setup in our support lists:
Sender: listadmin(_at_)winserver(_dot_)com
So Scott should not be in the Sender: field.
Would the mailing list software replace the Sender: Scott header
field, or would it reject the submission ? What I really wanted
to know, Scott mentioned a SHOULD about this issue, but which RFC
(apart from RFC 4406) talks about Sender header fields set by a
mailing list ? I'm looking for an RFC number, not for an example
what some lists actually do. I think the RFCs about List header
fields and the List-ID don't mention Sender, but I could be wrong.
The key thing is that it should never be part of a HUMAN reply
process, and as far I recall in our various MUA testing, none
include it in a "Reply To All" concept.
ACK, that's very clear in (2)822(upd), let alone the four or more
RFCs explaining the purpose of an "envelope sender address" again
and again - only the creators of Sender ID never got the idea. :-(
IMO, this is one reason why the PRA algorithm is flawed.
Let's be fair, they don't use the PRA for human or auto replies.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html