Steve Atkins wrote:
On Dec 8, 2009, at 9:35 PM, John R. Levine wrote:
MUAs these days can handle multiple inbound and outbound accounts, with the
various accounts only loosely connected. I have users who pick up their mail
here, but send via their ISP's mail server and vice versa. If you were to send
the report via SMTP you might well send it to someone who'd never seen the
message before.
So the report needs to be tied to the inbound account. For IMAP accounts, a
simple approach is to have an IMAP spam folder, and move the message there.
AOL does this in their IMAP access, so I suppose that makes it a de-facto
standard.
It's also already supported by some MUAs. Mail.app for one. Sorta.
If a server fetches mail from remote IMAP or POP accounts, it has to
annotate those messages in order to recognize them and route them to
the corresponding abuse-box. This may require to introduce a new (not
necessarily standard) header field.
The general purpose way would be for the receiving MX to embed a reporting
address in a message header such that the MUA would then forward the message to
when the user hit the button. The only functionality it requires from the MUA
is the ability to send email, which almost all MUAs already support.
We may reuse the authserv-id's from Authentication-Results header
fields that the user trusts. This method implies the MUA has validated
them, e.g. against the Received fields, and is thus preferable than
using, say, Delivered-To. It provides for sending a report to multiple
places, unlike the IMAP folder method.
Once the MUA knows which domain(s) take the responsibility of
delivering a given message, it would be advisable to lookup an address
list on the DNS and only resort to prepending "abuse@" if no record is
found. This additional level of indirection brings a twofold
advantage: on the one hand the MX has a chance to use a different
address, e.g. abuse-to-be-forwarded(_at_)example(_dot_)com; on the other hand, a
third party can monitor abuse reports even if example.com is also the
sending domain. To wit
_abuse IN TXT
"abuse-tbf(_at_)example(_dot_)com,abuse-D27(_at_)certifier(_dot_)example"
Example.com should do similar lookups when it forwards the report to
the sending domain, eliding duplicates. Certifier.example, as part of
its activity, should check that its agreed-upon addresses are present
in the records of its certified domains.
Alternatively, synthesizing addresses from VBR-Info header fields may
result in a similar set of recipients. However, separate validation
would be needed to avoid sending the report to untrusted senders.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg