On Feb 5, 2010 at 14:10 -0500, Chris Lewis wrote:
=>We've more-or-less reset the discussion to emailing ARF reports (most people
=>are satisfied with emailed ARF reports without other options)..
+1
=>I think we need to reset it again, yet further. The reason being that the
=>discussion touches too many pieces at once, and the security/practicality
=>issues of remotely-specified ARF destinations are obscuring the fact that why
=>bother with specifying them at all? Let the user's ARF handling service do
=>it. We need to very specifically disentangle MUA/MTA functions and simplify
=>yet again.
+1
=>So we get rid of inband abuse report instructions altogether.
=>
=>I propose two specifications:
=>
=>1) a spec for MUAs that says nothing more than "if the TiS button is pushed,
=>the selected email[s] get sent in ARF format to <some standard address>, via
=>the usual mail submission methods it uses". I recommend, so as to not
=>stomp/overload existing naming conventions, that it be
"arf(_at_)arf(_dot_)<domain in the
=>RCPT TO that reached the user>". Or, "ar", or whatever. I don't care what it
=>is (if you really don't want to use "arf") as long as it doesn't collide with
=>existing conventions and standards. Eg: IMAP/POP/SMTP/SPAM et. al. are
=>unacceptable.
=>
=>This also allows <domain> to use DNS to map them to somewhere else entirely.
-1 for having a "standard" address. Let sites decided. Some might want
them to go to abuse@, spam@, devnull@,
spam-training(_at_)anti-spam(_dot_)vendor(_dot_)
I have deleted the message, but Thursday someone (you?) had a post with
regard to having the final MTA insert a header with the ARF reporting
address? I like that idea, but would replace MTA with MDA. An MTA
never really knows if it is the "last" MTA, where an MDA does.
The MDA should be within a trust/security zone of the MUA user since
they are retrieving their message from it. (Doesn't matter how they
retrieve them be it webmail, IMAP, POP, fetchmail, SSH, NFS, pigeon.)
The MDA could be made to insert different reporting addresses in a
hosted domain environment thus allowing mailDomainA recipients use
reportingAddressA and mailDomainB recipients use reportingAddressB.
I get the feeling people are still trying to tie the message retrieval
MUA configuration with the MUA's submission configuration. Why? Is it
a bad assumption that the MUA is not already configured to send messages
via some MSA? If not, then use the MSA. (Clients like Thunderbird
would need to pick the right MSA for the "identity/persona" when users
have multiple MSA systems configured.)
So, if companyA/universityB/hostingCompanyC/dogAndFamilyHobbiestD want
to let their user's use a TiS button, they insert[1] the TBDheader with
the reporting address for the recipients domain. (Note that
fred(_at_)example(_dot_)com and wilma(_at_)example(_dot_)net might get
delivered into the same
folder of the message store, but the MDA could be configured to inserted
different reporting addresses for the different recipient domains.)
When the user click the TiS button, the MUA sends the ARF report using
the MSA that it has configured for the user's identity/persona that
matches where the message was retrieved from. (Note how this even works
for webmail based MUA.)
Where I see my suggestion break down is on the deliverability of the ARF
when a MUA is configured to retrieve message from one message store
(companyA), but use ISP-b's MSA. ISP-b might reject/quarantine/discard
the ARF if it is scanning it user's out-bound mail and thus the ARF
reporting address for companyA never gets the user's message. (So, if
companyA wants to get their user's ARF messages, they needs to be
running a MSA that their user's can use, tell them to use, and require
them to use. :)
1: I think having the option of reporting back up the delivery chain
several hops currently creates to many potential issues. Let just start
with the MDA removing any existing headers and putting the one that works
for user's "local" address.
--
***********************************************************************
Derek Diget Office of Information Technology
Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/
***********************************************************************
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg