On Tue, Sep 18, 2007 at 02:42:43PM -0400, Sean Donelan wrote:
> Instead of they suck, it might be more useful to highlight providers of
> similar scale which you think do a good job which others could emulate.
A first-order examination of the data suggests that Cox may be
doing something pro-active. The number of IP addresses on their
network engaged in recent spam delivery attempts is considerably
less than that from others, e.g.:
Comcast: 1240
Verizon: 1594
Cox:25
Of course, that could be due to the relative sizes of the networks
involved, but a second-order examination of the same data suggests
something more: the abuse-emitting IP addresses on Cox's network do not
appear to show up repeatedly over long periods of time. Contrast with
those on Comcast and Verizon, where it's quite common to see the same ones
in the logs for days/weeks/months. This suggests to me that Cox
is actually paying attention to abuse outbound from their network
and is either disconnecting or quarantining hosts which emit it.
> Some people think that users on dynamic addresses should be read-only, and
> not allowed to operate servers or send messages. Like most forms of
> red-lining, it tends to become self-fulling.
Of course, I've never suggested any such thing. Users of such ISPs
should normally be using their own ISPs outbound mail server(s),
a solution which is perfectly adequate for the overwhelming majority
of users. And it should be no problem for them to use other mail
servers, using SMTP AUTH (with TLS or SSL) or via HTTP. But
the days when direct-to-MX traffic is acceptable from all addresses
are as gone as those when operation of an open SMTP relay was acceptable.
Moreover, those who wish to operate servers (and whose ISPs permit
that operation per their TOS) should have no difficulty in having
the ISP assign them non-generic DNS/rDNS, and/or assign them static
address space which is reserved for such users.
> Unlesss accept all those messages from those addresses and check them, you
> really don't know the false positive rate. You only know the
> self-reported complaint rate; which is usually a fraction of the actual
> false positive rate.
Actually, I know quite a bit more than that. But since this is NANOG
and not an anti-spam discussion list, I elected not to delve into the
rather lengthy details of the methodology used to ascertain the FP rate.
But *briefly* and glossing heavily, when a particular IP address (with
generic rDNS, let's say):
- fails to wait for the SMTP greeting
- fails to send a QUIT
- fails to retry when given a deferral response
- retries immediately when given a deferral response
- attempts delivery to an MX that hasn't been an MX for years
- attempts delivery to a domain whose MX record hasn't
been pointed to this MX for years
- HELOs as ebay.com (or similar)
- HELOs as a non-existent domain
- HELOs as a very-recently-registered domain
- HELOs as something different each time it connects
- HELOs as *my* MX or a domain handle by it
- attempts to send mail with a putative sender @paypal.com (or similar)
- attempts delivery repeatedly with different putative senders/different
putative sender domains
- attempts to send mail with putative senders whose domain does
not exist or does not resolve
- attempts to send mail with a putative senders whose domain has
A or MX records which resolve to invalid network space
- attempts to send mail with a putative sender whose domain
has very suspicious DNS records [1]
- attempts to send mail from a putative sender using
a known-spammer-owned domain
- attempts to send mail from a putative sender using
a domain which resolves to DROP-listed space. [2]
- attempts to send mail from a putative sender using
a very-recently-registered domain
- attempts to send mail from a putative sender using
*my* domain
- attempts delivery to spamtraps
- attempts delivery to never-existed addresses
- attempts delivery to one-off addresses available only in SMTP
reject notices
- attempts delivery of messages whose headers contain known
spamware signatures
- attempts to send mail whose body-part contains URIs which
match well-maintained lists of spammer-controlled URIs
- has already been noted by other independent observers as
attempting spam delivery to their MX's
- passive-OS-fingerprints as running Windows
- is listed in the A or NS records of a known spammer domain
(see [1] again)
- has been noticed carrying out other attacks, e.g., attempting
exploitation via HTTP,
