Re: Spam sent from compromised (web)hosts vs botnet spam

On 2013-03-21 09:48, Chris Lewis wrote:
> On 13-03-21 12:20 PM, Dan Oetting wrote:
>> On Mar 21, 2013, at 2:51 AM, "Emanuele Balla (aka Skull)" <[email protected]> wrote:
>>
>>> The side effect is the colo doesn't see any significant traffic, as the
>>> only traffic going in and out the machine they host is return traffic
>>> (non-tunneled going IN, tunneled going OUT). So, unless you (as colo)
>>> know what to look at, there's nothing triggering your alarms…
>> Many years ago, i suggested a simple solution. In cases where traffic is presumed to be abusive such as an SMTP transaction involving multiple invalid accounts, send back an ICMP error that network providers would be able to watch for as a hint to what traffic they should be monitoring. Since these reports would be returning in real time, automated monitoring tools could be developed to snapshot the transactions that triggered the report so the provider would have all the evidence from their own network if they chose to look into it. The tools themselves could even do much of the preliminary analysis looking for common patterns and triggering alarms when problems are discovered.
> Many years ago, RFG did something similar.  Spam traffic inbound to him
> would result in a remote syslog back.
>
> Then we had an unapproved (aka "unknown to the guys authorized to run
> email servers") MTA go "multi-stage open relay".
>
> EVEN THOUGH the remote syslog text was sorta clear as to what it was (in
> an RFG-esque sense ;-), the rsyslog flood and resulting consternation
> churned up many manhours in network and corporate security groups, and
> was about to trigger a formal LE complaint, until _I_ found out about
> it.  By accident...
>
> "oh", I sez, "I know what _that_ crap is, I'll deal with it".
>
> RFG later blamed it on Dave Rand.
>
> [RFG doesn't like me reminding people of it.  He should be glad.  I
> saved him from a sticky time with the cops.]
>
> You don't want to be blamed for this, do you? <grin>
>
> This'd have to be some sort of "opt-in" service.  IOW the network
> provider has to somehow advertise "I want this feedback ...".

If we wanted to get serious about this type of implementation, an SMTP 
extension could do the trick.

Perhaps a new ABUSEID command could be used by the sending machine, 
after the EHLO and before the MAIL FROM, to provide a unique ID for the 
transaction on all outbound messages sent, in the form of ID@domain, 
where ID@domain must be unique.

A complaint could be generated by attempting to send mail to ID@domain 
as an email address, but at the RCPT TO stage, using RCPT ABUSETO: 
<ID@domain> listed above. DATA could be entirely optional, could be a 
ARF or regular bounce message, or it could be just comments for 
user-initiated complaints.

This would give a fair amount of flexibility, senders could use 
@abuse.example.com if they want abuse reports to a specific server, or 
just @example.com if all of their MXes can accept abuse reports, or even 
@mx2.example.com if each MX handles it's own abuse reports.

-- 
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

-
This is the asrg mailing list.  To change your subscription settings, see
http://lists.services.net/cgi-bin/mj_wwwusr/domain=lists.gurus.org