[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

2015-12-05 12:49:26
On 12/4/2015 2:37 PM, Ted Lemon wrote:
Friday, Dec 4, 2015 11:54 AM Dave Crocker wrote:
Hence, queries of the 'show your work' type move into the realm of
etended tutorial to non-experts, rather than helping to the vetting of
foundational issues for creating a working group.

I share your discomfort.   However, my concern with the approach of simply 
refusing to answer questions on the grounds you state is twofold: first, it 
excludes any participation by stakeholders other than anti-spam developers, and 
there are other stakeholders.   Second, it preserves the status quo, which is 
clearly broken.   By which I do not mean that you all are not doing good work: 
what I mean is that because you are so effective at minimizing spam, there is 
no incentive to actually clean up many of the messes you are working around at 
the moment.

From my perspective, quite a bit of useful information has already been shared 
as a result of this discussion, and it would be nice if that information were 
collected somewhere.   I think that there's more work to be done.   It may be 
bothersome to folks who don't feel that these questions need to be answered, 
but I don't think it's realistic to think that if you just protest loudly 
enough, they will stop getting asked, or that the practice of header redaction 
will not become more widespread.

Ted, as you know, many packages are quite old and well established -- change is not easy. What is common is that we all need to interop in a consistent and persistent protocol required/expected manner. Without that, it doesn't work well.

Sure, it will be nice to read reports on methods, ideas, issues but for the most part much of this has already been covered. So what else is possibly new after 30+ years of world-wide mail industry?

If it has been shown that the STD10/RFC2821/RFC5321.Received can be "exploited" in some negative way, then it doesn't really matter what I think, the customer can be potentially harmed and therefore, I am ethically obligated to offer an option to disable, hide or mask the "harmful" information. So what are the ideas for this? In the end, it may come down to changing the standard to say "MAY|SHOULD" instead of "MUST" IFF there is NO evidence of interop issues.

We do this all the time with product identification during any internet application protocol connections. For example, for PCI compliance, I have a very large customer whose PCI auditor pushed for the removal of all hosting product id/version identifying information. We made the option to disable available to the customer quickly and for others in the next update. No more support cost issues along those lines whether I thought it as stupid or not.

I can say that PCI Auditors can push for (IETF protocol related) technical changes if the customers are hassled by them. We have already begun to see the browser enforcement with the HTTPS only push. We long had a "Single Click PCI Compliance" button to enforces HTTPS and Session Tracking/Time Management.

However, most of the time, No one have have an answer for "Compromised User" issues. In that case, all bets are off. Like a "Active Shooter," learn to track it and basically shut the account or force a changing of a password.

If the removal of the "Received:" trace line help mitigate a potential exploit, then I would like to see input from people who think it may be also a backward compatibility issue where "useful things" may break.

Now that I am thinking about it, I need to see how it could alter our SMTP valid RFC header detector during reception.

Technically, we can have Very Simple Mail Transfer Protocol (VSMTP) clients sending mail where the RFC 822/2821/5321 header block MAY NOT be part of the payload (DATA). IOW, you can do see this:

  S: 250 Welcome
  C: MAIL FROM <mellon(_at_)fugue(_dot_)com>
  S: 250 its all good
  C: RCPT TO: <hsantos(_at_)isdg(_dot_)net>
  S: 250 continue
  S: 353 What do you have to say?
  Hi there!<CR><LF>.<CR><LF>
  S: 250 Mail Accepted!
  S: 220 <click>

And that MAY be an acceptable transaction because the system will auto-fill or regenerate the required RFC fields or it may not, i.e. for a print or fax job, or if its a local message versus a relay:

  5322.From:    <--- 5321.MAIL FROM, Required
  5322.Date:    <--- Current Time Stamp (GMT), Required
  5322.To:      <--- 5321.RCPT TO, Not Required
  5322.Subject: <--- not required

At a minimum, most mail readers systems only needed the above fields for the simplest Mail Reader possible. I've written about 5-6 MUAs in my time.

However, the regeneration MAY NOT take place if it detects a valid internet email header.

So the question now becomes how tight is the SMTP requirements per site?

If the site follow strict RFC822, then you require:

   822.TO or 822.CC

If you relaxed it to RFC2822 (which is the same as RFC5322), then only the 5322.From: and 5322.Date: are required. The "To:" was relaxed, not required. Once upon a time there was a I-D Proposal to further relaxed the "5322.From" header from email. If that had happen, DKIM would probably never had been done even though today, many folks would probably not wanted the 5322.From: DKIM binding requirement. Notice how there is a conflict here as well with Received since it also part of the Binding recommendations (but not a requirement).

In any case, in our SMTP RFC detector, we also use the the required "Received" line depending on what level of 822/2822/5322 support is enabled. I have to check.

So overall, it is not cut and dry about removing a long time "standard" required feature in SMTP. It has to be studied before a recommendation can be made to effectively change a long time standard.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>