Spammers Skirt IP Authentication Attempts

This is not a good beginning

http://www.eweek.com/article2/0,1759,1642848,00.asp

It's a predictable response by the spammers. Did anybody really expect
the spammers to go "oh, well, that's it, we'd better shut up shop
now"?

I'm an advocate of SPF, but not because it's the magic bullet that
stops spam. It does however allow innocent domains to say "no, I
didn't send that" and thus avoid the double-bounced backwash from a
spammer forging their domain as the sender.

a message of 4 lines which said:

This is not a good beginning

http://www.eweek.com/article2/0,1759,1642848,00.asp

Bad paper. The CipherTrust story, which is mentioned, is very weak: it
contains several big mistakes (such as mentioning SenderID
records... which do not exist yet since the working group is in the
"last call" state) so I question its credibility.

Regarding the facts, testing on my "spam" mailbox, I can see SPF
records from spammers but it is very uncommon (there is no incentive
for them to publish SPF immediately, because few sites will test
them).

Otherwise, SPF is not anti-spam by itself. In the same way that
network security is not provided by a firewall alone, anti-spam
protection is not provided by SPF alone. SPF is an enabler: it allows
you to be more confident in the authenticity of the domain, giving
reputation systems (whilelists and blacklists) a better chance to
succeed.

It's also a step towards making domain-based whitelists / blacklists
more practical (and, as pointed out recently on spam-l, which might be a
more appropriate place for this discussion, makes more aggressive
filtering of non-whitelisted domains and domains without SPF records
more possible).

It should hopefully help with viruses that forge the sender-address and
should help reduce bouncebacks due to spam and viruses with forged
sender addresses. It can help make phishing scams more difficult to pull
off. It makes it easier for someone to say "this domain will NEVER send
any legitimate email traffic".

Will spammers register tons of new domains, setting up SPF for each?
Probably. Will they start spoofing other domains hosted by the same
provider? . Will they register "look-alike" domains? Will viruses get
smarter, and start sending themselves out via providers' SMTP servers?
Probably. But all of these cases are still an improvement over the
current situation, and help make life easier for existing email
filtering / processing tools.

I don't personally believe that "[s]pam as a technical problem is solved
by SPF"[1], but I do think it has the potential to reduce some existing
problems with email (some of which are related to spam). I'm cautiously
optimistic that it /may/ be a good thing.

Victor Duchovni made some interesting points about SPF on spam-l that
are worth checking out if you can access the archives.

Some excerpts (please edit attributions if you're quoting / replying to
this - I didn't write this):

What everyone is forgetting is that the biggest proponents of SPF are
large mailbox providers, and their real motivation is actually not so
much deterring spam, but lowering the administrative cost of
maintaining white-lists!

White-listing IP addresses loses, because legitimate bulk mailers (and
some no so legitimate ones, but that is not the point) who are
whitelisted by the ISPs occasionally move their outbound relays to new
address pools. Also some providers host multiple sender domains, some
that one wants to whitelist and some that one does not.

[...]

This does nothing to block spam, this merely decentralizes whitelist
management. With more up-to-date (reliable?) whitelists, one can afford
to spend more resources on aggressive filters of mail that is not
white-listed, and not worry as much about false positives.

[1] http://www.interesting-people.org/archives/interesting-people/200401/msg00034.html

Envelope "cookie" schemes on outbound email, like SRS, can achieve that, far better (*you* know whether the bounce is legit, rather than relying on the bouncer to do the checking) and without the collateral damage of SPF.

regards,

Date: Mon, 6 Sep 2004 04:26:04 -0700 (PDT)
From: Henry Linneweh

This is not a good beginning

http://www.eweek.com/article2/0,1759,1642848,00.asp

Yawn. "If the sender domain isn't forged, the mail isn't spam"
is incredibly stupid logic. I suppose the next big news article
will be that spammers also prefer forging domains that lack SPF
records. (Will miracles never cease?)

Eddy

Yawn. "If the sender domain isn't forged, the mail isn't spam"
is incredibly stupid logic.

No Kidding!

I suppose the next big news article will be that spammers also prefer
forging domains that lack SPF records. (Will miracles never cease?)

Amazing :slight_smile:

I think SPF is an important step in getting rid of people pretending to be
someone else. If you have SPF records, and they match the mail, chances
are you are who you say you are. Finding out who you are behind domain
records/etc, thats a different story...

Although SenderID (or whatever the final name is) is not completed yet,
SPF has been around for a while and some people have been using it. But
who? Do domains with SPF records have fewer phishing attacks? Fewer
virus bounce-backs? Fewer spam forgiers?

According to the Anti-Phishing Working Group, these are the most phished
companies. How many are using SPF? I checked the most obvious domain name
for the companies (.COM and their country variant e.g. .CO.UK)

Company Name Has SPF TXT record

Citibank NO
eBay NO
US Bank NO
Paypal NO
Fleet NO
LLoyds NO
Barclays NO
AOL YES
Halifax NO
Westpac NO
FirstUSA NO
VISA NO
Earthlink YES
e-gold NO
Bank One NO
Bendigo NO
HSBC NO
MBNA NO
Suntrust NO
Verizon NO

Hrmmm, perhaps this hasn't been thought of yet, but this is a serious idea for things like spamassassin, or the like. For this list of domains, a decent twofold effort could happen:

1) A decent push on the part of pobox.com (previously, their focus has been on protecting lots of senders, like AOL, or Earthlink), rather than commonly-forged-phishers, to get these folks on board.

2) A big old warning (possibly for these domains themselves to opt into) as a "we know we're high risk but we have an SPF record, please check it" RDNSL.

It could even be used in some cases with SpamAssassin to inject a link into the email for the location to report such forgeries. (Such info could be kept in the RDNSL, for example).

Knowledge is Power.

-Dan

* danm@prime.gushi.org (Dan Mahoney, System Admin) [Mon 06 Sep 2004, 22:19 CEST]:

Hrmmm, perhaps this hasn't been thought of yet, but this is a serious
idea for things like spamassassin, or the like. For this list of
domains, a decent twofold effort could happen:

[snip]

No, SPF is not feasible for integration into SpamAssassin. Some links:

   ASF Position Regarding Sender ID
   Debian -- News -- DEPLOY: Debian project unable to deploy Sender ID
   http://www.imc.org/ietf-mxcomp/mail-archive/msg03884.html

Company Name Has SPF TXT record

[..]

Earthlink YES

This tells a slightly different story regarding EarthLink's commitment
to adapting Sender ID, though:

   http://www.imc.org/ietf-mxcomp/mail-archive/msg04258.html

  -- Niels.

[...]

No, SPF is not feasible for integration into SpamAssassin. Some links:
   ASF Position Regarding Sender ID
   Debian -- News -- DEPLOY: Debian project unable to deploy Sender ID

Microsoft's encumbered Sender ID and SPF are not the same.

   http://www.imc.org/ietf-mxcomp/mail-archive/msg03884.html

This URL confirms that Sender ID will not go into Exim, but there is
already SPF support.

as a general rule, you will find that the M$ license agreement for
Sender ID functions as a poison pill in the context of GPL, BSD,
and Apache style licensing. the restrictions on redistribution are
completely incompatible with traditional open source redistribution
policies.

i will be very curious to see what the IETF does or does not do
to resolve this issue.

richard

This is not a good beginning

http://www.eweek.com/article2/0,1759,1642848,00.asp

every time i see another Final and Ultimate Solution to the Spam Problem
(FUSSP, (tm) VJS) get some traction and then fall well short of its goals,
i've had the same emotion: "well what the h--- did you think was going to
happen?"

I'm not sure the people behind this concept (SPF, RMX, et al) ever
intended it to be the FUSSP, but a lot of the ensuing enthusiasm
built it up to that.

I've *never* viewed SPF as an "antispam" methodology, but considered
it an inevitable utility of the DNS system. Other methods are
evolving to deal with spam, don't confuse them with what SPF is,
which is essentially an authentication/identification framework
that has the ability to mitigate one of the more popularly used
spam obfuscation techniques.

That spammers are publishing SPF records is in no way indicative
of an inherent flaw in SPF's objectives or a failure in its
implementation, in fact, I welcome spammers who publish SPF
data detailing the originating points of their email. If
more "known spam domains" did this, a handy DNSBL could be
constructed out of such data (with a few caveats of course,
it would also potentially open the door to a type of DoS attack).

But at the end of the day, none of this is surprising and none
of it constitutes a "failure" or setback for SPF (quite the
contrary in fact).

-mark

I think SPF is an important step in getting rid of people pretending to be someone else. If you have SPF records, and they match the mail, chances are you are who you say you are.

Not really. For that you need X.509 or PGP and web-of-trust.

Also, SPF doesnt tell you whether it is spam. Indeed, apparently majority of SPF-valid email at moment is spam!

Finding out who you are behind domain records/etc, thats a different story...

SPF is worthless.

Joe-job protection can be done in far better ways, eg SRS.

regards,

a message of 24 lines which said:

Also, SPF doesnt tell you whether it is spam.

Of course. It never pretended to do so.

Indeed, apparently majority of SPF-valid email at moment is spam!

No. Where did you find the figures?

Also, SPF doesnt tell you whether it is spam.

Of course. It never pretended to do so.

Right, but a lot of seem people to be under the mistaken impression it will have some effect on spam.

No. Where did you find the figures?

regards,

And every time those people speak up, someone who knows better
  corrects them. Thus is wisdom gained.

paul@clubi.ie (Paul Jakma) writes:

SPF is worthless.

i don't agree. i think it's overengineered and that a simpler solution like
the one at <http://sa.vix.com/~vixie/mailfrom.txt&gt; should have been deployed
years ago, but i don't think SPF, or things like SPF, are at all worthless.

every time someone forges one of my domains or e-mail addresses as a spam
source, i get all kinds of bot-mail telling me that what the spammer tried
to do didn't work. quite a lot of challenge/response nonsense. quite a few
majordomo/etc listbot error messages. a whole pile of mailer-daemon@ errors.

