Subject: Re: [Asrg] Re: SPF abused by spammers

From: Peter Bowyer <[email-masked]>
Date: Fri, 10 Sep 2004 13:57:54 +0100

On Fri, 10 Sep 2004 13:50:33 +0200, Markus Stumpf
<[email-masked]> wrote:
> On Thu, Sep 09, 2004 at 06:54:59PM -0500, Jim Witte wrote:
> >   Why not try to get the press to grab something the SPF *can* do -
> > like perhaps stop the flood of V1@GR@ and C10L1S ads that keep filling
> > my inbox, coming from God-knows where.  Or the porn, or the occassional
> > spam I get that's in either Chinese, Japanese, or Korean (I read none,
> > but it's in *something* I can't read).
> 
> Sorry, but I really fail to see how SPF can do all this.
> SPF *could* do it *if* the spammers forge a domain that is using
> SPF records *and* the sending IP is not authorized by the SPF settings.
> 
> Spammers run bot networks with up 500000 hosts - maybe more.
> Just have a look at your maillogs
>   cooldictionary.com
>   forbetterjobs.net

<snip list of domains>

OK, so you know those domains belong to spammers. If you receive mail
apparently from one of those domains which passes SPF, you *know*
you've received a spam. Thanks, spammer, for confirming your identity
and making it easy for us.

An SPF failure is a de-facto reson to block (assuming you don't like
to receive spoofed mail). An SPF pass is an input to your reputation
system, which may confirm a blacklist entry and produce a 'block', or
confirm a whitelist entry and produce an 'accept'.

Peter

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 10 Sep 2004 16:17:30 +0200

> and making it easy for us.

So what? As I wrote it is peanuts for them to allocate their domains out
of a pool as big they want it to have. With 4 digits + 2 chars you can
create about 6.5 millions different domains. Burning 100 of them each day
costs them 500 dollars probably less and they can burn with 100 a day for
about 178 years. Add two more digits and you can burn 1000 a day for the
same period.

How fast will the domain blacklists adapt? Do they have a 10 minutes
window? This is kewl so they only need 144 domains a day to burn if they
use each one for only 10 minutes and never ever again.
It takes only 5 minutes to add new spammer domains to the blacklists?
No problem, they use 288 domains each day, each for 5 minutes.
With 4 digits and 2 chars to randomize they can "work" for 60 years
burning 300 domains a day.

This all is simple math. And please don't provide solutions like
"then we'll block all domains with the pattern"
    *[a-z][a-z][0-9][0-9][0-9][0-9]*
there are 15 different combinations of 2c and 4d.
And sorry, if I want to add all this to blocklists I can do it right now,
I don't need SPF for that. Blocking according to this pattern will also
hit a lot of innocent domains.

Get it, SPF doesn't help in *any* way to block spam in significant numbers.
It is a matter of simple math to prove it.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 10 Sep 2004 11:05:28 -0400 (EDT)

It's an arms race, as always.  No single weapon wins.

SPF helps.  Here's how, in the presence of domain-burning
SPF-publishing spammers:

1. Greylisting:  Email from a new domain that passes SPF is greylisted
   for 30 minutes.

2. Spamtraps: Email that hits a spamtrap, and which passes SPF, causes
   the domain to be blacklisted.  This will typically take well under
   30 minutes for a serious spam run.

3. When the greylisting expires, the domain is blacklisted.

The spammer has an incentive to push out crap quickly, in order to get
a lot past the non-greylisting receivers before he hits the blacklist;
he also has an incentive to push crap out slowly, hoping to get some
through to the greylisting sites before he hits the blacklists.

Seth

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 10 Sep 2004 11:35:17 -0400 (EDT)

> burning 300 domains a day.

Perhaps temp-fail all mail from any domain not whitelisted? Accept mail
only after 4 hours have gone by AND the domain hasn't shown up on a
blacklist? 

I don't mean to defend authentication as a means of spam reduction, as I
don't think in the end it will be helpful. But I don't think proponents
are stupid, it does have possibilities and might contribute to the
solution. It rather depends on what institutions develope in response.
Will reasonably large whitelists become available? I don't know. 

One problem is that the publicly available advocacy is aimed at relatively
ill-informed people. I am sure in private discussions with knowledgable
people advocates can put forward better thought out, but perhaps
complicated arguments. This forum, with its high level of ridicule,
perhaps doesn't qualify for the a-list arguments.

