On Feb 5, 2010, at 12:01 PM, Chris Lewis wrote:
Steve Atkins wrote:
Of those, the only thing that's actually associated with the inbound mailbox
is the incoming mail server.
As you suggest, key it to "feedback(_at_)feedback(_dot_)<incoming server
name>".
Yup.
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.
From the perspective of code base, checking for an A record for
"feedback.<incoming server name>" would be simpler. The MTA doesn't need to
use DNS to deliver, and you really don't want the MUA to be establishing
direct connections anyway. Fixed route to whereever in the MTA.
So an A record for feedback.imap.example.com to demonstrate existence, and an
MX record for the same to actually control delivery.
So the MUA can lookup the A record for feedback.imap.example.com to enable the
TiS button, and when the TiS button is pressed it just sends email, using it's
normal submission server, to
feedback(_at_)feedback(_dot_)imap(_dot_)example(_dot_)com or something like
that, and the smarthost delivers that just as it would any other email.
If the MUA checks for the A record when fetching mail, rather than when
displaying it, it'll all work when I'm on a plane too. Yay for
store-and-forward!
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg