Charles Lindsey wrote:
Somehow, MUAs need to be aware of which lists the user is subscribed to if
they are going to do that sort of thing.
I think which keeps getting in the way here in molding ideas is that
much of it is based on online MUA access which does not always match
Offline MUA access, and there is a HUGE leap in faith that the backend
is going to be transparent and have no or lesser role in the filtering
(good or bad) process.
In short, we need more protocol consistency here.
With Online MUA access, the backend complete control what is going to
be displayed to the user. It can change the display at a single source
location and have it applied to all Online MUA access.
With Offline MUA access, it has no control on how the backend moves
its mail. It can a gating and/or conversion process. But in the end,
the Offline MUA when talking internet mail, has to conform to RFC
822/2822/5322. The assumption that it will be a simple RFC to RFC
passthru would be a bad engineering assumption.
We have 5-6 different ways to access and display mail. There are all
sorts of ideas to consider that could apply to what you want.
Again, the Online MUA has no say in whats shown. The backend has
complete control here.
The offline MUA, talking about the common RFC-based offline MUA, can
only "programmed" to see what you want it to see by altering what is
commonly displayed today, the three fields are:
From:
Subject:
Body:
Today, the MLM adds a [LIST-NAME] for the Subject field. At this
point, mail system designers will have an ethical problem with
altering the FROM:. The MLM also alters the both with footers (some
do headers as well).
To depend on a LIST-ID offline MUA display would be a bad dependency
to count on.
However, to illustrate how a backend can do something things to help
support the OFFLINE MAU, as we did in a recent project for a Microsoft
Web Mail to NNTP Bridge for NNTP Reader support,
http://opensite.winserver.com/wclex/default.wct
there were alterations done by the NNTP bridge to better emulation of
the online view of mail via an offline view of mail. This was
required to help restore the TRUST or VALUE of the online message view
via an offline view.
For example:
Via Online MUA, the from might be:
From: Joe Smoe [MVP]
From: Tom Sawyer [MSFT]
The ROLE bit is part of the user database and is displayed that way.
When downloading the mail via the NNTP Bridge, that From: field info
is lost.
So the NNTP Bridge when it does the backend to RFC 2822/NNTP
conversion, it checks the user status and alters the From so it can
show these tags.
There are other poster "Trust and Value" factors that is shown via the
Microsft Web-based Forums view of the mail, such as:
# of post made
# of Stars Earned
The NTTP-bridge optionally provides information by including it the
2822.BODY at the top of the message view.
So the point is the backend can do a few things to help support the
offline view of mail as far as DKIM TRUST is concern. This is not
protocol material, but more to the point that we need to not lose
focus we need to work out how the backend deals with DKIM first and
not depend on the OFFLINE MUA to do this for us.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html