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(_at_)dotat(_dot_)at> http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf