Re: Resent-* oddities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tony Finch wrote:

> 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.

Okay, and something like Resent-Message-ID worries me, e.g.
what are mail2news gateways supposed to do ?  Personally I
think that Resent-* is a hopeless case and should be
deprecated.

*Maybe* it's possible to fix it in hypothetical 2822bis and
2476ter RfCs, and if that's done with "we want PRA to work"
in mind PRA might really work.

But my personal interests in this issue are limited to "I've
never got a single Resent-* mail", "MIME message/rfc822 is
better for this purpose", and "so do what you like but stay
away from my mail".

And the latter is the point of the first senderid-appeal.

> 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.

Yes.  The method to do this would be somewhat similar to PRA,
starting with "if there is a Resent-* header field" {etc.]

BTW, 2476bis 8.1 talks about "add Sender", not "fix Sender",
that's a major difference.  A potential "fix Sender" should
be better "reject" - or maybe "rename and add", but not just
"replace silently", the latter makes me very nervous.

>> 2 - it's ignorant but at least it follows a similar strategy
>>     as 2822-"resenders" inserting its stuff at the top
{...]

> It's more common for software to add fields to the end of the
> header.

Then let's forget "maybe PRA could work with case [2]", that
leaves case [3] "PRA doesn't work with the 822 Resent-* idea".

> I intended to just address the syntactic problems, not the
> higher-level deployment problems.

Okay, but the IESG has to do something with William's appeal,
that's a special case of "higher-level deployment problem" ;-)

                          Bye, Frank



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]