Dan Feenberg

---

From: "Tim Bedding" <[email-masked]>
Date: Fri, 10 Sep 2004 17:43:31 +0100

Seth

> 1. Greylisting:  Email from a new domain that passes SPF is greylisted

Is this the same as the following?

1. Email from a domain of unknown-reputation is greylisted

If so, then a spammer would wait until his domain goes green
and he can then send email in the interval before the
domain is black-listed.

This defeats the grey list.

Regards
Tim

Crusade - The Path of Sorrows
Galen: There is no planning, no design
  to our lives.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 10 Sep 2004 18:48:50 +0200

> 3. When the greylisting expires, the domain is blacklisted.

Hmmm ...
If you delete the SPF relation in the above items, and substitute
"domain" with "IP address" so that it reads:

*> 1. Greylisting:  Email from a new IP address is greylisted for 30 minutes.
*> 2. Spamtraps: Email that hits a spamtrap, causes the IP address to be
*>    blacklisted.  This will typically take well under
*>    30 minutes for a serious spam run.
*> 3. When the greylisting expires, the IP address is blacklisted.

What makes the real difference? Is there any real advantage of SPF over
the IP address method?

When I looked at greylisting (the classic triple method) I checked the
logfiles of one of our mailservers of 5 days. We had 1.2 million transfers
and 980,000 unique triples (i.e. 87%). We burn a lot of spam with
"artificial" backup MX hosts that accept *everything* but return 4xx
at the end of the DATA phase, so I'd say the spam part of those 1.2
million transfers is around 60% or so.
If we delay for 4 hours (ignoring all the problems with Yahoo mailservers
and Lotus and other broken MTAs that cause failures) still a significant
portion of legitimite message to our customer will be delayed for about
half a work shift and messages sent shortly after noon will not make it
to the recipient the same day.

Our support hotline is flooded with calls if a larger German Mail Service
Provider have problems, because customers ask "I am waiting for a
message that usually takes 2 minutes and it hasn't arrived within
30 minutes now. Is your mailserver dead or what?". This is also
the case if they wait for an email of a random communication partner.

People rely on emails as a fast and reliable medium. The classic form of
greylisting IMHO breaks the first assumption and because of that we
didn't put it into production. IMHO (I haven't talked to customers about
that, however, but it is true for me at least) people tend to accept
some spam as long as email communication is fast.

I did write "classic greylisting" as we DO use a form of greylisting.
If in a multi-RCPT transfer one of the addresses causes a permanent
failure the while session (even with intermediate RSETs) is temporarily
rejected (the bad address is signaled permanent).

	\Maex

---

From: Barry Shein <[email-masked]>
Date: Fri, 10 Sep 2004 18:43:47 -0400

This is all based on an assumption of spammers using static domains.

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD
The World              | Public Access Internet     | Since 1989     *oo*

---

From: Barry Shein <[email-masked]>
Date: Fri, 10 Sep 2004 19:01:37 -0400

> It's an arms race, as always.  No single weapon wins.

This is a cliche which could apply just as well to painting ourselves
blue and dancing a cha-cha.

 > 1. Greylisting:  Email from a new domain that passes SPF is greylisted

What about from the huge dialup/ppp domain pools like AOL, ATT,
earthlink, tiscali, interbusiness, tpnet.pl, retevision.es,
prod-infinitum.mx, plala.or.jp, hkcable.com.hk, comcast, verizon, etc
etc etc etc.?

Because it's zombie'd PCs on those broadband nets which account for
nearly all the spam.

 > through to the greylisting sites before he hits the blacklists.

This is a vague, probabilistic attack on an outdated method of
spamming.

-- 
        -Barry Shein

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 10 Sep 2004 19:25:12 -0400 (EDT)

> blue and dancing a cha-cha.

Maybe that's how world.std.com fights spam; I wouldn't know.

> prod-infinitum.mx, plala.or.jp, hkcable.com.hk, comcast, verizon, etc

What about them?  In particular, what domain does the spam _claim_ to
be coming from?  AOL isn't about to publish SPF records for its dialup
lusers; neither is ATT, earthlink, etc.  Why should they?  They'd only
publish such records for their own outgoing servers.

> Because it's zombie'd PCs on those broadband nets which account for

What domain will they claim?  That's the key point.

> This is a vague, probabilistic attack

What part don't you understand?

And stopping each spam with a probability of 99% may be
"probabalistic" but I like it.

> on an outdated method of spamming.

It works fine against zombie armies.  What's the newer method?

Seth

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 10 Sep 2004 19:44:11 -0400 (EDT)

> 1. Email from a domain of unknown-reputation is greylisted

Yes.

> This defeats the grey list.

The idea is that the spamtrap addresses will cause blacklisting before
the domain can green off the greylist.

Seth

---

From: Barry Shein <[email-masked]>
Date: Fri, 10 Sep 2004 20:59:37 -0400

> publish such records for their own outgoing servers.

Why not? Why wouldn't they? Why shouldn't they?

Some ISPs have a policy: No direct mail sending, no port 25, that is
certainly true.

But many others do not have any such policy, nor are they likely
to. And much of the common mail software is happy to do direct
delivery rather than forward through an ISP official relay.

So unless you can somehow argue that the bazillion connections from
broadband and dialup ports I see all day are going to disappear I
think it's safe to say that either these ISPs publish SPF records for
each and every one of those pool/dhcp, or even statically assigned
(you know what I mean, the cheap seats), addresses, or they'd better
start getting their customers used to the change in policy coming up
when and if something like SPF happens and they refuse. Or maybe they
can sell them SPF entries (hmmmmm.)

More importantly, I suppose we can GUESS what actual practice might or
might not be.

But perhaps we'd be better off being SPECIFIC (prescriptive) about
what is actually required by a standard.

And I don't see anything inherent in SPF that stops an ISP from
publishing a few million SPF records to cover all their IP allocation
if their policy is that any customer may send directly to port 25. One
pretty much implies the other.

Have we found yet another fatal flaw in SPF? Or am I really missing
something (I can't say I've deeply thought thru this aspect, it's just
come up.)

 > What domain will they claim?  That's the key point.

Well, I assume if I were a DSL customer with verizon.net then it'd be
verizon.net. What else?

Oy, what a mess. We're really getting nowhere, fast.

-- 
        -Barry Shein

---

From: Matthias Leisi <[email-masked]>
Date: Sat, 11 Sep 2004 11:56:21 +0200

> can sell them SPF entries (hmmmmm.)

$DIALUP_ISP that adds it's whole dialup-range as "legitimate 
mailservers" for $DIALUP_DOMAIN is of course free to do so, but that 
would be less-than-intelligent.

The whole point of "Sender IP authentication" is to designate legitimate 
sources for mails from a certain domain. If $DIALUP_ISP trusts it's 
customers so much as to allow them to be legitimate sources - fine, 
that's their decision. But they will cause problems for their own domain 
name in doing so.

> pretty much implies the other.

They can only publish SPF records for their /own/ domain(s). Publishing 
"a few million" legitimate sources is certainly not a good way to build 
trust in these domain(s).

-- Matthias

-- 
Brain-Log                               http://matthias.leisi.net/

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 13 Sep 2004 17:14:37 +0200

> the domain can green off the greylist.

At which point do greylist implementations make the entry for a triple?

How about a
   MAIL FROM
   RCPT TO
   RCPT TO
   RCPT TO
   RCPT TO
   RCPT TO
   [ ... ]
   RSET
and come back 30 minutes later.

	\Maex

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 13 Sep 2004 17:40:59 +0200

> would be less-than-intelligent.

This is why SPF is totally useless for anti spam.
Adding SPF in some cases has nothing to do with intelligence but with
contracts and if AOL puts records in DNS that don't allow someone to mail
from a vaild AOL access (DSL, Dialin) with his valid AOL email address any
longer he'll probably sue them for breaking contract. At least in
Germany they see "Internet access" and I don't see anything in the
contract that forces me to use their MTAs.

Sometimes I have the impression people talking about all those methods
don't have many - if at all - experience in running Internet for comercial
customers.
For my very private domain I can reject eMails as I want, I can add SPF
records ... it's all mine.
Running Internet services (e.g. mailservers) for (business) customers
is something completely different.

	\Maex

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 13 Sep 2004 17:48:34 +0200

> and come back 30 minutes later.

Such a pattern could be a reason to blacklist the sender, too. 

	hp

-- 
   _  | Peter J. Holzer    | Je höher der Norden, desto weniger wird
