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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf