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

From: "Kevin M. Gallagher" <[email-masked]>
Date: Sat, 29 Mar 2014 02:59:00 -0400

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

Kevin
@ageis
0x5921D69C

---

From: Randy Bush <[email-masked]>
Date: Sat, 29 Mar 2014 17:44:51 +0900

> delete Received: headers?

as someone who has to debug email problems, they are very very helpful

> Is exposing sender IP addresses to any attacker who can view e-mail
> headers

perhaps an apporach would be to limit who can view email headers

randy

---

From: Dave Cridland <[email-masked]>
Date: Sat, 29 Mar 2014 09:33:06 +0000

> http://tools.ietf.org/html/rfc5321#section-4.4

I would note that removal of internal Received headers at the exit boundary
of the sending ADMD is quite common - and I ran into this one just the
other day, where a client wasn't doing this and it caused concern.

Outside of the sending ADMD, the trace fields are of very low value for
debugging, and as discussed in §7.6, may be problematic.

Inside (and at the boundary especially), they are useful, so mandating that
they're added, but may be removed at the exit of the sending ADMD seems
sane. I'm not going to demand any change here for the simple reason that
there's no way to distinguish what's happened externally; therefore this
doesn't strike me an an interoperability concern.

Dave.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 29 Mar 2014 10:51:23 +0100

Hi Kevin,

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

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Mar 2014 08:36:52 -0400

> that (IMHO) outweigh debugging considerations.

RFC 7044 (An Extension to the Session Initiation Protocol (SIP) for Request History Information) did a pretty nice job of addressing very similar privacy concerns.

---

From: Dave Aronson <[email-masked]>
Date: Sat, 29 Mar 2014 10:38:42 -0400

> perhaps an apporach would be to limit who can view email headers

Once a malicious actor has the email, how do you propose to limit his
ability to view whatever part of it he pleases?  Maybe add a "Do Not
Look At If You Are Evil" bit on each field?  ;-)

-- 
Dave Aronson, freelance software developer (details @ www.Codosaur.us);
see also www.PullRequestRoulette.com, Blog.Codosaur.us, www.Dare2XL.com

---

From: David Morris <[email-masked]>
Date: Sat, 29 Mar 2014 07:57:30 -0700 (PDT)

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

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2014 14:59:03 -0000

>like security and privacy?

The headers are useful for debugging, particularly for things like
forwarding loops.  Particularly on public webmail systems, it lets you
see where spam is coming from, and offers the possibility of alerting
the originating operator if you think they'll care.  Gmail is notable
in redacting this from some (not all) of their outgoing mail.

What sorts of attacks do you think are enabled by allowing mail
recipients to see the headers?

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 29 Mar 2014 12:01:37 -0400

> From: "Kevin M. Gallagher" <[email-masked]>
> 

Received: headers are quite useful when you're trying to figure out
which mail server sat on the message for four days.

They're also useful when you're trying to figure out what sequence of
address rewrites got the message to you.

Dale

---

From: Dave Crocker <[email-masked]>
Date: Sat, 29 Mar 2014 09:16:47 -0700

On 3/29/2014 5:36 AM, Ted Lemon wrote:
> On Mar 29, 2014, at 5:51 AM, Eliot Lear<[email-masked]>  wrote:
> RFC 7044 (An Extension to the Session Initiation Protocol (SIP) for
> Request History Information) did a pretty nice job of addressing very
> similar privacy concerns.

1. Even a document as 'small' as 26 pages is large enough to make a 
simple document reference be vague; can you point to the specific text 
that is relevant to this thread?

2. In spite of email's having 30 years of operational experience with 
this issue, RFC 7044 does no more than make a generic reference to email 
in the Background section.  For the purposes of the current thread, that 
makes applying the RFC 7044 reference even more challenging.  It would 
help if you explained how we ought to apply its lessons to the question 
at hand.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Brim <[email-masked]>
Date: Sat, 29 Mar 2014 12:43:42 -0400

I think the privacy beach from exposing intermediate steps is small, and in
some cases knowledge of the routing may be required by law.

---

From: Hector Santos <[email-masked]>
Date: Sat, 29 Mar 2014 12:47:57 -0400

> delete Received: headers?

I will provide a different perspective other than the typical trace, 
debugging and technical support reasons and why they are useful for 
those moments.