|_|_) | Sysadmin WSR       | überhaupt gesprochen, also auch kein Dialekt.
| |   | [email-masked]         | Hallig Gröde ist fast gänzlich dialektfrei.
__/   | http://www.hjp.at/ |   -- Hannes Petersen in desd
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 13 Sep 2004 12:17:54 -0400 (EDT)

> This is why SPF is totally useless for anti spam.

That stupid people will get it wrong?

> Adding SPF in some cases has nothing to do with intelligence but
> with contracts

Do you have a contract about provision of SPF?  With whom?  What does
it say?

> and if AOL puts records in DNS that don't allow someone to mail from
> a vaild AOL access (DSL, Dialin) with his valid AOL email address
> any longer

1. SPF records don't prevent anyone from mailing; they merely provide
   the recipient more information about how to handle that mailing.

2. AOL _never_ intentionally allowed people to mail directly from
   their connections without going through AOL's mailservers.

> he'll probably sue them for breaking contract.

And lose.  Have you read the contract?

> At least in Germany they see "Internet access" and I don't see
> anything in the contract that forces me to use their MTAs.

Do you see anything in the contract that requires them to validate
email sent not through their MTAs?

> Sometimes I have the impression people talking about all those
> methods don't have many - if at all - experience in running Internet
> for comercial customers.

You mean like [email-masked]?

Seth

---

From: Richard Rognlie <[email-masked]>
Date: Mon, 13 Sep 2004 12:27:26 -0400

> Such a pattern could be a reason to blacklist the sender, too. 

If you are greylisting, it's that pattern that well behaved MTAs will use.

doubtful on the same connection, since I'd expect that to timeout.

so you'll use greylist behaviour to justify blacklist creation.

Ok... I won't send mail there.

-- 
 /  \__  | Richard Rognlie / Sendmail Ninja / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/~rrognlie    <rrognlie at gamerz.net>
 /  \__/ |      The early bird gets the worm
 \__/    |      But the second mouse gets the cheese

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 13 Sep 2004 12:29:06 -0400 (EDT)

"Peter J. Holzer" <[email-masked]> wrote, in quoted-unreadable:
>>=20
>>=20
> Such a pattern could be a reason to blacklist the sender, too.=20

If the response to the RCPT TOs was 251, then perhaps blacklist (why
would a sender do that, anyway?).  If they were all 451, then RSET is
a reasonable response (nobody wants the message, why continue?) and 30
minutes is a reasonable retry period.

Seth

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 13 Sep 2004 21:29:37 +0200

> > Adding SPF in some cases has nothing to do with intelligence but

We have contracts with our customers. We provide email addresses for
customers without their own domain within our "for customers domain".
Neither the "Internet access" nor the "use of the email address" require
the customer to use our mailservers.

>    the recipient more information about how to handle that mailing.

No, but they discredit (aka unauthorize) them, which is wrong.

>    their connections without going through AOL's mailservers.

Ah, do they intentionally deny it? If not there is x-x-x (I don't know the
english term) but it means that if you can use something that is not
explicitely stated in your contract for a period of time it can be seen
as a positive part of the contract and the partner is not free to take
it away from you "just because".

> And lose.  Have you read the contract?

I have read their AUP on their homepage. It says:
    2. AOL Services
    2.1
    - you get access to the AOL internal service
    - you get access to the Internet
    - you get access to send and receive emails
    2.3
     AOL tries to talk do everythin possible that there are no restrictions
     or adverse effects using AOL as far as this is technically possible.
There is a passus that says I may not send illegal conteant and that I
shall not send mass emails or spam.
That's it. The AUP is all you get regarding the contract if you order
online (at least it is all you get until you say "yes order it now").

> email sent not through their MTAs?

They do not validate emails by setting SPF records. SPF records say
that an IP is authorized as a mail agent sending emails that use a
particular domain in the 2821.FROM.
If I rightfully use a email address to send emails and my contract for
using this email address does not restrict me to using a special gateway
to use that email address, the owner of the domain for those email
address has no right whatsoever to mark my emails as not authorized
from that server that I choose to use.

> You mean like [email-masked]?

Don't know ... is [email-masked] a sex god?
Our postmaster doesn't know how to run Internet for commercial customers.
That's not his job. His job is to sort the emails, classify them and
answer questions. He doesn't know (much) about deployment problems, mail
server balancing, customer contracts, legal affairs, future strategies,
anti spam risks. That's not his job.

