Tony Hansen wrote:
Charles Lindsey wrote:
Actually, the best suggestion I have seen is that POP3/IMAP servers should
see to the matter. I realise that might not be easy for POP3, but IMAP is
already so bloated with extensions that another one would hardly be
noticed :-( .
Yes, I also shuddered slightly when I suggested it. But it seemed to fit
the most with what was going on. IMAP/POP servers are what the MUA is
talking with; they *are* the representative for the MDA; and the MUA is
*already* talking with the IMAP/POP servers, so could easily ask for a
bit more information.
We can write it up and see if it flies. Here's how it could look:
IMAP
x CAPABILITY
x CAPABILITY Authentication-Results=isp.example.net
x OK CAPABILITY completed
POP3
CAPA
Authentication-Results=isp.example.net
Can we make the new capability string longer :-)?
In both cases, the isp.example.net is the authserv-id put in by *this*
MDA system.
I am slightly confused: Is there just one MDA delivering all messages to
the user's inbox?
What about a clustered case when there are multiple LMTP servers?
As a side note: "Authentication-Results=isp.example.net" is fine
syntactically, but you would have to make sure that people don't put IDN
domains in there - non US-ASCII characters are not allowed in <atom> and
CAPABILITY strings are <atom>s.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html