Re: SMTP RFC: "MUST NOT" change or delete Received header

[David Morris <[e-mail]>]

On Sat, 29 Mar 2014, Eliot Lear wrote:

> Hi Kevin,
>
> On 3/29/14, 7:59 AM, Kevin M. Gallagher wrote:
> > What do people today think of the SMTP RFC's current requirement that
> > mail programs and servers must not under any circumstances change or
> > delete Received: headers? Is exposing sender IP addresses to any
> > attacker who can view e-mail headers, for the purposes of preserving
> > trace information, really worth it when weighed against considerations
> > like security and privacy?
> >
> > http://tools.ietf.org/html/rfc5321#section-4.4
> >
>
> There is at least some value in retaining trace headers both for
> debugging and anti-spam (mostly validating what one would expect to for
> a given sender see), headers added by an MSA can entail privacy concerns
> that (IMHO) outweigh debugging considerations.

I would say that the shape of the received headers is one of the things
I look at manually to decide if a strange email is legit. That includes
any internal headers. I'm really uncomfortable having the IETF endorse
removal of received headers considering the finely tuned balance the
many anti-spam algorithms must use to protect us, the public, from
the deluge of junk mail being generated.

I think any change to allow removal should mandate:
a) retention of the whole header set and message for some period like
   90 days to insure the possiblity of dealing with evil actors (virii
   for example) behind the removal
b) include a 'mark' in replacement header indicating the summary nature
   of that header
c) certify the identity of the sender

I don't think mail list software should be allowed to truncate the
received chain as I know that is part of at least some anti-spam
systems logic which allow blocking some list mail, but not all.