Pete Resnick wrote:
Base
specifications can be extended by other documents, and we may update
base specifications without taking into account those extensions.
+1
2. The mailing lists described in 2821 are very simple redistribution
lists, as opposed to the "fairly sophisticated forums for group
communication" [2919] described in these documents. For simple aliasing
and redistribution lists, I think the "MUST be left unchanged" is
appropriate.
A mailing list is re-posting a message. From a purist's standpoint it is a
new message. However the simple lists that Pete is describing seek to be MTAs
that do multi-casting. They are not intending to more than be a relay,
mapping what is really an intermediate address into a set of final recipients.
Having mailing lists like these discussed in 2821 seems reasonable, since they
seek to emulate MTAs. Not mentioning this class of relay is probably worse
than the challenge of mentioning them.
Consequently, to Pete's point: +1.
Assuming people here on the general IETF list have no idea what you're
talking about here, suffice it to say that the discussion that occurred
on the DKIM list to which you refer is about whether the aforementioned
more complex mailing list should be adding or modifying the "Sender"
field. I think there is not consensus on what such mailing lists should
do,
+1. Mailing lists have always presented architectural challenges. No
expectation that that will change anytime soon.
let alone what DKIM should do about that, which IMO lends more
support for the position of 2821bis: Mucking around with a header
section leads to bad consequences, and until some more work is done in
this area to figure out the "correct" thing to do, one MUST NOT go
changing header sections.
+1.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf