[Asrg] Meta channel, not bounces

[Alessandro Vesely]

Seth wrote:
> "Chris Lewis" <clewis at nortel.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.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.