Re: "Principles" of "Spam-abatement"

Robert G. Brown wrote:
> On Wed, 17 Mar 2004, Dean Anderson wrote:
> > On Wed, 17 Mar 2004, Robert G. Brown wrote:
...
> > >  b) Return the complaint as mail to postmaster of the originating
> > > network with a special error code that would allow it to be counted and
> > > digested easily.  One doesn't want to create a new kind of DoS attack on
> > > postmaster, and making it easy and automatic to return a complaint COUNT
> > > of some sort on otherwise identical content can help prevent that while
> > > making it easier for SP admins to deal with mounting complaint levels.
> > This is possible now, and SpamCop does this. The problem with SpamCop is
> > that they alter the message, making it useless.  SpamCop complaints are
> > routinely deleted as a result.  I usually forward them on to customers
> > with an FYI that we don't consider such to be a valid complaint, but they 
> > may want to be aware of what someone said.
>
> So what you are saying is, that this CAN be done and even is being done,
> but it isn't done correctly and consistently and isn't widely available.
> I agree.  In fact, I think that this is potential work for the IETF --
> define a way for it to be done correctly and consistently (which
> wouldn't be too difficult, I imagine) via a protocol.  Then SpamCop
> could fix their tool, SpamAssassin could add a compliant interface,
> Joe's Spam Seal (not yet written) could be written to comply with the
> protocol and abuse@ or postmaster@ addresses could actually AUTOMATE a
> response process based on consistent completely reported problems.  This
> lowers their cost and makes it easier and more likely that they'll take
> effective action.
We are actually soliciting volunteers in the ASRG specifically for this 
kind of work - protocols and formats for abuse reporting to be discussed 
in a closed subgroup separate from the main ASRG list 
(http://asrg.sp.am/subgroups/abuse_reports.html). So far, we haven't 
gotten much interest :(

> As you say, if you get insufficient information, there is little that
> you can do even with the best of will as the manager of an ISP with too
> little time and too many things to fill it.  You probably don't have
> time or energy to engage in the "please resend your complaint with the
> full header and message attached" game (known to administrators
> everywhere, and not just in regard to mail:-).
If part of the protocol and format states that specific information is 
required, you can discard non-compliant reports solely on the basis of 
being non-standard. Or you can just discard them :)
> > >  d) Take steps to ensure that SPs run a postmaster address, and maybe
> > There is already a BCP for this. Rarely is this a problem.
>
> In the US.  Try hitting the postmaster of 7.197.76.17, and good luck
> communicating with the postmaster of the brazilian relay in my previous
> reply.  (This is picking nits -- actually I agree that what can be done
> largely has been done, but it would be lovely to be able to extend
> overseas with a little more ease, to get a bit poetic...;-)
There has been a proposal in the ASRG from someone about storing contact 
data for abuse departments in the rDNS tree the same way there is a 
responsble RR type for forward DNS. So far hasn't seen much interest...
> > > come up with things like Jeff Chase was proposing to continuously
> > > measure their responsiveness to spam/virus-class bounce messages and
> > > globally blacklist the worst (least responsive) offending SPs.  Etc.
> > How would you define "responsiveness"? Does it mean getting an 
> > auto-responder message?  Does it mean getting a message saying something 
> > had been done?  You cannot give out certain information about customers.  
> > Basically, all you can do is send an auto-responder message and a notice 
> > that the ticket was closed.  That doesn't indicate what happened, nor does 
> > it indicate who the spammer was, or if the ISP agreed they were a spammer.  
> > Sometimes the action is obvious if, say, a website disappears. But how do 
> > you know they took action against a dialup customer?  You can't.
>
> No, I think that responsiveness has to be measured by the level of spam
> reported as originating within the site -- results.  I don't think this
> is that difficult, actually.  Vernon pointed out that once earthlink got
> serious about controlling spam, the reduction in traffic was very
> apparent.
>
> If the IETF has any role here (and it may not) it might be to codify the
> process of blacklisting ISPs that aren't serious as they are revealed.
> You've pointed out several times that abuse of blacklists is pretty easy
> as things stand.  It shouldn't be.  And people like you who have bad
> experiences with the previous non-process should be the ones who end up
> agreeing that whatever schema that might be proposed is fair and
> equitable and not likely to punish ISPs who are doing their best.
A general BCP on blacklists and how to properly apply them would be 
higly useful. Another BCP on how to properly manage a blacklist would be 
useful as well. Both have been floated in the ASRG, no one volunteered :(
> > > Right now enabling SPs are insulated from any kind of RFC-based
> > > responses or complaints about spam because MUA's and MTA's have no
> > > predefined protocol for generating such a response in a constructive
> > > way.  
> > ???  I'm not sure what you mean. By the time you -read- a spam, it is
> > delivered, and the SMTP protocol has long since finished.  Spam isn't the
> > only kind of abuse that an ISP responds to. The abuse@<isp> works pretty
> > well, since you can forward the complained-of message. There are some
> > things I'd like MUA's to do, such as include the whole headers(some MUA's
> > do, some MUA's don't), but that isn't an RFC issue, either.
>
> Why not?  SPAM is a major networking problem.  Reporting spam and
> viruses (at the MTA or MUA level, as filters can work at either one) is
> only going to be effective if it is easy to report spam and if the
> reports are consistent and contain the information needed to combat
> spam.  Most MUA's cannot help users to report, and users definitely
> cannot help themselves.  If MUA writers tried to add a reporting
> capability now, they'd botch it by coming up with a dozen different
> formats and effectively precluding the creation of automated tools on
> the other end to facilitate processing the complaints at minimal cost.
>
> Perhaps not an RFC, but a standard is most definitely needed, and it
> needs to be both articulated and discussed in an open RFC-like process.
> And there are already RFC's that address this, e.g. RFC 2635.  It is
> just that this RFC reads like spam for the beginner (intended for users,
> a sort of anti-spam howto) and doesn't spell out anything like a uniform
> protocol for reporting spam TO the abuse@ address it suggests MTAs
> maintain.  Lacking this (and due to the fact that nobody reads RFCs but
> techie nerds; others don't even know what RFC stands for) the document
> isn't horribly useful to a software designer wanting to actually design
> TOOLS that might be portable and consistent.
We are soliciting volunteers for discussions of these type of issues in 
a closed subgroup of the ASRG. So far some of the ISPs are interested, 
but we don't have enough people to hold a coherent discussion on a 
mailing list. MUA authors haven't been interested so far :(
Yakov