Earl Hood wrote:
IMHO, if robust anti-spoofing is desired, MUA support is needed.
MUAs have much greater capabilities of displaying verification results
to the end-user versus anything an MTA can do.
I'm not sure I agree with this, simply because there are many forms of a
MUA. I think what is needed are new 822 header standards to offer
"material" to better train the MUA presentation of information.
I agree current MUA "presentation" is out-dated and its based on the four
fundamental common message header fields:
FROM:
TO:
DATE:
SUBJECT:
These are common among all mail formats.
There needs to be new ergonomics involved here and for a store and forward,
offline RFC-based MUA, I can see your point, where they can do more offline
MUA processing. Some already do so. But for a online based MUA, such as
WebMail, and even a cell or PDA, the online host and backend can do a lot
more for its these type of user bases.
Atleast for us, since have six MUAs ways a user can pickup/send mail, we are
always confronted of provided a consistent behavior:
- ANSI/VT100 (direct dial or telnet) console connectivity
- Dedicated Windows GUI Frontend
- WebMail
- POP3 for RFC based offline readers
- WAP for Cells
- QWK/OPX/BW (offline mail packets, P2P-like)
I don't think I am speaking for myself but in general for any MUA or mail
system vendor who have various forms of mail clients.
For consoles, this would be a backend doing the work and possible providing
DKIM feedback to the user. We will have a small screen "real estate" issue
(typically 80x24) displays to deal with.
With dedicated GUI frontends, it offers excellent GUI ways to present, the
issue here will be "how to pass" the information to the GUI. Authorization
Header Only?
With WebMail, new HTML template presentations will be need. Maybe a real
estate issue depending on how mail is presented (frames, for example, limit
your view window).
For POP3 clients, which is what I think you are talking about and I think
presents the majority of the MUAs, the backend can provide information via
the headers. But this is where the RFC based MUA needs to be trained to
understand and present this information.
For PDA/cells, well, this is 100% backend provided. Definitely a small
screen real estate issue.
For QWK/OPX/BW, this is similar to dedicated user applications such as the
GUI or RFC based MUA, these QWK/OPX/BW based readers will need to be
updated. Small market, but overall, vendors are using custom clients more
and more to differentiate themselves.
Of course, in all cases, the backend can serve ALL MUAs by writing directly
to the body of the text. But IMO, that may be borderline ethical and a very
bad idea overall to open Pandora's box to begin changing text presentation.
It is considered a taboo and if anything is added, it is usually footer
related junk and even that creates a soar note with many! I recall the
"tear line" wars where Offline Mail Reader authors and Mail
Distribution/Gateway author had vicious "stripping" battles over what part
of the mail was considered sacred, what part of the body was considered USER
OWNED text and WHERE did it end. Adding a footer opened the door, MUA
adding "brag lines" disguised as user signatures opened the door wider. An
MTA adding body to the top so that it is the first thing seen by the user
will really raise eyebrows - well, atleast mine. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org