Re: [Asrg] Adding a spam button to MUAs
2010-02-05 13:58:36
On 2/5/10 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).
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".
It seems doubtful that any MUA will be able to properly determine
origination's of a message without greater insight into their receiving
administrative domain's architecture. Nor will Authentication-Results be
bound to specific accounts once placed into a recipient's mailbox. Any
meaningful feedback, especially those related to source IP addresses,
can only be emitted by the receiving administrative domain. In
addition, without some type of secured mechanism, MUAs can not safely
submit any end user feedback beyond their receiving administrative domain.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] Adding a spam button to MUAs, (continued)
- Re: [Asrg] Adding a spam button to MUAs, Ian Eiloart
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Steve Atkins
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Steve Atkins
- Re: [Asrg] Adding a spam button to MUAs, Chris Lewis
- Re: [Asrg] Adding a spam button to MUAs, Steve Atkins
- [Asrg] MUA/Operator reporting address (was Re: Adding a spam button to MUAs), Dave CROCKER
- Re: [Asrg] MUA/Operator reporting address (was Re: Adding a spam button to MUAs), Chris Lewis
- Re: [Asrg] MUA/Operator reporting address (was Re: Adding a spam button to MUAs), Dave CROCKER
- Re: [Asrg] Adding a spam button to MUAs,
Douglas Otis <=
- Re: [Asrg] Where to send the ARF report, was Adding a spam button to MUAs, John Levine
- Re: [Asrg] Where to send the ARF report, was Adding a spam button to MUAs, BOBOTEK, ALEX (ATTCINW)
- Re: [Asrg] Where to send the ARF report, was Adding a spam button to MUAs, Dave CROCKER
- Re: [Asrg] Adding a spam button to MUAs, Daniel Feenberg
- Re: [Asrg] Adding a spam button to MUAs, John Levine
- Re: [Asrg] Adding a spam button to MUAs, Dave CROCKER
- Re: [Asrg] Adding a spam button to MUAs, John Levine
- Re: [Asrg] Adding a spam button to MUAs, Steve Atkins
- Re: [Asrg] Adding a spam button to MUAs, Dave CROCKER
- Re: [Asrg] Adding a spam button to MUAs, der Mouse
|
|
|