Re: [Asrg] Meta channel, not bounces
2009-01-16 06:10:45
Seth wrote:
"Chris Lewis" <clewis(_at_)nortel(_dot_)com> wrote:
It is technically possible (in fact trivial in many cases) to
instrument a MTA to automatically generate and send ARF in real
time. Even assuming that the MTA can figure out the _right_ place
to send the ARF, it becomes a WMD.
Yeah, standardizing arf(_at_)example(_dot_)com can generate much confusion...
Imagine, if you will, everybody did it. Some moderately sized site
gets a reasonably prolific (single) infection, and spews out a few
million viruses. You're expecting the site's MTAs to handle a few
million ARFs, when only one _should_ suffice.
If one suffices, then the site immediately closes or blocks the
infected machine, and it doesn't get all that many notices.
If I understood Chris' point, there would be a few millions different
MTAs that have been reached by the site's fallout. None of them knows
whether anyone else already reported that notice. However, the number
of notices is linear with the number of viral messages sent. If the
site has been able to send so many messages, it might (should?) also
be able to receive so many notices. Unlike DSN (which existed before
their format was standardized), the response should be machine readable.
Reporting to a DNSBL service, as Franck suggested, might overcome that
risk. In facts there are monitoring services that do such kind of
service. However, the server may submit its report to a different
organization than the one(s) subscribed by the client. Unless they
exchange data, thus forming a global distributed organization, report
delivery would be at stake. Unfortunately, RIRs don't do that.
It would be better to create a new protocol for the ARF responses
(even if it's just email on a new port, though I'd include some
extensions to allow for "Report of virus emitter on <IP>" "I already
know" "QUIT")
"I already know" requires a strong standardization of the reasons.
Probably keying on faulty IPs can drastically reduce the number of
repeated messages. For ARF reports, the receiving site doesn't have to
reject or bounce what it doesn't want. Having two DATA commands, one
for the machine readable part and a rejectable one for the original
body, can save bandwidth; but currently ARF does not provide for that.
Something new is required in order to let the client and server MTAs
become aware that they both support ARF reporting. Perhaps they should
negotiate what reports they are interested in, which ones with full
bodies, for which types they only want one, etcetera.
_______________________________________________
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] where the message originated, (continued)
- [Asrg] Meta channel, not bounces (was: Re: where the message originated), Alessandro Vesely
- Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated), Rich Kulawiec
- Re: [Asrg] Meta channel, not bounces, Alessandro Vesely
- Re: [Asrg] Meta channel, not bounces, Rich Kulawiec
- Re: [Asrg] Meta channel, not bounces, Chris Lewis
- Re: [Asrg] Meta channel, not bounces, Franck Martin
- Message not available
- Re: [Asrg] Meta channel, not bounces,
Alessandro Vesely <=
- Message not available
- Re: [Asrg] Meta channel, not bounces, Rich Kulawiec
- Message not available
- Re: [Asrg] Meta channel, not bounces, Chris Lewis
- Message not available
- Re: [Asrg] Meta channel, not bounces, Chris Lewis
- Message not available
- Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated), Rich Kulawiec
- Re: [Asrg] Meta channel, not bounces, Chris Lewis
- Re: [Asrg] Meta channel, not bounces (was: Re: where the message originated), SM
- Message not available
- Message not available
- Re: [Asrg] where the message originated, Chris Lewis
Re: [Asrg] where the message originated, Franck Martin
|
|
|