>From mail.com's AUP:
    Mail.com., ("Mail.com") shall provide e-mail products and services
    ("the Mail.com Service") to you ("User") under the terms and
    conditions of this Mail.com User Agreement ("the Agreement").
    [ ... ]
    User shall not use the Mail.com Service for spamming.
    [ ... ]
    Should User cause e-mail that does not meet these criteria to be sent
    through Mail.com's servers, User understands and agrees that this is a
    breach of Mail.com's Terms of Service, which may result in User's
    account being terminated, with or without notice, and/or legal action
    against User for misuse of the Habeas trademark and copyright.

Do they consider an email address @mail.com as part of the Mail.com
Service? Their AUP does not define what exactly the "service" is and it
surely doesn't force anyone to use a @mail.com address only with mail.com
servers. They don't state there that any email using @mail.com addresses
and not sent through your mailservers is unauthorized.
So with adding SPF records have they informed all of their customers
about what they did? Don't know about the USA but in Germany this is
a change in contract and gives each customer an immediate right to
cancel.

	\Maex

---

From: Barry Shein <[email-masked]>
Date: Mon, 13 Sep 2004 17:35:30 -0400

> would be less-than-intelligent.

So your point relies on $D* never doing anything that is
less-than-intelligent?

But this isn't a technical hurdle, merely a presumption about how $D*
might behave.

 > that's their decision. But they will cause problems for their own domain 

They may have little choice, from their point of view, either because
they perceive this as a marketing aspect (why don't they block port 25
now?), or their economic/business model doesn't allow for the sort of
e-mail infrastructure which provides for officialy relays. Or, more
likely, a little of each (since one policy tends to lead to the
other.)

 > trust in these domain(s).

Can't wanadoo.fr publish an SPF record allowing
ABordeaux-251-2-10-162.w82-125.abo.wanadoo.fr to send email directly?

Not "are they likely to", or "it wouldn't seem to be in their best
interest", but just: Can they or not?

I admit I might be missing something here but thus far it's been like
grabbing smoke trying to get to the bottom of this.

-- 
        -Barry Shein

---

From: "Peter J. Holzer" <[email-masked]>
Date: Tue, 14 Sep 2004 00:28:23 +0200

> > > > The idea is that the spamtrap addresses will cause blacklisting before
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> If you are greylisting, it's that pattern that well behaved MTAs will

I seem to have been quite confused when I was writing that, sorry.

What I was thinking of was that the RSET would be sent even though some
addresses (e.g., the the spamtrap mentioned by Seth) would return a 250
reply to avoid triggering the spamtrap before the greylist period runs
out.

That could be detected (although there is a certain probability of false
positives), but that isn't necessary. Much better to trigger the
spamtrap when receiving the RCPT TO address than waiting for the DATA
command.

	hp

---

From: "Peter J. Holzer" <[email-masked]>
Date: Tue, 14 Sep 2004 01:17:08 +0200

On 2004-09-13 17:35:30 -0400, Barry Shein wrote:
> now?),

Blocking port 25 is a lot more drastic. Even if most free email
providers offer submissions on port 587 today (do they?), most users
won't know that and if connecting to port 25 of their favorite email
provider doesn't work, they will call their ISP's hotline.

Publishing an SPF record won't affect most users (they use either the
ISPs relay, or that of their email provider, or they have their own
domain) and for those which are affected, the effect will be comparable
to that of DULs: They find that their mails are rejected by a small (but
growing) number of MXes. 

> or their economic/business model doesn't allow for the sort of
> e-mail infrastructure which provides for officialy relays.

Are there "pure" ISPs in the mass market? My impression is that at least
in Austria and Germany you can't even get a (cheap) internet connection
without a pop mailbox, a relay host and some web space if you want it (the
quality of these services is often poor, but that's another story).

> interest", but just: Can they or not?

They can not. 

They can publish an SPF record allowing
ABordeaux-251-2-10-162.w82-125.abo.wanadoo.fr to send mails with
a sender domain of wanadoo.fr directly (and probably lots of
other domains, too). They cannot publich an SPF record allowing
ABordeaux-251-2-10-162.w82-125.abo.wanadoo.fr to send mails with a
sender domain of ietf.org or hjp.at.

OTOH, they can easily publish an SPF record which allows everyone to
send mail with a sender domain of wanadoo.fr.

In any case I think it is rather uninteresting whether
wanadoo.fr will publish an SPF record allowing
ABordeaux-251-2-10-162.w82-125.abo.wanadoo.fr to send mails from
wanadoo.fr. If they do, they take responsibility for mail that host
sends out, and they will have to bear any consequences (these may well
be less severe than those of not publishing the record, time will tell).

The big problems of SPF are something else:

1) Every spammer can easily register lots of domains (they already do)
   and publish SPF records for those. The pure existence of an SPF
   record doesn't tell you anything. You also need a reputation system.