There was never a requirement to retain HEADERS at the final 
destination.  The historical main reason is because of gateway 
transformations.  There are other formats that predated x822/5322 
electronic mail storage formats.

The 5321 "requirements" is more about not TAMPERING with passthru mail 
(relays), and there is legal precedence for not tampering with 
transient communications laid out in the 1986 US ECPA.  Of course, the 
mail body content SHOULD NEVER be tampered.  Mail hosting systems such 
as ours were long molded from this ethical mail hosting design model.

> Is exposing sender IP addresses to any

Again, if you are relaying mail, you really have no choice here.  You 
have to keep and pass it on.  If you don't, then you are not playing 
the game right, plain and simple.  You might not be helping the 
downlinks of the message (the true final destinations) if there a 
problem.

So you are really just talking about LOCAL FINAL DESTINATION mail.  I 
think that applies for (meta) data that is created temporarily as 
well, i.e. you might add a trace meta header for your own internal 
mail routing purpose but it is finally pulled before it goes out or 
the end user gets it.   There are a few headers like that, the 
Return-Path is one of them where it is added but then POSSIBLY pulled 
by an implementation.

Historically, they helped in support but yet at the same time, you had 
a small mistrust in them as well as you are suggesting here.  You 
extracted what made possible sense and thats it.  I personally think 
the IP concerns, while possible and real, are very isolated.  The 
support needs are also isolated but I think its one of those things 
where you desire/wish for the information when the relatively few and 
increasingly rare support times comes.

Overall, I always had an strong ethical engineering position on never 
destroying information especially at the passthru (relay) level. 
There is/was legal precedence for this.   At the local level, we also 
had a need to provide mail gateways for other formats and there are 
many headers that are not part of the transformations.  The Received, 
and the potential to have many of them, was not one of them.  When a 
gate was performed, the necessary Network Control Lines, headers that 
allowed for replying and continued network communications to take 
place, where added to "meta" storage. But the the remaining overall 
was pruned.  If there was a support need, you enabled the preservation 
of the full RFC headers and told the user "try it again."

That said, as the mail systems and END-USERS evolved to include more 
multi-media information, like HTML, MIME, etc, it became increasingly 
necessary to PRESERVE the original message format. This became more 
true as users moved away from online to offline RFC reader/writer 
communications, i.e. POP3, where online it (display rendering) was 
fully controlled by the backend server, but with POP3, the backend 
lost the control of what is possibly displayed.

But with the movement or recycling back to online is taking place, you 
don't really need all the headers and there are lots of wasted 
overhead for sure. Most Users don't even know what they are anyway or 
even care.  Its all for those rare support needs and thats become so 
infrequent, who knows, maybe the next big interested I-D would be how 
to clean up all the x822/5322 mess.  Have you see the junk in those 
stuff?  Junk that could expose security related info or just plain 
nonsense that doesn't apply to you anyway.  ALL those X- headers. 
Thats information you certainly don't need 80% (pareto) of the time.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 29 Mar 2014 12:49:44 -0400

On 3/29/2014 12:43 PM, Scott Brim wrote:
> I think the privacy beach from exposing intermediate steps is small,
> and in some cases knowledge of the routing may be required by law.

That has always been my engineering understanding, and it predated the 
IETF RFC electronic mail format.

-- 
HLS

---

From: David Morris <[email-masked]>
Date: Sat, 29 Mar 2014 10:03:57 -0700 (PDT)

On Sat, 29 Mar 2014, Hector Santos wrote:

...

> was pruned.  If there was a support need, you enabled the preservation of the
> full RFC headers and told the user "try it again."

...
> headers. Thats information you certainly don't need 80% (pareto) of the time.

The problem with the "try it again" approach is that there is no assurance
the failure will repeat. Information lost, is just lost, making end user
support on the 20% (your number) of the cases where there is a problem
impossible. Etc.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Mar 2014 13:04:35 -0400

The History-Info header field is somewhat analogous to the Received: header field.   Look for the section on privacy.

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2014 17:16:00 -0000

>I think the privacy beach from exposing intermediate steps is small,

agreed

> and in some cases knowledge of the routing may be required by law.

That seems unlikely.  Got any citations?

R's,
John

---

From: Dick Franks <[email-masked]>
Date: Sat, 29 Mar 2014 17:20:10 +0000

> address rewrites got the message to you.
Try explaining to some other organisation that their mail system is broken
without the evidence readily available.

The longest delivery delay I ever investigated was a magnificent 17 months!
The recipient was truly baffled.  A mailserver far away had a disk restored
from backup, complete with a queued message in the level 0 dump.

---

From: Hector Santos <[email-masked]>
Date: Sat, 29 Mar 2014 14:10:43 -0400

This isn't new for mail processing software developers. US EPCA. 
Product liability concerns.  You will pay more in commercial 
insurance.   Tamper with passthru, routing mail, you are at more risk, 
more so than others that don't. There were court precedence not only 
with tampering, but related to ownership and privacy issues. Google, 
yahoo, now facebook, etc, have all relied on the middle ware ownership 
legal concept to help get away with the privacy, tampering related 
borderline ethical issues. Congress has relaxed the laws to allow for 
"Good Samaritan" provisions, where you are allowed to do more, but 
don't go overboard. Of course, push come to shove, the devils would be 
the details.

Remember, its not just about protecting yourself, but protecting your 
customers are well.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sat, 29 Mar 2014 14:13:08 -0400

> support on the 20% (your number) of the cases where there is a problem

Sure. No doubt, that these days, as oppose to days where mail volume 
STORAGE was a premium and overhead was pruned, preservation RFC/MIME 
is the first consideration.

Thanks

-- 
HLS

---

From: Christian Huitema <[email-masked]>
Date: Sun, 30 Mar 2014 01:02:09 +0000

> IETF RFC electronic mail format.

I flagged that in the perpass draft that I wrote back in November. Exposing the *intermediate* steps is pretty much harmless, but exposing the *initial submission* step does convey some interesting information. If you use the combination of IMAP and SMTP submission, the traces convey the current IP address of your laptop, or record its successive IP addresses as you move.

When SMTP was designed, the practice was to submit your mail directly from the server. The web based servers and many corporate servers still follow that model. The first SMTP step was from a fairly well known server to the next relay. There is no particular privacy issue with the trace field in that case, since the mail server name can pretty much be inferred from the sender's address, and the IP address can be retrieved from the DNS. The same is true for intermediate relays, which are (or should be) publicly advertised in MX records. 

Now look at what happens If you use IMAP or POP3 to retrieve your mail on your laptop, or tablet, or phone. IMAP and POP3 do not enable mail submission, so you will normally use SMTP. Your laptop becomes the first step in the transmission chain. The first "Received" header carries its IP address, the laptop hostname, the time of submission, and very often other information like the type of security being used. This will be available to anyone who can observe the mail in transit. Should you send an email to a mailing list, the information becomes available to all mailing list recipients.

There is a strong case that the "SMTP submission" information should be removed from the trace fields for privacy reasons.

-- Christian Huitema

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 30 Mar 2014 10:55:35 -0400

On Sat, Mar 29, 2014 at 10:59 AM, John Levine <[email-masked]> wrote:

> forwarding loops.

Debugging is not a justification for MUST.

Never, ever, ever. The justifications are

* Interoperability
* Security / stability.

The justification for MUST was I suspect to prevent infinite recursion mail
loops. For that particular purpose a count is sufficient.

> Particularly on public webmail systems, it lets you

The requirement does not meet contemporary requirements for MUST so it is
invalid. Systems out on the net are justifiably ignoring it.

-- 
Website: http://hallambaker.com/

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2014 15:14:32 -0000

>loops. For that particular purpose a count is sufficient.

Oh, of course, you're right, it even says so in section 6.2 of RFC
2821, now 6.3 in RFC 5321.  But there isn't a count, so this would be
an incompatible change to the SMTP protocol, which seems like a
non-starter to me.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Mar 2014 14:09:12 -0400

Wow.  The nice thing about SMTP is that everyone has an opinion,
sometimes several.  20+ messages in under two days.

I'll try to avoid repeating things that others have said, but...

(1) The historical reason for a list, rather than a count, is
that a count does not permit a "been here already" test.  At
least in the past, "been here already" tests have been as or
more useful than counts for loop detection, especially when
gateways to systems that use SMTP-like protocols are involved.  

