On 4/25/2015 11:34 AM, Stephen J. Turnbull wrote:
My personal opinion is that, on the contrary, people are already way
too quick to discard proposals simply because they involve changes to
MUAs. Of course, the reality that this is an IETF WG, and what we can
do that has effect with high probability is change wire protocols.
MUA presentation is outside of our bailiwick, ......
Stephen, we (SSI) have the following MUA and/or interface points that
is still supported:
o Telnet/Dialup console/text-based, 80x25 Vt10x/ANSI interfaces, the
display fields are generally fixed length and short, WCX P-code language.
o Web-based mail Client. WCX P-Code Language.
o Native GUI Mail Client. MFC C/C++
o RFC-based POP3 server interface. MFC C/C++
o RFC-based NNTP server Interface. MFC C/C++
and a RPC-based client/server MAIL API with multiple languages
support, like sysop editor tools written by us and 3rd party
developers. It contains a fixed TMsgHeader structure that allows for
any other client to be written but more importantly represents a
commonality between all integrated parts and among heterogeneous mail
network systems. All systems have a common denominator:
From:
Date:
To:
Subject:
-------
BODY
Today, there are only two requirements in the RFC 2822/5322 format;
From: and Date: It was relaxed from RFC822 requiring the To: field as
well.
Lets not assume that all systems are RFC x822/5322 based. Local policy
can transform the message and as long as it is not a passthru and it
has reached its final destination, the backend does have a lot of
security conscious controls. That has been the design rule of thumb
since I wrote Silver Xpress (and offline MUA for Fidonet/Internet) in
the early 80s. In our Wildcat! Mail Hosting package, Preserving MIME
is an SYSOP option, not a requirement for users. The only reason it
is now enabled more, is because users are more multi-media ready. MUA
display rendering was lost in the regeneration of RFCx822/5322
messages so preserving MIME helps with the WYSIWYG (WIZ-ee-wig) concept.
Also consider that RFC message overhead is getting whack, over bloated
and wasteful. I have sysops who will pull the MIME and HTML and
provide a pure text transformation. If the special user has a
Preserve MIME need, a request a made to the operator who will decide
to set it or not. 3rd party developers have written WCX tools to
help operators to make it more as a default today.
...... and nobody really has a
good way to get ideas for MUAs broadly implemented the way we can
influence MTA implementations.
Its far easier to single source the solution at the backend threat
entry points.
Lets not forget that the Receiver (including the Mediator receiver,
not just the end-user receiver) also benefits by reducing the
fraudulent mail and blocking them at the door. Its not about just
protecting the originator or the end-users.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