2) Lots of domain owners don't publish SPF records and probably won't
   ever do so. So the nonexistence of an SPF record also tells you
   nothing.

3) Because of the above two points, many MTAs won't reject mails which
   don't pass SPF, so publishing an SPF record will have little effect.
   (which feeds back to problem 2)

	hp

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 13 Sep 2004 19:49:43 -0400 (EDT)

>    don't pass SPF, so publishing an SPF record will have little effect.

We need to distinguish between "doesn't pass" (which can happen when
SPF isn't published" and "fails" (which happens when SPF is published
and denies that IP).  In the latter case, at the very least, I don't
want to see a bounce.

Seth

---

From: Barry Shein <[email-masked]>
Date: Tue, 14 Sep 2004 17:03:04 -0400

I will admit that I am *almost* beaten into the ground in pure
frustration by the lengthy verbiage and misinterpretations of the
questions but ONE MORE TIME...(I know I know it's all my fault.)

Can wanadoo.fr publish an SPF record allowing the PC which is
currently assigned the host name:

      ABordeaux-251-2-10-162.w82-125.abo.wanadoo.fr

to send mail claiming to be from:

      [email-masked]

I say they can and likely will, but more importantly that spammers who
grab such a host as a zombie can use this to send all the mail they
want past any SPF.

-- 
        -Barry Shein

---

From: Barry Shein <[email-masked]>
Date: Tue, 14 Sep 2004 17:48:24 -0400

> it away from you "just because".

Probably "estoppel".

-- 
        -Barry Shein

---

From: "Peter J. Holzer" <[email-masked]>
Date: Wed, 15 Sep 2004 00:20:13 +0200

On 2004-09-14 17:03:04 -0400, Barry Shein wrote:
> I say they can

Of course they can. 

> and likely will,

Why should they? No legitimate user would want to send mail as
[email-masked], because he will
never be able receive an answer (assuming that this is an address in a
dynamic address pool). The legitimate user will send want to send mail
as [email-masked], or maybe [email-masked].

Publishing such records makes no sense at all. Publishing records
allowing the whole dial-in pool to send mail as [email-masked] makes
at least some sense and some providers may do that.

Anyway, if wanadoo chooses to publish such records, who cares? Does it
make any difference whether the spam comes from
<[email-masked]> or from
<[email-masked]>?

> but more importantly that spammers who

SPF doesn't stop spam. It doesn't even try to stop spam. All it does is
tell the recipient whether a certain IP address is allowed to send mail
on behalf of a certain domain.

This allows to domain owner to prevent forgeries (or rather, allows the
domain owner to publish information which will allow the recipient to
recognize the forgery easily), which will reduce bounces and misguided
complaints.

It may be used against spam together with a reputation system for
domains. But frankly, I don't see why a reputation system for domains
should be more effective than the existing reputation systems for IP
addresses (aka RBLs).

	hp

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 15 Sep 2004 01:51:17 +0200

> as [email-masked], or maybe [email-masked].

Not quite right.
There is a big difference between 2821.MAILFROM and 2822.From. I can
fake the 2821.MAILFROM and use my correct 2822.From and everybody will
be able to answer using a MUA. But I will not get bounces or error
messages. SPF uses 2821.MAILFROM.
I could use a lot of different providers and my email addresses with
them in 2821.MAILFROM and inject emails with always the same 2822.From.
Fine, all answers will be in the same mailbox and I would be still SPF
compliant.
The problem arises if I mistype an email address. Then I'll have to scan
all boxes with all providers to collect my bounces, because I cannot
forward them to my main box, as SPF breakes forwarding.

> on behalf of a certain domain.

If they add SPF records to allow each hosts to send mail as user@revDNS(host)
it would be on behalf of that certain domain (which in fact is a host).

> recognize the forgery easily), which will reduce bounces and misguided

And they all will have to learn that it is not sufficient to add SPF
records to the domain only.
What will happen (as per SPF) with emails sent with a sender address
    [email-masked]
