ietf-smtp
[Top] [All Lists]

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

2015-12-12 10:30:54
On 12/3/2015 8:29 PM, Robert A. Rosenberg wrote:
At 13:40 -0500 on 12/03/2015, Hector Santos wrote about Re:
[ietf-smtp] [Shutup] Proposed Charter for the "SMTP Hea:

Personally, If the WG is created, it should also consider looking at
reducing redundancy and the major RFC5322 overhead in electronic mail
that already exist.   Many headers are simply not needed at all and
many do leak all sorts of user information.

Which headers do you regard as "not needed" and which leak user info?
For the latter, please indicate if the header's existence in a message
is under the control of the user's MUA.

Hi Robert,

Taking a step back, at a minimum, based on the history of the mail systems in my multi-network 30+ years of design, developing, marketing and support experience of mailers (MSA/MDA/MTA, gateways) and readers/writers (MUAs), again, at a minimum, all that was needed were:

  From:
  To:
  Date:
  Subject:

At a local, centralized level, you don't need any other header. In other words, if you were brand new in writing any mail system, not necessarily RFC-based, that is what you will begin with in your UI.

Only when we began to "network" mail systems, added additional "Network Control Lines" were helpful and fundamentally, the goal was to be able communicate back and forth (replies). Back in the day, if you couldn't send mail directly, perhaps it was more costly, i.e. toll calls, you routed the mail via your "hubs" during non-prime time hours.

These headers were the common denominator. Everything else was "optional" and even the subject line can be blank and incidentally, what are required by RFC5222 are the From: and Date: headers. The To: was relaxed in RFC2822. That's it!

At the end of the day, we are talking about three different things:

 -  Transport Requirement (minimum basic communications framework)
 -  Administrator Requirements (Operator/Local Policy Options)
 -  End User Requirements  (Offline, Online, Hybrid MUAs)

The IETF has been mostly concerned about the transport protocol. Making sure all the SMTP, POP3, NNTP, IMAP systems can communicate. While implementation details and end-user requirements has always been challenging and in conflict over the years (because each vendor has a "preferred" way of doing things), we try to extract the commonality by minimizing conflict of interest. I call it "Cooperative Competition."

The key thing to remember is the main goal of this mail tool -- to communicate to someone and to allow for an respond mechanism.

Look at the MUA, there are various types; OFFLINE, ONLINE and HYBRIDS. From a UI, standpoint, the above headers would be the first headers to add to your interface. They are what most users will need and what most people are familiar with.

So the question is what additional headers are needed and why?

Well, we do have the "Reply-ID" and by design, it overrides the "From:" for a response. It works well for One to One mail systems, and you know the history of how it is been leveraged in One to Many, Group-ware systems, i.e. Mailing list.

Is the Message-ID required? Who adds it? It is dependable as a "Dupe Detector?" It probably is, but our system does bot depend on this header for dupe detection, Our system has a proprietary dupe detection mechanism because its not just about a RFC based mail storage system. Someone or something can post a duplicate message online before any RFC headers are added which by the way are only added when they exported for an RFC-based network!! :)

DKIM-Signature also leaks information. USer-Agent, X-Mailer, and basically the X-xxxxx headers do, especially the "Anti-Spam" ones. There are slew of headers that leak information about a transaction.

Anyway, I think we can have a BCP that is basically a table of all the headers accumulated over time, with a new view of RFC2119 level of compliance with technical information, common implementation and interop details. Just start with all the headers in your message, sorted:

Archived-At:
Authentication-Results:
Cc:
Content-Transfer-Encoding:
Content-Type:
DKIM-Signature:
Date:
Delivered-To:
Errors-To:
From:
In-Reply-To:
List-Archive:
List-Help:
List-Id:
List-Post:
List-Subscribe:
List-Unsubscribe:
Message-Id:
Mime-Version:
Precedence:
Received-SPF:
Received:
Received:
Received:
Received:
Received:
Received:
Received:
References:
Sender:
Subject:
To:
X-BeenThere:
X-Mailer:
X-Mailman-Version:
X-Original-To:
X-Spam-Flag:
X-Spam-Level:
X-Spam-Score:
X-Spam-Status:
X-Virus-Scanned:

There is a lot of junk there.

But to answer your MUA question, which header(s) it has control of.

The short answer is none. Unless, you want to say the Reply-ID is probably an important header the MUA is inserting into the transaction (if the user prepared it). But as we know, the MUA doesn't really have control of it in many MLS (Maiing List System/Server).

Think about it. By the time I get your message from my hosting server, the MDA, it is already authorized mail in order to accept it. Many filters are applied and by the time the import takes place, it has two ADMIN (and relatively recent an USER) options at my server:

  (o) Preserve MIME mail (Keep RFC intact)
  (_) Convert to Wildcat! Format

The default was to convert to the proprietary format of the box. So you have to set it if you want the RFC overhead. Only with the advent of the OFFLINE mail readers and greater WYSIWYG (HTML/MIME) needs, users required the preservation of "raw" RFC mail as it came in. So by the time the host server passes it to my reader during a mail pickup, all I have to make sure is set the above headers in a reconversion back to simplified RFC MIME 1.0 format. That is OFFLINE. In an ONLINE MUA (i.e. web browser, Telnet, etc), the backend has full control of the display. It has the freedom to do much more without compatibility conflicts. No conversion back to RFC necessary.

Of course, it had become more complicated when you want the NATURAL "Reply" button to do the right thing. But before List-ID became popular with the MLS, many MUAs did not support this. So that is one reason the Reply-ID was added with the list address. If the List-ID was prevailing early on, perhaps the MLS would not had redesign to use the Reply-ID. Now the the List-ID is widely popular, perhaps in the next MLS update, we can disable using the Reply-ID out of the box.

But the point is, that no other header is simply not required and I think, at best, because we have many disciplines to deal with, all we can do is go thru all the headers and provide guideline regarding the MUST, SHOULD and MAYS for current and future developers. Its good to know what the "big guys" are doing, but that doesn't necessarily mean it should be made into a IETF mail standard or mandate. In fact, we have to be careful of the potential conflict of interest.

I know our system is probably unlike others, and we can state we are only dealing with pure RFC to RFC networking, sure, but the reality is that its not always that cut and dry. There are an awful lot of local proprietary processing that can do anything to the mail, and the the time the user sees it, they might be just the above headers for the most part, and perhaps a MODIFIED body with a special BODY HEADER:

  From: Hector
  To:  Robert
  Date: ...
  Subject: ....

  *THIS MESSAGE WAS DKIM VALIDATED BY SO AND SO and other MSA/MDA,
   User information tacked on as a BODY header*
  *To see Authentication/IP information, click here, password required*

  My actual message.

  ---
  HLS


I actually did this for a NNTP Bridge/Gateway (WCLEX, Wildcat! Live eXchange http://opensite.winserver.com/wclex) I wrote for Microsoft when they deprecated the Microsoft NNTP Newsgroup support servers for a MSDN WEB-BASED system. Fortunately, MS provided the .NET-based API hooks and WCLEX provided a great transition tool. But what it did was to add the BODY HEADER to show some the Web-Based User Data points, i.e. number of replies, how many stars you have, etc because, of course, the MUA was not ready for these type of new interfaces.

--
HLS


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

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