Paul Smith <paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
>>> Look at the headers of the mail in your inbox, particularly mail from
>>> large providers, and you'll find megabytes of headers that nobody is
>>> ever likely to look at or use. This battle was over decades ago.
>> I heard this stated by you a few times. I never brought into it. It
>> a problem to be concern about a few decades ago. Now it is. It's junk
>> its growing. The more it grows the more overhead we have. It makes
>> who are suppose to be ignorant about the junk, work harder. It makes
>> "View Source" more cryptic.
> Hmm, my view is that the headers should be at least vaguely useful at the
> recipient end. That means that OK examples could be:
> But useless ones could be:
But, how to tell which is which, and your X-PP-Email-Transimission-Id
scenario is actually a point.
> The former set may be more useful if it was tagged with WHICH server added
> those headers, but that's it.
It seems that we could write a BCP that says that X-Foo is bad, but
X-foo.example.com: is better?
I think that there is information in the DKIM header which can tell us what
we need to keep.
Any header mentioned in a validatable DKIM header needs to be kept, right?
That also tells us which server added, or was aware of those headers.
If the message goes through "mailman" or some other processor, then it seems
like it ought to rip pretty much every X-FOO out. The rest of them ought to
be known headers at the time the processor was written, and it ought to
either know what they are, or it does not, in which case, it shouldn't pass
on things it does not know about.
I suspect that this would at least make a lot of us less grumpy about excess
I don't subscribe to the idea that the target MTA should rip everything other
than From/To/Subject/Date out. That would limit our ability to innovate, and
there sure has been a lot of that! But, surely, any system that knows what
some header is, (such as X-BeenThere or X-GRID-REF) *is* ought to rip that
out as it knows whether or not its useful.
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
Description: PGP signature
ietf-smtp mailing list