the right way to resolve this would be to make all errors synchronous to the
smtp session where they occur. but this would prevent secondary-mx, or any
kind of asynchronous mail forwarding. so, mail that requires a robotic reply
has to cause a new envelope to hold this reply, and if the source was forged,
then some innocent bystander is going to get that reply.

if all mailbots learned to speak something like SPF, and my domains all
advertise the nec'y metadata to enable something like SPF, then i would find
it far easier to filter the remaining drivel in my inbox, which would just
be spam and e-mail (listed in order by volume) -- no more mailbot responses
to messages i never sent.

the economic benefit that will actually cause something like SPF to come into
wide use is different yet again -- it's not to make it easier to filter the
remainder, and it's not to stop spam. it's to protect trademarks owned by
large e-mail providers ("@hotmail.com" being one, "@yahoo.com" being another)
from dilution. everything that happens on the internet these days happens
for economics-related reasons. i'm glad that companies bigger and richer
than i am find it in their own selfish best interests to push something like
SPF -- that means it'll happen. that my own reasons differ from theirs is
immaterial. that they have to mismarket it as a spamstopper to get corporate
and investor support for it is also immaterial. the fact is, it's coming --
and it's useful, just not for the advertised reasons, or a universal reason.

i don't agree. i think it's overengineered and that a simpler solution like the one at <http://sa.vix.com/~vixie/mailfrom.txt&gt;

oh, hear hear.

Then there's Sender-ID. Bulky XML in DNS, sigh.

should have been deployed years ago, but i don't think SPF, or things like SPF, are at all worthless.

every time someone forges one of my domains or e-mail addresses as a spam source, i get all kinds of bot-mail telling me that what the spammer tried to do didn't work. quite a lot of challenge/response nonsense. quite a few majordomo/etc listbot error messages. a whole pile of mailer-daemon@ errors.

True, but bounces, and anything else with NULL return path, can be taken care of with SRS.

Bogus bounces are probably the most annoying non-spam email problem, and we do not need SPF to kill those. Hence, given a better solution to the only pressing problem we know SPF can solve, SPF is worthless.

For the other problems, well, SPF just isnt going to solve them. So SPF will tell you that client.acme.net is indeed allowed to send mail from foobar.com, but that describes only trust between foobar.com->client.acme.net. I am no wiser at all as to whether foobar.com is worthy enough to send me email. And given that there are *millions* of domains, and they can be registered by anyone within minutes, I'm unlikely *ever* to be able to make any use of the knowledge that foobar.com allows client.acme.net to send mail on their behalf to discriminate between genuine and spam email. (other than whitelisting clients i trust - but i dont need SPF for that).

Indeed, you've been saying this for years. :wink:

(which is largely how i've come to my own opinion :wink: )

if all mailbots learned to speak something like SPF, and my domains all advertise the nec'y metadata to enable something like SPF, then i would find it far easier to filter the remaining drivel in my inbox, which would just be spam and e-mail (listed in order by volume) -- no more mailbot responses to messages i never sent.

See:

   http://www.libsrs2.org/
   http://www.libsrs2.org/srs/srs.pdf
   http://asarian-host.net/srs/sendmailsrs.htm

And be happy, and realise "SPF is worthless" :wink:

the economic benefit that will actually cause something like SPF to come into wide use is different yet again -- it's not to make it easier to filter the remainder, and it's not to stop spam. it's to protect trademarks owned by large e-mail providers ("@hotmail.com" being one, "@yahoo.com" being another) from dilution.

Ah, ok. Yes, I've read you making above argument before and, aye, it's a very fair point. But, is it enough of a reason? It seems like a fallback reason, for use when other answers to "what actual real problems does SPF solve?" are not forthcoming.

Is it really worth it for every domain owner on the planet (including spammers!) to implement SPF records in DNS, and the resulting forwarding breakage, simply to provide some fairly intangible "dilution protection" for, primarily, the very small subset of widely-known domains out there?

It would prevent joe-jobs, yes. But how bothersome are those, given that the bounces can be dealt with with the far less intrusive SRS?

everything that happens on the internet these days happens for economics-related reasons. i'm glad that companies bigger and richer than i am find it in their own selfish best interests to push something like SPF -- that means it'll happen. that my own reasons differ from theirs is immaterial. that they have to mismarket it as a spamstopper to get corporate and investor support for it is also immaterial. the fact is, it's coming -- and

Well that depends. At the moment it looks like the clients will implement a standard that most of the servers will not!

Also, I doubt I'll be implementing SPF myself. Indeed, to implement SPF I would have to list the MTAs of at least several irish ISPs, and probably more, as I have users who only receive email via my systems, but dont send it via systems.

yes yes, MSA.. but I dont even know most of these people except as usernames in a password file, they're mostly non-technical, and I dont intend to track them down one by one and go visit them to reconfigure their MUAs for them. And even if i did, no doubt they also have /other/ email addresses, eg one from their ISP, and many popular, particularly older versions of, MUAs have problems with allowing one to configure SMTP/MSA according to From address, sigh.

it's useful, just not for the advertised reasons, or a universal reason.

Ah, absolutely yes.

regards,