or how about
    [email-masked]
The really funny thing is that - as www.your_domain is a CNAME -
you cannot even add a SPF record for www.your_domain, as CNAMEs does not
allow other RRs for the same LHS.
So you cannot prevent forgery with SOF abusing www.your_domain.

(I must admit I don't have a clue about how SPF handles CNAMEs, but I
doubt it will be possible as desired, as it will be impossible to say
    allow  www.your_domain from IPs ...
    asherah.wsr.other_domain does not send email at all
with www.your_domain -CNAME-> asherah.wsr.other_domain)

	\Maex

---

From: Barry Shein <[email-masked]>
Date: Tue, 14 Sep 2004 22:51:46 -0400

> as [email-masked], or maybe [email-masked].

Well, of course that's sensible, but the point really is that there is
little difference between hijacking your PC and just breaking into
your house and sitting down at your PC, as far as detectability of
intent goes.

So, if the ISP allows your PC to do direct delivery and will ACK your
SPF (however one might say that) then a zombie program on that PC will
be ACKed also.

I see a lot of that [email-masked]
kind of addressing here but ok, so perhaps it becomes as you say,
[email-masked] or [email-masked].

The point is, if wanadoo.fr's servers will ACK for that PC when the PC
tries to send from [email-masked] then it'll ACK for a zombie
program running on that PC also.

AND, I contend, there'll be millions of such PCs (infected or not.)

-- 
        -Barry Shein

---

From: David Maxwell <[email-masked]>
Date: Wed, 15 Sep 2004 10:31:52 -0400

> SPF (however one might say that) then a zombie program on that PC will
[...]
> AND, I contend, there'll be millions of such PCs (infected or not.)

If the ISP requires all mail to go through their servers, it's trivial
to detect an upsurge in number of emails from a particular sender. This
change (in concert with SPF, or other RMX method) would limit the number
of spam message sent to the number of legitimate emails sent. I know
many users who receive a 20:1 or higher spam ratio, so this would be a
significant reduction.

If the ISP doesn't require all mail to go through their servers, the
same limiting could be accomplished by having routers count outgoing
SMTP SYNs.

Current routers aren't optimized to do that, so requiring use of the ISP
mail servers is easier - but either way is possible.

-- 
David Maxwell, [email-masked][email-masked] -->
If you don't spend energy getting what you want,
	You'll have to spend it dealing with what you get.
					      - Unknown

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 15 Sep 2004 17:06:02 -0400 (EDT)

>      [email-masked]

Yes, they CAN.

> I say they can and likely will,

I have $100 that says they won't.  Want to bet on it?

> but more importantly that spammers who grab such a host as a zombie
> can use this to send all the mail they want past any SPF.

Only if it's published that way (which it won't be), be even if so,
all it would do is cause people to treat email from *@*.abo.wanaoo.fr
as likely spam.

Seth

---

From: [email-masked] (Claus Färber)
Date: 16 Sep 2004 23:02:00 +0200

Markus Stumpf <[email-masked]> schrieb/wrote:
> Then I'll have to scan all boxes with all providers to collect my
> bounces, because I cannot forward them to my main box, as SPF breakes
> forwarding.

It can't break forwarding for bounce message because bounce messages  
don't have a domain name in their 2821.MAILFROM.

Claus
-- 
http://www.faerber.muc.de

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 17 Sep 2004 16:52:36 +0200

> don't have a domain name in their 2821.MAILFROM.

Hmmm ... I can't find it anymore right now, but shouldn't SPF conform
bounces have a non empty envelope-sender, as a workaropund to prevent
spammers sending their messages with <> only?

	\Maex

---

From: Mark <[email-masked]>
Date: Fri, 17 Sep 2004 15:11:18 GMT

> spammers sending their messages with <> only?

Hello? Ever heard of HELO? :) Sending with en empty envelope-from, to try 
and circumvent SPF, is pointless: checks are done against HELO, in that case 
(as if tested against, say, postmaster@HELO). Consequently, since there is 
nothing to prevent, there is nothing to send "non empty" either (where empty 
was the case).

- Mark

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 18 Sep 2004 09:33:43 +0200

On 2004-09-15 01:51:17 +0200, Markus Stumpf wrote:
> be able to answer using a MUA.

Yes, but which MUA used by "normal" users does this? My point was that
ISPs wouldn't post such SPF records because such records are of no use
to (almost all) their legitimate users (Only work/cost for the provider,
but no benefit).

