On Fri, Feb 13, 2004 at 09:57:11AM -0600, wayne wrote:
(1) If the SPF proposal is widely adopted, I'd expect spammers just to start
sending spams with null envelope senders, i.e.
MAIL FROM:<>
RCPT TO:<me(_at_)mydomain(_dot_)com>
This doesn't help the spammer at all. If the envelope-from is null,
then SPF uses the HELO domain because the HELO domain is sending the
bounce. All the spammer has done is moved the requirement from one
spot to another.
I see. But presumably the spammer will use
HELO dsl-192-0-2-35.someisp.net # real reverse DNS
or
HELO myisp.com # any domain hosted at this ISP
in which case presumably SPF will allow it?
I still can't see how the receiver can use SPF to tell the difference
between a valid bounce originating from that ISP, and a spam originating
from a spammer who is connected to that ISP (or has hijacked a machine on
that ISP, or a message from a virus-infected machine on that ISP)
There are IP blacklists of course, but those already exist, and don't depend
on SPF.
Right now, there isn't any real way to distinguish a real bounce from
a fake bounce, but SRS gives the ISPs an option to do this. Sadly,
the format of the bounce messages is not document and varies widely in
real live. You can't count of message-ids or any sort of header being
preserved in the body of the bounce. It takes a lot of parsing to
even determine which MTA (and version of the MTA) created the bounce
and therefore determine if it is even plausably legitimate.
Actually I don't think it matters even if you could, because it could be a
legitimate bounce anyway (to a message with a forged sender). I get loads of
those, and until 90% of the Internet is covered by SPF it's not going to
help me.
If spammer at ISP A sends a spam to a bad address at ISP B (not using SPF)
then I will receive the bounce, and it will be a perfectly well-formed,
valid, legitimate bounce - just not to a message that I sent :-(
OTOH, if I start sending out messages with an SRS-signed envelope sender, I
can block *all* false bounces today. The personal benefit is immediate and
doesn't rely on someone else's rollout schedule.
In other words:
- signing your outgoing mails with SRS and rejecting unsigned bounces, is
similar to publishing an SPF policy
- implementing callback filtering on a receiving host is sufficient to
honour that policy
SRS and SPF don't completely overlap. SRS requires knowing a secret,
which roaming users are unlikely to know.
They'd relay via their ISP's smarthost (which would know the secret and
perform the signing). For strong use of SPF you require your users to use
SMTP AUTH to relay while roaming anyway, so I think it's pretty similar.
Many (most?) ISPs consider
having to do a callback to be way too expensive.
OK, that might be an issue. pobox.com does callback filtering as well as SPF
and various IP-based RBL lists. Perhaps one of their technical staff could
comment on the relative costs? Of course the callback also applies a cost to
the sending ISP (accepting the callback) as well as the receiver of the
mail. But I think that CPU and RAM are cheap these days, compared to the
economic costs of spam anyway.
The advantage of the callback is that you can say for certain that this
*particular* message must have originated from that ISP, and within a known
timeperiod of a few days. It also guarantees that should the message fail to
be delivered, the bounce would be deliverable.
SPF just tells you that any message from *(_at_)thatdomain(_dot_)com could
originate
from that ISP (but of course that information can be cached cheaply in the
DNS)
SPF and SRS are completely independent solutions to different
problems. People can freely use one without the other, although using
both is A Good Idea.
Maybe. What I was musing is that SPF by itself doesn't solve the
null-envelope-sender problem as far as I can see, and that SRS could by
itself solve that *and* the original problem which SPF was trying to solve
(i.e. forged envelope senders). Simpler solution, quicker deployment, more
immediate benefit to those who deploy.
Regards,
Brian.