Double Irony! (was Re: [linux-elitists] ruben's stupid filter)

Karsten M. Self kmself@ix.netcom.com
Sun Mar 24 16:39:47 PST 2002


on Sun, Mar 24, 2002, Marc MERLIN (marc@merlins.org) wrote:
> On Sun, Mar 10, 2002 at 11:51:30AM -0600, Mr. Bad wrote:
> >     KMS> SA tagged the message as spam and my procmail autoreporting
> >     KMS> rules (set to trigger at a threshold of 10, not SA's default
> >     KMS> "5 and you're spam" threshold) sent the mail to his
> >     KMS> employer's NOC.
> > 
> > So, I got to say, I really, really, really hate this auto-reporting
> > white-list challenging crap. It's goddamned rude to your absolutely
> > legitimate correspondents.
> (...) 
>  
> Yep, I definitely agree with you here.
> Challenging, I *could* maybe deal with depending on the situation (who I'm
> Emailing and so forth).
> Auto-reporting or semi-auto reporting, I'm getting really tired of.
> 
> For that matter,  Karsten and I have had this  dicussion twice
> already, even though he usually knows what he's doing he's already
> twice reported spam to me (through svlug and sourceforge) because the
> machines were in the received headers (mailing list) 

Note that this was twice because the mail arrive through two independent
routes, each of which was (individually) added to a "do not respond"
list immediately.

> Karsten has some clue, so that tells you about people who don't have
> one, and still try to use auto-reporting tools.  I'm getting very
> tired of auto reporting because it accuses _me_ and I have to spend my
> time to say/prove that I'm innocent. Fuck that!

A few points on this:

  - Defending your name is, unfortunately, part of the game.  In the
    real world, this leads to things like trademark suits.   Online, it
    means you have to come up with a reasonable response to people who
    claim you're a spam source.  Until mail software does a decent job
    of testing for validly-formed headers, the truth is that it's easy
    to forge and hard to validate email information.
    
  - Tools like spamassassin are pretty damned slick.  For personal
    systems, it handles the load admirably.  Moving this to the mail
    gateway raises performance issues -- I'm seeing about 0.4 seconds
    per validated mail, restricting any one server to a total possible
    peak of about 200,000 mails a day.  Sufficient for many, but not
    all, purposes.

  - The problems I'm having are far _less_ with the spam
    _identification_ (none of the messages forwarded to Marc were not
    spam).  It's identifying spam _sources_ from headers.  I use
    Ricochet (how many times have I said this already ;-).  I've tuned
    to to be more selective on its reports (no secondaries).  I get a
    fair bit of response suggesting that the reports result in actions.
    As with most things, I actually favor automated response tools --
    they are easier to fix where things go wrong.  A widely used,
    well-tuned, free software reporting tool would be a boon, not a
    cures.

  - My experience with Spamassassin suggests it's going to become more
    widely used, not less, and will likely be used with either manual or
    automated response tools.  As such, the solution isn't to block them
    or rail against their use, but to improve both the reporting tools,
    and the means for responding to them.

    For example, if Ricochet's response could be crafted to indicate a
    recipient's relationship to a spam message, in a standard format,
    parsing tools at the recipient's site could analyze this content and
    determine if the complaint were legitimate or not.

    Also, spam will tend to generate large numbers of responses for the
    same (or substantially similar) messages.  A spam response handling
    system could prioritize responses similar to a ticket tracking
    system.  I may well need such a system at work....

    Simple truth:  being online with email capabilities is a benefit and
    a liability.


SpamCop:

> The  part  that annoys  me  the  most  is  that their  "spamvertised
> sites" checkboxes are  enabled by default, which  means that any moron
> that send a spam with a URL pointing to  sourceforge.net, or slashdot,
> or whatever, ends up as a report in my mailbox.

What's this?  Sites that are advertised in spam generate responses to
that site's PM?  I can see how this would lend itself to abuse, but it's
not an entirely bad thing.  Context matters, natch.  You don't specify
_how_ sourceforge is being mentioned in these emails.


> On Sun, Mar 17, 2002 at 03:08:15AM -0800, Karsten M. Self wrote:
> > There are different objectives for antispam measures.
> > 
> >   - For most people, it's probably to minimize the amount of spam that
> >     sneaks into their inbox (or other filtered mailboxes).  This is one
> >     of my objectives.
>  
> I'd like to believe that.  Not sure how true it is anymore. People who
> still read their abuse mail are largely people who hardly ever spam,
> if at all.

There's a shitload of incidental spam through major ISPs.  Some of it's
spoofed headers, much of it isn't.  Virtually every Nigeria spam I've
ever seen has gone through Yahoo, much of it from Yahoo.uk.

> > The problems have largely concerned not identifying spam, but
> > identifying related/associated systems.  "Ricochet" is a good tool,
> > but does require some tuning.  Spamassassin simply rocks.  Its false
> > negative rate is low, its false positve rate lower.  Using a higher
> > threshold for automated reporting means I largely don't have to deal
> > with the issue of dealing with falsely reported spam, just getting
> > the reports to the right place.
>  
> That's the problem. You should review  your reports carefully before
> sending them, especially for every new domain you add to your report
> list.  In 2  of your 5  examples, it ended  up in my  mailbox, and I
> wasn't happy, because there are two many of you already.
>  
> If  you are  not willing  to  carefully inspect  the reports  you
> send, you shouldn't send any.

Personally, that's a relatively reasonable request.

As the webserver, system administrator, helpdesk dude, and general tech
wizard for a company of 25 and several hundred domains, manually
inspecting the 50-100 spams I get daily is simply not feasible.

> > I'm impresssed that most mainstream ISPs seem to have pretty decent
> > automated spam mitigation in place.  I'm not saying they're solving the
> > problem, but I tend to see a pattern of responses:
> > 
> >   - Automated "we recieved your message and are investigating, don't
> >     expect any further response" messages from majors (Yahoo, MSN,
> >     UUNET, etc.).
>
> Can be translated as:
> "We receive lots of reports, 3/4th aren't  for us and were sent to us anyway
> damnit! so  we don't bother  answering anymore. We may quickly  eyeball your
> report, and should it actually be correct,  we may have a look, but we can't
> spend our time answering all these useless reports anymore"

Actually, I _do_ frequently get followups indicating that a ticket (not
necessarially my own report, but an aggregated response) was evaluated
and determined to be legit or a spoofed line.  Frequently as well,
accounts, websites, or clients are terminated.

> >   - Variations on "undeliverable/failed mail", often from Asian ISPs,
> >     though far too common elsewhere, for abuse@ and postmaster@
> >     addresses.  These get manually forwarded to
> 
> My exim callbacks on sourceforge.net simply refuse mail from any
> domain that isn't willing to accept mail back for  postmaster@ (I
> can't tell if the mail would actually get accepted, but at least I
> took care of basic bounces)

Hmmm...

Any suggestions for implementing same for qmail?

> >   - Occasionally, mail suggesting that spam from a domain is my
> >     problem, not theirs, and unless I jump through various hoops
> >     (modifications, additions, or removals of header formatting,
> >     attachment formats, GPG signatures, etc.), my mail won't be
> >     addressed.  I respond that if
> 
> Ah, so people have to go through your challenges, but you won't go
> through theirs. I see.

My "challenge" is "you have spam that looks like it's coming from you".
I use standards-compliante tools to indicate this.  If I'm _not_
following a standard, I'll change to accomodate this.  The sites I'm
complaining about are restricting input to a subset of Internet
standards.  This isn't acceptable.


> On Sun, Mar 10, 2002 at 03:49:37PM -0800, Dan Wilder wrote:

<...>

> > I have in the past blacklisted sites which originate excessive false
> > or frivolous autoreports.  I will do so in the future.  Such
> > nuisance mail is itself little better than spam.  
>  
> Amen brother.

Do so with an understanding that this itself may be a violation of RFC
2142, and may result in a listing with, e.g.:
http://www.rfc-ignorant.org/:

    2.  INVARIANTS

    For well known names that are not related to specific protocols,
    only the organization's top level domain name are required to be
    valid.  For example, if an Internet service provider's domain name
    is COMPANY.COM, then the <ABUSE@COMPANY.COM> address must be valid
    *and supported*, even though the customers whose activity generates
    complaints use hosts with more specific domain names like
    SHELL1.COMPANY.COM.  Note, however, that it is valid and encouraged
    to support mailbox names for sub-domains, as appropriate.

    [http://www.rfc-editor.org/rfc/rfc2142.txt]

Blackholing classes of mail may result in your being blackholed
yourself.

Again:  I think automated tools *are* a benefit *if* properly designed.
I think the solution is in improving the tools, not in griping about
them.

Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>      http://kmself.home.netcom.com/
 What part of "Gestalt" don't you understand?          
   Keep software free.         Oppose the CBDTPA.         Kill S.2048 dead. 
           http://www.eff.org/alerts/20020322_eff_cbdtpa_alert.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20020324/734dfacf/attachment.pgp 


More information about the linux-elitists mailing list