Lisa Dusseault wrote:
I'd like to do a more explicit consensus call now to nail this down.
I've tried to identify the major points of attraction rather than every
variant, to see where people are leaning. Please reply with one of
these options, a variant, and explanation if you like:
A) auth-header to not require any feature advertising or auto-configuration
B) auth-header to normatively RECOMMEND some kind of feature advertising
C) auth-header to normatively REQUIRE some kind of feature advertising
"C" for having a reason for living (implementing it). Otherwise,
whats the point? "A" will further create fuzzy unknowns about trust.
While B is the middle ground, it is just as bad as A.
Separately, the unspecified feature advertising or auto-conf should be
(choose one or more):
1) IMAP Capabilities advertising
2) E/SMTP capabilities
3) IMAP annotations
4) Something else
Thats just it. Whats it for?
The only use I see for it is to pass intra-process (internal) state
information, i.e. so that a 2nd trusted process doesn't have to
"re-do" whatever the first trusted process did. For an Internal MUA
(a trusted process), it can be used for state information.
Why and When would a offline MUA, for example, trust and make use of
this information? In terms of DKIM, does it replace the need for an
MUA to do DKIM verification?
Hector Santos, CTO