(2) As others have noted, the trace has often been a critical
debugging (and finger-pointing) tool.  It is also sometimes been
an important legitimacy-determining tool because it allows
"could a legitimate message possibly have taken that path"
examination.

(3) There is no SMTP requirement that trace headers (really a
part of the envelope, even while stored in the headers) be
transmitted from the final delivery server to the message
recipient or even to whatever is used as a mail store.   Whether
such information suppression would be helpful for any important
threat model is another issue entirely.  In most of the
circumstances I can think of, suppressing or discarding those
header would have few practical advantages and be fairly dumb
but, "don't be dumb on delivery" is not an explicit SMTP
requirement either. 

(4)  For those that believe that exposing the address of an
originating client machine poses a serious privacy problem (see
Christian's notes for a clear discussion), Section 8, especially
Section 8.8, of RFC 6409 (Message Submission) appears to me to
provide more than adequate permission to rewrite those addresses
in the submission server.  That issue does not appear to me to
be part of the SMTP discussion.  Indeed, having an intermediate
SMTP system decide what information should be rewritten or
disguised seems to me to violate the general prohibition about
messing with messages in transit of which the "don't change or
delete RECEIVED header fields" rule is one corollary among many.

<rant>
Our current mail system, including the various evolutionary
changes to both SMTP and Message Headers, has, as Dave Crocker
pointed out, served the community rather well for 30+ years and
a decade more than that if one counts the email-over-FTP period.
For many of those years, it was the fabric that held the people
of the extended Internet together despite poor connections,
connections that were at best intermittent, interconnections to
alternate network technologies, and competing mail protocols
(both based on voluntary standards and quite proprietary).
Things are easier today because most of those competing systems
and technologies have faded away and most email connections go
directly from the administrative scope that is, at least in
theory, under control of the sender to one that is, also at
least in theory, under the control of the recipient.  In those
"one hop over the public network" arrangements, this type of
proposal would, independent of its other properties, accomplish
nothing useful in terms of information-hiding.  

However, as people contemplate ways to get a little more
performance, a little better privacy, a little better way to
deter or filter spam, malware, or bad guys, I wish we could all
keep in mind that no one with adequate authority has promised
that today's happy situation will prevail forever.  We are
seeing a large collection of proposals and actions that point to
national network boundaries; new, more politically-based,
address allocation strategies; national content controls and
filtering; and a whole series of other things.  If the advocates
of any of them succeed, we could easily find ourselves back in a
situation very similar to the one we had in the late 80s and
early 90s.  I hope that few who are reading this would advocate
that situation, but wishing won't prevent it.  In that
environment, network protocols that are dependent on single-hop
end to end connections just won't work worldwide.   In such a
situation, a robust, international, gateway-friendly, store and
forward email system could turn out, again, to be the best we
can do.   Let's try to avoid weakening it. In particular, let's
be very careful that proposals that would weaken it in the
interest of worthwhile goals, including privacy improvements,
really bring enough benefits to be worth the costs and risks.
</rant>

   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 30 Mar 2014 17:31:36 -0400

> gateways to systems that use SMTP-like protocols are involved.

I still don't accept mere debugging as a rationale for MUST.

But I can extend the case to MUST: Attacker subscribes two mailing lists to
each other. Thus setting off a spam loop.

> recipient or even to whatever is used as a mail store.

It depends in part as to whether SUBMIT and SMTP are treated as separate
protocols. I think they should be since mail can only cross once from the
SUBMIT port to the SMTP port. And the acceptance of the SUBMIT mail should
be authenticated in any case.

If we assume the mail traffic is all over TLS, for non mailing list mail,
there are three spans at issue:

1) User's mail client to outbound email server via SUBMIT.

2) From the user's outbound mail server to the inbound mail server
specified in the destination address. (ignoring outbound mail forwarding
for the mo).

3) From the inbound mail server to the final destination.

Span 3 is all under the control of the recipient mail domain. Those headers
might leak information to the recipient about their provider's
infrastructure but they are not leaking information about the sender.

> delete RECEIVED header fields" rule is one corollary among many.

Agreed

> early 90s.

There are certainly governments trying and at least some will succeed.

I don't think we can stop them but the people who they are trying to
control can.

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Mar 2014 18:44:13 -0400

--On Sunday, March 30, 2014 17:31 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