> What will happen (as per SPF) with emails sent with a sender address

Nothing. There are no mail addresses of this form. Every mail to will
either bounce with "Connection refused" or "550 no such user".

> allow other RRs for the same LHS.

I could change the CNAME to an A record, or I could add the SPF record
to asherah.my_other_domain. I just don't see the need.

> So you cannot prevent forgery with SOF abusing www.your_domain.

I don't need to. 

	hp

---

From: David Wilson <[email-masked]>
Date: 20 Sep 2004 15:29:21 +0100

> spammers sending their messages with <> only?

The use of an empty reverse path dates back to RFC 1123 (Section 5.3.3)
which states that delivery failure MUST [with the standard implication
of the upper-case] use a null reverse path. This is to avoid bounce
messages bouncing to and fro across the 'net.

RFC 2821 is somewhat ambiguous (in section 3.7), but it also can be
interpreted in saying that notification messages MUST use an empty
reverse path.

It also states that implementations SHOULD use standard forms for such
messages (for instance Delivery Service Notifications: RFC 3464).

Yes, spammers do use an empty reverse path. But if the generators of
notifications always used a standard format (which should be processed
by the UA in attempt to correlate the notification with a sent message,
and therefore should never be presented to the user as a normal message,
therefore spammers would not use it), then it would be possible to
distinguish between legitimate and illegitimate uses of an empty reverse
path.

<grumble>
But the reality is that every email processing vendor seems to invent  
their own format for bounces, which means that automatic processing is
not possible.

Which makes it a pain going through the mailbox for one's honeypot
addresses, trying to separate the bounces from the genuine rubbish.
</grumble>

But remember, SPF is _primarily_ about combating forgery. That, together
with other mechanisms, may help to stop spam. But the main benefit is
preventing people (and not just spammers) sending mail from addresses
which they are not entitled to use. ONe might say that a message with an
empty reverse path does not claim to be from anyone, therefore there is
no risk from forgery.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 22 Sep 2004 01:45:56 +0200

On Fri, Sep 17, 2004 at 03:11:18PM +0000, Mark wrote:
> and circumvent SPF, is pointless: checks are done against HELO, in that 
> case (as if tested against, say, postmaster@HELO). Consequently, since 
> there is nothing to prevent, there is nothing to send "non empty" either 
> (where empty was the case).

That was the reference I didn't find.
Which leads to the problem with
   HELO [10.0.0.1]
or
   HELO i222-150-67-241.s04.a013.ap.plala.or.jp

which would require all ISPs to add SPF records to all entities and
raises again the problems Barry Shein has addressed.

And: if I am a customer of some.isp and my current revDNS entry for the
IP I am using is
    1.0.0.10.rev.dsl.some.isp
should I be allowed to send a bounce on behalf of that address, i.e. use
the name or IP in the HELO string?

	\Maex

---

From: Mark <[email-masked]>
Date: Wed, 22 Sep 2004 01:25:35 GMT

>> Hello? Ever heard of HELO? :) Sending with en empty envelope-from,
>> to try and circumvent SPF, is pointless: checks are done against
>> HELO, in that case (as if tested against, say, postmaster@HELO).
>> Consequently, since there is nothing to prevent, there is nothing to
>> send "non empty" either (where empty was the case).
>

Well, only if that ISP allows people to send mail from their home IP 
addresses. Otherwise, the ISP just has to create SPF records for its own 
outgoing mail servers.

If people on a home network get their own $9 bucks domain name, they could 
(and probably should) set their HELO string to their domain name, if they 
are also sending from their home IP address(es). Then they can, themselves, 
publish, or have published, SPF records for that domain. Setting HELO to 
their PTR (if unchangeable, and provided by the ISP, and in the above format 
you described), would not make much sense, in that case.

> And: if I am a customer of some.isp and my current revDNS entry for
> the IP I am using is
>
> should I be allowed to send a bounce on behalf of that address, i.e.
> use the name or IP in the HELO string?

I doubt you'll get far with a 10.0.0.1 address. :) But, assuming a public 
address, why should you not be allowed to send a bounce from that address? 
SPF "classic" does not check against your PTR; so, if you have proper SPF 
records for your domain/HELO, why not? If your HELO is set to your own 
domain name, and an A record lookup of the HELO matches your IP address, 
you're in the clear.

- Mark