RE: FW: The worst abuse e-mail ever, sverige.net

Mailman List Mirror (Read Only)
1

We configure our DSL customers the same way you do. Static PVC, Static
IP. Each user has a static IP and in 99% of the cases, we do not assign
any dynamic IPs.

However, I would say that it is safe to say that the majority of the
ILECs here in the US provide DSL service where the IP is dynamic. Most
of the time, it doesn't change, but it is very possible that the next
time that the user logs in (most are also using PPPoE for the connection
setup) that the DHCP server might give them another IP.

As such, when we have seen our IP blocks get blocked strictly because of
the rDNS entry having 'dsl' in it, a simple email to the admins
explaining that we are not providing dynamic services has gotten our
rDNS entries taken off of the blacklist.

-Sean

Sean P. Crandall
VP Engineering Operations
MegaPath Networks Inc.
6691 Owens Drive
Pleasanton, CA 94588
(925) 201-2530 (office)
(925) 201-2550 (fax)

2

Why do you assume that an IP being static, but having generic rDNS
showing it to be a DSL line, automatically makes it worthy of relaying
or sending mail? I certainly don't make that assumption - rather the
opposite, given my experience of the past three years.

In my view of the universe, IPs with generically named rDNS should never
emit mail except by way of a suitably configured MTA, which ought to
have non-generic rDNS, preferably of the sort 'mail.$domain' where
abuse@$domain is a live account manned by an abuse desk, rather than a
generic '1-2-3-4.assignmenttype.technologytype.bigisp.example.net',
where complaints to abuse@example.net may or may not make any difference.

In the past 60 days, we've refused mail from

ip-69-33-132-156.nyc.megapath.net (claimed to be 'hal.org', and sender
was a yahoo.com account)

and

ip-66-80-96-99.aus.megapath.net (claimed to be 'asu.edu', and sender
was an asu.edu account)

and

ip-66-80-90-195.iad.megapath.net (claimed to be
'ccs1.clinicofcosmeticsurgery.com', sent to an inactive account)

and

ip-66-80-206-37.lax.megapath.net (claimed to be 'mail.totexusa.com',
sent to my account - I don't know anyone at 'totexusa.com'; both
messages were backscatter from a joe job)

Were we wrong to do so? I don't think so. Static or dynamic, makes
little difference. Today's email services require more than the current
status quo. And I haven't seen any reason to adjust my policy.

I'm left with the overall impression from many on this thread that in
the view of many ISPs, DNSBLs have removed the ISP's burden of policing
their own networks. And that's a shame.

Steve

PS: this message certified "ad hominem free" :confused:

3

I cannot agree to the "block port 25" line of action.

I am a Unix sysadmin, with 15 years of experience as sendmail and DNS
expert. I have a DSL line at home, with static IP, and generic rDNS
provided by my ISP. Behind it I have a serious Unix server, configured
to roughly the same standard that I use at work.

I know enough about this business to not trust my ISP with anything
more than moving packets to and from my server (and even that is
streching it ;-). I don't want to pay for their lousy mail service,
I can do it better myself.

And you don't want to let me?

Now, *why* should *I* be punished because the rest of my neighbours
have chosen to jump into the commercial bed of an operating system
that is a walking invitation to cracking?

The Internet is designed to be end-to-end.

I know of ISPs that try to filter out IP telephony to force the users
to use and pay for the ISP's VOIP service. Is that OK? No, I thought
not. But remember - when VOIP gets deployed really wide and far (like
e-mail today), you'll start to receive a lot more abusive phone
calls. Why?

This all boils down to cost and cost model. In the real world, the
sender pays for the (paper) mail message. In the electronic world,
the bigger cost is carried by the recipient. This model will break in
the future.

It's too d---ned cheap to send out spam, and it'll be too d---ned
cheap to sell your stuff over VOIP in the future.

We could fight all this, but it takes manpower and competence, and
manpower and competence cost real money - money that the customer is
not willing to spend ... yet.

This is a market problem. It will eventually sort itself out, but
stopping serious and sesnsible people from using the Internet as it is
designed, is not the right way to do it. If the Internet is going to
survive - the cost model has to change. Or, there's another future,
where the Internet as we know it, is just a packet transport system,
on which we build our own (several) virtual networks which are only
reachable by the community (-ies) that we choose. Configuration
nightmare. But someone will make money by providing software tools to
help us make our worlds as complex as possible (see "NAT" in your
dictionary ...)