>> Wow.  The nice thing about SMTP is that everyone has an
>> opinion, sometimes several.  20+ messages in under two days.
>> 

Whether one accepts it or not, "been here already" tests are not
about debugging.  They are about loop detection and DoS attacks.

> But I can extend the case to MUST: Attacker subscribes two
> mailing lists to each other. Thus setting off a spam loop.

Yes.

> It depends in part as to whether SUBMIT and SMTP are treated
> as separate protocols. I think they should be since mail can
> only cross once from the SUBMIT port to the SMTP port. And the
> acceptance of the SUBMIT mail should be authenticated in any
> case.

While I don't think SUBMIT has anything to do with whatever a
final delivery does, while they share a command structure, they
are as much separate protocols as the IETF can typically
arrange: different conformance rules, some differences in
command structures, different ports, etc.

> If we assume the mail traffic is all over TLS, 

It is not clear to me that discussing models based on obviously
counterfactual assumptions is a good use of time.

> for non mailing
> list mail, there are three spans at issue:
> 
> 2) From the user's outbound mail server to the inbound mail
> server specified in the destination address. (ignoring
> outbound mail forwarding for the mo).

Please read the part of my note that argued for preserving the
multi-hop model.  You are not only assuming TLS, you are
assuming TLS in a "no relay" environment.  Sorry, but that
discards enough of SMTP's capability's and model to make your
discussion uninteresting.
  
>> deter or filter spam, malware, or bad guys, I wish we could
>> all keep in mind that no one with adequate authority has
>> promised that today's happy situation will prevail forever.
>> We are seeing a large collection of proposals and actions
>> that point to national network boundaries; new, more
>> politically-based, address allocation strategies; national
>> content controls and filtering; and a whole series of other
>> things.  If the advocates of any of them succeed, we could
>> easily find ourselves back in a situation very similar to the
>> one we had in the late 80s and early 90s.
>> 
> 
> I don't think we can stop them but the people who they are
> trying to control can.

The point was intended to be that we have a mail system
(critically including, but not limited to, SMTP in all of its
sometimes-inconvenient MX-as-gateway, multiple hop, glory) that
has proven very successful in getting messages past and around
government-imposed and technological blockages.  Models and
systems that assume or force having only one hop between what
you describe as the user's outbound mail server and inbound mail
server considerably weaken the potential of that model.  That,
in turn, makes it much easier for governments and the like to
block email traffic along with anything else they might block.
I don't think we should hand them that victory just because it
is easier to think about SMTP in the sort of model you describe
above.

Folks, if we really need to continue this conversation (I hope
we don't), can we move it to the SMTP list?

   john

---

From: Randy Bush <[email-masked]>
Date: Mon, 31 Mar 2014 08:43:51 +0900

> Debugging is not a justification for MUST.

do tell me where that is enshrined so the ietf ops community can go have
it fixed.

randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 31 Mar 2014 08:52:38 +0900

the day was weird enough already without my having to agree with an
entire, typically long, jck posting :)

the truth is, i have not used received: headers to authenticate/debug
[0] since yesterday.  but it's not yet 09:00, so there is still time
today.

randy

---

[0] - from an ops pov, loop detection, lists subscribing to eachother,
      and all that stuff is debugging.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 30 Mar 2014 20:38:03 -0400

> about debugging.  They are about loop detection and DoS attacks.

Are there MTAs that make use of the Received: header for loop detection?

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2014 01:07:51 -0000

>Are there MTAs that make use of the Received: header for loop detection?

Mine has since 1998.  If the SMTP daemon sees 100 Received: headers in
an incoming message, it rejects it.  This is both in qmail's SMTP
daemon and mailfront, a better SMTP daemon often used with qmail.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 31 Mar 2014 01:16:24 -0000

>daemon and mailfront, a better SMTP daemon often used with qmail.

A little more poking around finds that sendmail and postfix also do,
although their default limits are 25 and 50 headers, respectively,
rather than 100.

---

From: mohammed serrhini <[email-masked]>
Date: Mon, 31 Mar 2014 05:49:46 +0400

