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