(Hmm. Maybe I should start a BGP feed that blacklists all ISPs that
block port 25? Hmm. Hmm. Any takers? :slight_smile:

        Cheers,
          /Liman

4

I cannot agree to the "block port 25" line of action.

I am a Unix sysadmin, with 15 years of experience as sendmail and DNS
expert. I have a DSL line at home, with static IP, and generic rDNS
provided by my ISP. Behind it I have a serious Unix server, configured
to roughly the same standard that I use at work.

Congrats. Ask your ISP for non-generic rDNS, in your domain, so I know
where to send the abuse reports.
  

I know enough about this business to not trust my ISP with anything
more than moving packets to and from my server (and even that is
streching it ;-). I don't want to pay for their lousy mail service,
I can do it better myself.

And you don't want to let me?

I don't mind at all. Get rDNS that provides a clue that you have a clue,
and I'm happy as all get out to accept mail from you. Otherwise, you're
functionally identical to fifty million spam zombies, as far as I have
time to determine.

Understand me? You're the /rare exception/.

Now, *why* should *I* be punished because the rest of my neighbours
have chosen to jump into the commercial bed of an operating system
that is a walking invitation to cracking?

Because that's how things are today. You're a 1-in-50-million chance,
as far as I can tell from my mail server.

<snip unhelpful Internet architecture lesson>

5

Lars-Johan Liman <liman@autonomica.se> writes:

I cannot agree to the "block port 25" line of action.

I am a Unix sysadmin, with 15 years of experience as sendmail and DNS
expert. I have a DSL line at home, with static IP, and generic rDNS
provided by my ISP. Behind it I have a serious Unix server, configured
to roughly the same standard that I use at work.
...
This all boils down to cost and cost model.

Yep, precisely. You're running a business/professional type of
configuration on a consumer-grade circuit. Your ISP has to assume
that you're Joe or Jane Luddite with an unpatched Windows PC when you
buy this configuration, but your requirements are outside of the
standard product definition (and best current practices) for consumer
b/w.

Buy an appropriate connectivity product for your home connectivity and
the problems go away. Put your servers in a colo (a la
http://www.vix.com/personalcolo/ ) and the problems go away. It costs
more to maintain a zone file that is not created by a perl script (ie,
your generic rDNS). You can expect to pay for this. Presumably as a
Unix sysadmin with 15 years of experience, this is a cost you can
afford/justify.

                                        ---Rob

6

[..]

Buy an appropriate connectivity product for your home connectivity and
the problems go away. Put your servers in a colo (a la
http://www.vix.com/personalcolo/ ) and the problems go away. It costs
more to maintain a zone file that is not created by a perl script (ie,
your generic rDNS). You can expect to pay for this. Presumably as a
Unix sysadmin with 15 years of experience, this is a cost you can
afford/justify.

What will that 1U server help me if I am sending stuff from
my Unix box at home via SMTP to it when my IP block is in
the various 'dialup' RBLs and ends up in the Received
headers, so every SA on the way happily scores it rather
high as these RBLs sum up. What would be gained than at the
end of it?

Alexander

7

Alexander Koch wrote:

What will that 1U server help me if I am sending stuff from
my Unix box at home via SMTP to it when my IP block is in
the various 'dialup' RBLs and ends up in the Received
headers, so every SA on the way happily scores it rather
high as these RBLs sum up. What would be gained than at the
end of it?

$ ssh -2 -L2525:your.mail.server:25 you@your.mail.server

  srs (check my headers and tell me if you can see my home dsl ip)

8

Alexander Koch <koch@tiscali.net> writes:

[..]

Buy an appropriate connectivity product for your home connectivity and
the problems go away. Put your servers in a colo (a la
http://www.vix.com/personalcolo/ ) and the problems go away. It costs
more to maintain a zone file that is not created by a perl script (ie,
your generic rDNS). You can expect to pay for this. Presumably as a
Unix sysadmin with 15 years of experience, this is a cost you can
afford/justify.

What will that 1U server help me if I am sending stuff from
my Unix box at home via SMTP to it when my IP block is in
the various 'dialup' RBLs and ends up in the Received
headers, so every SA on the way happily scores it rather
high as these RBLs sum up. What would be gained than at the
end of it?

Think about what you just wrote -- if things actually worked this way,
nobody who ran SpamAss would ever receive any mail. :slight_smile:

(if you're a conspiracy theorist or just weird, set up an ipsec, ssh,
or gre tunnel and call it done).

What's it buy you? Unblocked ports, control of in-addrs associated
with your addresses, data center UPSes, data center cooling, (still
subject to Acts of God as recent experiences in NoVA showed, but
that's life), not having your *server* in a block that is identified
as dialup.

                                        ---Rob

9

You block port 25 until a customer says that they're claim to have
setup a responsible mail submission agent and demonstrate the
necessary clue density.

This can be readily determined by having customer support mail
a short form with relevant questions such as "Is your mail server
RFC2505 compliant?", "Please list the mechanism used to secure
mail submission to your server?", and "Are you prepared to handle
SPAM reports for all email originated or relayed?" No problem for
someone who knows what they're doing but enough to deter the
random end user.

/John

10

Date: Wed, 22 Sep 2004 16:54:20 +0200
From: Alexander Koch

What will that 1U server help me if I am sending stuff from
my Unix box at home via SMTP to it when my IP block is in
the various 'dialup' RBLs and ends up in the Received

Presumably you'd admin the 1U server, and your authenticated
SMTPS traffic would be allowed despite RBL listings, yes?

headers, so every SA on the way happily scores it rather
high as these RBLs sum up. What would be gained than at the
end of it?

Huh?! Either you're running { UUCP | some strange multihop
relaying } or I'm totally confused. You connect to your colo box
directly. There are no other hops along the way.

Eddy

11

[ we have had this discussion before. how many times are we doomed
  to have it? ]

in the north american culture, this is usually termed "guilty
until proven innocent," and generally discouraged. perhaps we
should not deprive the customer of rights/services until they
have been shown to have abused them?

lars-johan's posting was a wonderfully eloquent plea for the
survival of the internet, as opposed to the walled-garden telco
model.

randy

12

I am *so* happy that the power grid doesn't operate this way...
fuses and circuit breakers are there in your home, the pedestal,
and the pole for good reason. Call your power company if you
want to upgrade *and* can demonstrate appropriate certified
electrical work in advance.

/John

13

Randy Bush <randy@psg.com> writes:

<reductio ad absurdum comments about American jurisprudence elided>

lars-johan's posting was a wonderfully eloquent plea for the
survival of the internet, as opposed to the walled-garden telco
model.

In a vacuum, we all agree with him. He should be sending his plea to
Redmond, from whence comes the vulnerable software that makes this
stopgap BCP necessary.

                                        ---Rob

14

But we've fixed that! We added a ENUM layer with DNSSEC on top of it.
So now we can decide what to tell our potential callers without them
being to spoof it. Like "do not disturb me now"

Oh yeah, and we'll use the phone number as index for all this information!

Now if you'll excuse me, I'll go sob in the corner over there.....

Paul

15

in the north american culture, this is usually termed "guilty
until proven innocent," and generally discouraged. perhaps we
should not deprive the customer of rights/services until they
have been shown to have abused them?

I am *so* happy that the power grid doesn't operate this way...

i think history has disabused the apocrypha that the telco or the
power grid are so reliable

randy

16

Unless you do final delivery on that hypothetical 1U colo box (presumably to
yourself and whoever else you give access to), the mail will almost certainly
acquire at least 1 or 2 more Received: lines while getting to the remote site.

The problem is that some tools run through *all* the Received: headers looking
for borked forward/backward chains or hosts that are in a blacklist. So if
they saw the dialup IP address in one of the earliest Received: lines, you'd
get scored some dings on the spam-o-meter. After all, 95% of any email that
ever passed through a dialup is spam, right? :wink:

We now return you to our regularly scheduled episode of "What's wrong with this
picture?"....

17

I'm *so* happy the sidewalks don't operate this way. Can you imagine asking for permission every time you wanted to cross the street? And being _licensed_ for it?

That was not a commentary on whether we should or should not block port 25. I _am_ saying we should not use analogies to justify it one way or the other, since this is really a rather new, different thing. (BTW: That includes the cultural thing Randy said too, although I am an American and absolutely identify with what he said.)

We've done pretty well in the past letting each operator decide on their own about new ideas, and the majority can ostracize the bad apples. Then again, I did say this is new, and I meant it, so perhaps even past Internet experience might not be enough....

There, I think I've said absolutely nothing, so I'm right in keeping with this thread in general. Back to your regularly scheduled flame fest. :slight_smile:

18

Older versions of SA, especially with custom DNSBL rules, may have had
this issue (applying DUL type DNSBL rules to IPs in every Received:
header:) but thats been fixed for some time.

Welcome to NANOST (North American Network Operaters Spam Talk). But
seriously, anyone who has an interest in such issues ought to at least
occasionaly read spam-l or spamtools before posting to nanog about long
fixed problems in old software.

19

In many cases, "fixed" != "deployed", unfortunately. And that adoption
curve has got a LONG tail at the far end going to infinity, because some
sites will never upgrade.

Has anybody done a comparison for different instances of this same problem
(for instance, rate of fixing of 69/8 filters, open SMTP relays, installing a
Microsoft 'critical' software fix, patching bind/ssh/apache/whatever
after a vulnerability is found), to see if the underlying curve has similar
characteristics?

I'm familiar with Eric Rescorla's "Security Holes - Who cares?"
paper (http://www.rtfm.com/Upgrade-usenix.pdf) and Beattie, Arnold,
Cowan, Wagle, and Wright's "Timing the Application of Security Patches
for Optimal Uptime" from LISA XVI - any other cites, especially for those
that succeed in mathematically modelling it in the real world well enough to
make predictions from?

20

Let's move this thread to some place where people love to talk about spam:

  http://www.claws-and-paws.com/spam-l/spam-l.html -- spam-l list for
       spam prevention and discussion
  http://www.abuse.net/spamtools.html -- spam tools list for software
       tools that detect spam
  net.admin.net-abuse.email | net.admin.net-abuse.usenet -- usenet lists