A Bayesian Method Bayesian filtering  (it's best known for its extensive testing of message headers) to filter spam

>although their default limits are 25 and 50 headers, respectively,

С уважением,
mohammed serrhini
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Mar 2014 19:14:02 -0700

> Are there MTAs that make use of the Received: header for loop detection?

MMDF had it, probably from the early 1980s, but certainly sometime 
during the 80s.

I have a vague recollection of adding it to the code, though that could 
be an invented memory.  The Received header field was not in RFC 733, 
and was standardized in late 1982 (RFC 822), just before I stopped doing 
MMDF work.

More likely, it was added by the folk who did the follow-on work for 
MMDF II, but still probably early/mid 1980s.

Back then, passing through the same host more than a couple of times 
would be a good indication of looping.

d/

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Mar 2014 23:31:30 -0400

--On Sunday, March 30, 2014 20:38 -0400 Ted Lemon
<[email-masked]> wrote:

>> Whether one accepts it or not, "been here already" tests are
>> not about debugging.  They are about loop detection and DoS
>> attacks.
> 

It is long gone, but my recollection is that the
second-generation VM/CMS Internet-BITNET gateway did both count
and "been here" checks.  Exim not only does a count check but
has a configuration parameter for the threshold count.  Ned or
one of his group would be authoritative about their current
system and its PMDF predecessor but my recollection is that the
latter made at least one of those checks.

Based on the above, comments from others, and my general
impressions and recollections, I think the answer to the above
question is probably "yes, most of them".

    john

---

From: Dave Cridland <[email-masked]>
Date: Mon, 31 Mar 2014 08:36:23 +0100

> [0] since yesterday.  but it's not yet 09:00, so there is still time

I'm assuming you realise that nobody is arguing that all received header
fields be stripped?

The problem I've run into is generally machine [~auto] submitted email,
where the network itself is "sensitive" (let's pretend it's a big bank),
and the administrators don't wish to reveal anything about the network
location of said machine.

The trace fields stripped would be limited to (probably) one - that of the
original {trans|sub}mission. It'll also be (in practise) a constant modulo
the timestamp.

Does this change your point of view? If not, why would knowing about a
machine that's likely on private IP address space or otherwise on an
unrouted network be useful to you for debugging purposes?

If there's a problem with the mail, the big bank can track down what
happened easily enough, and you can point your finger at the correct big
bank.

Dave.

---

From: Hector Santos <[email-masked]>
Date: Mon, 31 Mar 2014 07:57:37 -0400

On 3/29/2014 9:02 PM, Christian Huitema wrote:

> There is a strong case that the "SMTP submission" information should
>be removed from the trace fields for privacy reasons.

We need to remind ourselves that, as a society, we have already 
exposed "Caller ID" information for the originating contact.  So this 
engineering mindset is set.

But we have made it optional (via a phone).  So I would rephrase your 
suggestion that there is a strong case to allow operators the option 
to remove it or add it by default, however, I would suggest it 
SHOULD|MUST always be recorded, like in a log.

It may be none of my business to know what your IP address is, but it 
maybe also be none of my business to know:

  -- your MAILER?, reader/writer software?
  -- how many machines in your network?
  -- that you have anti-spam, security activity going on
     between HOP x and HOP y?

That spam scoring stuff can leave one with a major complex!

The only time any of this is needed is when there is a tech support 
issue.  In my opinion, communications reliability has improved over 
the years where the overhead items are less necessary.  However, when 
the need does arise, you want the information.

So do we turn it off?  Perhaps not, the software would evolved where 
it would be recorded -- somewhere, but maybe not further distributed 
downlink.

Consider, between all communication devices, hosting systems, we only 
really need the common denominator headers:

    From:
    To:
    Subject:
    Date:

plus body and not much more.  The popularity of texting in general 
illustrates that simplicity works.

-- 
HLS

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Mar 2014 08:40:56 -0400

Would it help if the Received: line had a domain-unique stamp, such that
at the border of any "sensitive" place, it would be easy to identify 
the stamp.
I'd love to suggest it be the AS#, because that would have utility for
everyone, but I suspect that many entities that care also don't have
their own ASN, or the network being transitted doesn't have an ASN.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Mar 2014 08:40:59 -0400

--On Monday, March 31, 2014 08:36 +0100 Dave Cridland
<[email-masked]> wrote:

>> the truth is, i have not used received: headers to
>> authenticate/debug [0] since yesterday.  but it's not yet
>> 09:00, so there is still time today.

> I'm assuming you realise that nobody is arguing that all
> received header fields be stripped?
> 
> The problem I've run into is generally machine [~auto]
> submitted email, where the network itself is "sensitive"
> (let's pretend it's a big bank), and the administrators don't
>...
> If there's a problem with the mail, the big bank can track
> down what happened easily enough, and you can point your
> finger at the correct big bank.

As I pointed out earlier, this is precisely the case for which
there is language in the message submission spec.  It has
nothing to do with SMTP across the network.

   john

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Mar 2014 08:47:41 -0400

--On Monday, March 31, 2014 07:57 -0400 Hector Santos
<[email-masked]> wrote:

>...
> The only time any of this is needed is when there is a tech
> support issue.  In my opinion, communications reliability has
> improved over the years where the overhead items are less
> necessary.

Actually, I disagree.  While one could develop measures based on
a series of conditions being met, I think that "communications
reliability" can only be measured and reported in some way that
reflects the fraction of messages that leave an origin point
that are fully accounted for (i.e., by being delivered or
non-delivery being adequately reported).  Messages that simply
disappear lower that estimate.

Independent of the reasons why quietly discarding messages may
be entirely justifiable, the decisions of the last several year
to do that reduce communications reliability relative to the
time when senders could be assured that messages would either be
delivered or returned (or rejected if the distinction is
relevant).   If one comes up with a definition of "legitimate
message" and defines "communications reliability for legitimate
messages" the numbers would obviously be better but, absent very
broad consensus about that definition or 100% accuracy in
decisions about what to discard --two conditions I believe are
very unlikely to be satisfied, but YMMD-- the reliability
estimate is still almost certainly down from the period before
spam and malicious mail became major issues.

>...
> So do we turn it off?  Perhaps not, the software would evolved
> where it would be recorded -- somewhere, but maybe not further
> distributed downlink.

For part of the answer, see earlier comments about message
submission.

    john

---

From: Hector Santos <[email-masked]>
Date: Mon, 31 Mar 2014 13:46:37 -0400

My point is that today, the technical advancement is such that is 
there clear cut technical advancement and understanding of what it 
takes to setup a proper and compliant mail system. We know what works. 
We know what doesn't works. We know what to avoid. We know what is 
expected to happen in the mail flow for practically every situation, 
etc. It isn't a guessing game anymore.

If this isn't the case, then we have wasted our time in the past three 
decades. What have we been doing?  What are we producing and selling? 
I don't believe SMTP is a "Cross your Fingers" mail transport protocol.

Of course, when it comes to the specific mail applications, there is 
going to be different mail delivery efficiency levels, e.g.; DMA 
vendors, spammers, etc, will experience a higher rate of undeliverable 
and/or not getting to user's eyeballs.  These are deliberate actions 
must of the time, and in advanced systems, automated.

But we simply don't expect unreliable protocol communications to 
happen in  professional or business networking markets where 
communications is highly expected to be reliable. When there is a 
problem, it is usually addressable.  I would suggest that those 
problems are few and far between.  (Not speaking of spam filters, but 
again, that is intentional).

Of course, we have the rare "hard nose" local system operators that 
will reject and do things differently than most, but generally it is 
not the norm and we don't usually follow them as the norm. Even when 
it may include one or two key IETF contributors with such a different 
"ownership" philosophy, we make note that they exist and also note it 
is possible Mail Delivery is not always guaranteed.  But I would 
suggest that would be the exception, not the rule.

Again, I think if communications was unreliable across the board for 
all markets, I believe many of us would of moved on to other product 
development careers.  It wouldn't be the same.  I have always expected 
a high degree of reliable communications, in the protocol logics that 
make it all work, dynamically or delayed, store and forward, etc.

Its the same idea here with the IETF list; you and I expect the mail 
to be delivered and distributed. I expect a high reliability in the 
procedures and steps that are known to occur.  We can't live in a 
world where crossing fingers is the norm.  When there is a problem, 
there are no gremlins. There is an explanation and its resolvable.

Perhaps a dumb analogy, is like a DEBUG vs RELEASE compiled 
production.  Once you have a certain confidence in your reliable code 
in release form, you don't need all the debugging statements to help 
you solve problems.

--
HLS

-- 
HLS