On Feb 5, 2010, at 11:15 AM, Chris Lewis wrote:
Steve Atkins wrote:
Okay, but "arf" is so short ;-) And we have to get everybody else to use it.
"feedback" works too.
The only setting that the MUA is likely to have access to is the name of the
IMAP or POP3 server. As IMAP and POP3 are not name-based, the entry there
could easily be domain.com, mail.domain.com, imap.domain.com or
pop.domain.com or smtp.domain.com or even www.domain.com.
It has the default name used in inbound email, as well as (usually) an email
address used as a userid. Per delivery server. It may even be able to see
the rcpt to (or the MTA could "help". Oh, never mind).
Lets look at a concrete example from my MUA
Account type: IMAP
Description: Fruitbat
Email address: steve(_at_)blighty(_dot_)com,
steve(_at_)wordtothewise(_dot_)com, steve(_at_)word-to-the-wise(_dot_)com, ...
Full Name: Steve Atkins
Incoming Mail Server: mail.wordtothewise.com
User name: steve
Password: *******
Outgoing Mail Server (SMTP): mail.wordtothewise.com
Of those, the only thing that's actually associated with the inbound mailbox is
the incoming mail server.
In the mail itself, without parsing Received headers the only relevant headers
are:
X-Original-To: steve(_at_)blighty(_dot_)com
Delivered-To: steve(_at_)m(_dot_)wordtothewise(_dot_)com
To: Anti-Spam Research Group - IRTF <asrg(_at_)irtf(_dot_)org>
Message-ID: <4B6C7000(_dot_)5060207(_at_)dcrocker(_dot_)net>
So the only data I'd have to work with as a self-configuring plugin would be
the IMAP server hostname, mail.wordtothewise.com.
One option is to have the MUA "use some heuristic to find the 'domain'
associated with that hostname", but past experience with SSP suggests that
it makes people point and laugh at you and start mentioning things like
imap.aardvark.us.com.
Another would be to prepend "feedback." to the imap server name - so do an
MX lookup for "feedback.imap.domain.com" to discover whether it's to enable
the TiS button. That'll either need a DNS record added for every possible
name for the IMAP server, or accept that it won't autoconfigure unless the
recipient uses the name for the IMAP server you're expecting, either of
which seems reasonable.
(That doing MX lookups is not something that MUAs typically need code for,
and that isn't supported by base API, is a minor issue but worth mentioning).
Agreed. I suspect many MUAs are completely incapable of doing direct to MX,
and don't do MX lookups. See other suggestion, where I say "Use normal
submit mechanism".
Yeah, the usual submit mechanism is the way to go for actually sending the
reports.
But a critical bit of UI design is that it should be clear to the user whether
something will happen, or not. So for this to be workable the MUA needs to be
able to configure itself to show or hide the TiS button (or grey it out, or
whatever UI idiom you like).
The charm of using an MX record to configure this is that the MUA can do an MX
lookup to know whether to show or hide the button. That's pretty clean, and if
I were coding an MUA I'd be happy to do it that way, but it's not necessarily a
_trivial_ thing to add to a codebase, especially via plugin, so it's worth
considering.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg