ietf-asrg
[Top] [All Lists]

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>