[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: recent spam to this list

On Mon, Oct 13, 2003 at 04:26:35PM -0500, John Hasler wrote:
> Joel Baker writes:
> > I'm sorry, but your individual desire to be able to send mail from
> > anywhere on the planet, claiming to be anyone on the planet...
> What makes you think I want to claim to be "anyone on the planet"?
> I have a valid domain and I want replies and bounces to go to it.

If you're doing what these proposals are meant to block - that is, sending
email from a random IP on the internet without cryptographic authentication
data at the protocol level - then you can claim to be "Joe.Bob@turkey.com"
just as easily as you can claim to be your legitimate email. Opening up the
ability to do it for legitimate uses opens up the ability to use it for
illegitimate ones, as well - and this has a proven (and high) cost.

> > If adding .1 to your SA score for lacking a repudiation protocol, and 3
> > (or 5, or whatever) for claiming to be from a domain that denies that it
> > origionates mail to the rest of the world from your IP...
> I have no IP.  Outgoing mail from home goes via my ISP's smarthost.
> Incoming mail goes to his POP server.

I'm going to gloss over the utter mistake of your first statement (unless
you happen to connect to your mail server over SNA, IPX, or some stranger
option), and point out that the second statement automatically removes
you - entirely - from the issue at hand. If you're sending your email to
your ISP's smarthost, then *it*, not *you*, are what talks to the remote
mailserver - and, as such, it's IP (not yours) is what will be checked.
So, unless your ISP pulls a boneheaded misconfiguration, either there will
be no published policy (that is, anyone can send), or the policy will list
that smarthost as authorized.

> > If lacking a domain-authorized relay point comes to eventually have the
> > same statistics, you'd better bet that you'll have the same sorts of
> > penalties in spamfilters.
> What do you mean by "a domain-authorized relay point"?  It was my
> understanding that the idea behind SPF was that I would list in the DNS for
> my domain the IPs that were authorized to send mail claiming to be from my
> domain.  That would be fine with me, but I evidently misunderstood.

Understand that there are five normal situations that cover pretty much all
non-pathological sources of email on the Internet today:

1) Private mailserver run by a business, co-op, or highly technical single
user (enterprise servers).

2) ISP mailservers (just what they sound like)

3) Normal end-users relaying through their connection ISP (Joe Dialup)

4) Normal end-users relaying through their home ISP, organization, or
business (The Road Warrior)

5) Normal end-users delivering directly.

Class #1 is generally a "business" account of some sort; it costs more than
$19.95/mo, and is expected to be able to send and receive email directly,
as a rule. Also, as a rule, they can control their own DNS (either by
running a server, or by having update control from whomever they pay to do
hosting for their domain).

Class #2 is fairly obvious, though the line between "normal business" and
"ISP" can blur somewhat if your business has an IT department serving tens
of thousands of users. They almost certain run their own DNS servers, and
can afford someone compentant to run them.

These two classes have a strong business case for needing to send their
own email rather than let an ISP handle it for them; they frequently
have access through more than one ISP, and can easily (and legitimately)
generate hundreds of thousands of emails an hour, which would put an
excessive load on the mailservers of an ISP for one customer, if so.

Classes 3 appears to be your situation; both this, and class 4, are removed
entirely from the question of SPF/RMX/etc, because they relay through their
ISP's smarthost (and thus, that smarthost is what will be checked for being
allowed to send to a remote site).

Class 5 are the people who regularly used to use open relays (instead of
smarthosting), and who now want to be able to send emails directly (without
having to smarthost). They are the only ones such proposals hamper in any
significant way.

Your understand above is correct - note that you would list your *ISP's*
mailservers (probably the same smarthost you send to as their customer,
but possibly others; they would be able to tell you which ones) for your
domain, since that's where mail is expected to come from. In fact, if you
have something spiffy like Dynamic DNS updates arranged, you can even send
directly from your current IP, by updating the DNS to say "This dynamic IP
I got is authorized to send email for my domain". What you *won't* be able
to do, if the proposals are widely adopted, is to send email claiming to be
from "Joe.Bob@turkey.com", unless one of the following things is true:

1) The DNS for turkey.com has no published policy (entries in the DNS for
whatever protocol is adopted, saying "only these mailservers can send").
Lacking a policy statement, the sane default is "traditional", or "anyone
IP can claim to send on behalf of it".

2) The turkey.com domain publishes a policy, and your IP is listed as
one of those authorized to send on behalf of it (maybe you have Dynamic
DNS, or maybe you're a business mailserver running without passing
through the ISP, whatever).

3) You smarthost your email to a server configured to handle turkey.com
email, which is presumably listed in the policy, and *it* sends the email
on to the remote site (which then sees it coming from that server, not you,
and will accept it as coming from an approved server).

The price of leaving class 5 open is too high for the taste of many
people, because it *is not possible* to close it, and still block spammers
or viruses from spoofing emails that catch the bounces. It is possible,
however, to lock it down *only* for those entities who actually put
something in the DNS saying "we are only authorizing these IPs to send
email on our behalf".

Consider - wouldn't it be nice to know that the email you just got from
hotmail.com was, in fact, FROM a hotmail.com server - and that because
of that, you could trust the headers in it not to be forged, and that if
you filed an abuse complaint with Hotmail, they wouldn't come right back
and say "that didn't come from us, it's someone faking our name"? Or, for
that matter, wouldn't it be nice to NOT get the (looks) 100 or so emails
I've gotton over the past day, from broken autoresponders claiming I sent
someone a virus?

If it's a choice between being nice to the people in class 5, and having a
thousand fewer emails a week to sift through in *my* mailbox, they can take
a flying leap. None of them are important enough (right now) that I want
to get their emails *more* than I want to *not* get that many spams/broken
Joel Baker <fenton@debian.org>                                        ,''`.
Debian GNU NetBSD/i386 porter                                        : :' :
                                                                     `. `'

Attachment: pgpvQOiELQ4qS.pgp
Description: PGP signature

Reply to: