On Sun, 4 Sep 2005, Frank Ellermann wrote: > > Where's the problem with an 2822 "resender" ? I'm not sure > about your term "submission server", as far as 2822 (excl. PRA) > is concerned a "resender" is a MUA controlled by a human user. RFC 2476 recommends server-side message header fix-ups, so that MUAs do not have to worry themselves with creating globally-unique message-IDs or correct Date: fields. Submission servers can also fix-up the Sender: field with the address of the authenticated submitter. If the message is re-sent then the server needs to fix-up the Resent-Sender: instead, so it needs to be able to deal with 2822/822 backwards compatibility. > It (the 2822-agent) only has to insert its own Resent-block on > top of all old Resent-header fields. No fixing necessary, or > do you have an example ? If the message has already been 822-re-sent then its syntax will not be conformant with RFC 2822. Perhaps a properly conformant MUA (or MSA) would prefer to fix the old Resent- fields in order to avoid syntax errors. > 2 - it's ignorant but at least it follows a similar strategy > as 2822-"resenders" inserting its stuff at the top => no > problem with PRA. Maybe it's impossible to guess who > created which Resent-Message-ID, but that's no PRA issue. It's more common for software to add fields to the end of the header. > > Sender-ID effecively requires that this kind of submission > > server fix-up must be implemented by MTAs and MDAs that do > > aliasing / redirecting / forwarding. > > Yes, there are serious reasons why co-opting non-voluntary > participants into this mess is _wrong_ But that's the other > appeal, not William's appeal. I intended to just address the syntactic problems, not the higher-level deployment problems. Tony. -- f.a.n.finch <dot@xxxxxxxx> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf