Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealth

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:
  C: EHLO mail.fugue.com
  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
  C: DATA
  S: 353 What do you have to say?
  Hi there!<CR><LF>.<CR><LF>
  S: 250 Mail Accepted!
  C: QUIT
  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.From:
   822.Date:
   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.
--
HLS


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp