Bruce Lilly wrote:
s/Received/Return-Path/ (or is this some pre-821 history ?)
RFC 821's predecessor, RFC 788:
Oh, yes, I should have known this, I read the "SMTP history"
archive at rfc-editor.org (once - looking for new "evidence"
for we-all-know-what-and-are-seriously-tired-of-it... :-)
Ordinary users are most probably not often interested in the
timespamp lines
[...]
Interesting typo; maybe the lines should in fact be referred
to as "timespam".
I fear you've to be very brave when you start your first DKIM
review. Until then I hope that I've found out why they _copy_
the signed header fields - it must be something obvious.
The problem with UAs suppressing header fields is that some
of them suppress important fields which communicate
information from the message originator to recipients (e.g.
Reply-To).
Normally I trust that my UA just does the right thing, Re:Mail
to Reply-To, or without Reply-To to the From. The one thing I
simply didn't expect was that you manually set Reply-To: list.
No idea how to fix this, UAs trying to be smarter than their
user are in trouble. In that case I was the stupid user, and
I didn't like the experience, I want to be smarter than my UA.
It's a tough problem for a UA author, as there is no way to
automatically determine whether some new message header field
is a new originator field (which should not be suppressed) or
some transport noise (which should be suppressed).
Or some wannabe-Received-SPF / Authentication-Results where an
implementor is sure that everything he does could be dangerous.
The usual game, there will be a way to configure the behaviour,
most users won't do this resulting in some default, and that
default will be very bad for some constellations. Bye, Frank
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf