[linux-elitists] Re: MCI boots send-safe (Register) -- adds a net of 11 more spam hosts

Karsten M. Self kmself@ix.netcom.com
Tue Mar 8 15:53:58 PST 2005

on Tue, Mar 08, 2005 at 11:49:12AM -0800, Don Marti (dmarti@zgp.org) wrote:
> begin Karsten M. Self quotation of Thu, Mar 03, 2005 at 02:24:55PM -0800:
> > I think I get at this somewhat more trivially with a proportionate
> > rejection scheme:
> > 
> >   - Accept the first mail from a new source.
> I doubt this is going to be the default if spam keeps up its growth
> rate.

FVO "Accept" equal to "allow data to be submitted, not necessarially
competing a successful delivery".  The alternative is an IP-level
refusal to serve, preferably via a DENY rather than REJECT rule.

You may well be right, in which case the default would be "produce a
temporary nondelivery error", at which point the remote MTA's behavior
vis-a-vis respecting retry intervals would be monitored.

The point is that you've got no data to base initial response on.
False-positive costs are high, and though a delay on first delivery from
a previously unknown MTA (_not_ "sender address", as those who'll
misread this prosal will inevitably claim), is a small cost, some shops
might prefer to avoid it.

The odds of getting spam from a previously unknown IP, not near,
networ-wise, other known spam sources, or from a spam-happy ASN/CIDR,
should be reasonably low.

Too, the major cost of spam is the consistent degredation of trust and
efficacy of legitimate email communications.  Human mediation costs
(sorting spam, etc.), and silent failure (email becoming less reliable)
are among the others.  Technical bandwidth constraints themselves are
not _yet_ an issue for most MTAs, though dialup users are starting to
hit that limit.  _Processor_ limitations for some active-scanning
systems (e.g.: SpamAssasin) serving many accounts are an issue if that
is the sole strategy -- in combination with other methods (firewall
rules, DNSBLs) the load is still pretty manageable.

> Fortunately, there already _is_ a reputation system for domain names.
> It's called Google.  

Probably a pretty loose correlation there, though it might be an
interesting input to, say, SA.  


  - For heavily spammed sites (pr0n...), probably an _inverse_ relation.

  - Many high-value senders may use mail services from unrelated

Still, interesting.


Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    The black hat community is drooling over the possibility of a secure
    execution environment that would allow applications to run in a
    secure area which cannot be attached to via debuggers.
    - Jason Spence, on Palladium aka NGCSB aka "Trusted Computing"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20050308/6cf39af2/attachment.pgp 

More information about the linux-elitists mailing list