Debian Developers - SPF (was: Re: Bug#257644: ITP: libspf2 -- Sender Policy Framework library, written in

Author

SPF (was: Re: Bug#257644: ITP: libspf2 -- Sender Policy Framework library, written in

Adrian 'Dagurashibanipal' von Bidder

2004-07-05, 7:51 am

Isaac To

2004-07-05, 5:54 pm

>>>>> "Adrian" == Adrian 'Dagurashibanipal' von Bidder <avbidder@fortytwo.ch> writes:

Adrian> SPF does nothing (almost) against spam. It can be used to
Adrian> fight certain forgery issues (where it would IMHO be
Adrian> better to just use PGP or S/MIME anyway)

Unluckily, PGP and S/MIME is very hard to do on the mass. It is much
easier to ask people to use a MSA for sending mail, than to ask people
to use a signature. And there is nothing which prevent you from doing
both. I've tried for 4 years, before Gnus's version stopped
supporting mailcrypt. Basically, nobody care to verify my signature.
And then, how the others will treat your mail if it lacks a signature?
As far as I can see, nobody even come close to care.

Adrian> The only thing it can do is specify which IPs are allowed
Adrian> to send email with a certain domain part. And AFAICT it
Adrian> does this only for envelope addresses, anyway, and not for
Adrian> mail headers, so phishing attacks will still be possible
Adrian> (who looks at envelope addresses?).

Yes. It is to support forwarding. At least it gives you a
trust-worthy return address whenever you have something that you find
untrustworthy.

Adrian> OTOH it *may* make sense for certain companies, they can
Adrian> say that their email is only to be sent over their
Adrian> network. But I am not clear what the benefit for those
Adrian> companies is.

If you're using Linux and still receives mails from other organization
telling you that your E-mail addresses are originating spam or virus,
you can---by publishing your SPF record---tell others to ignore those
mails because they, according to the usage pattern of your
organization, clearly be identified to be not originating from your
organization. You can then hope that others---by honoring those
records---stop processing those mail, helping them to prevent anything
wrong which is done by those mails, and at the same time helping
yourselves by not having to process and throw away those
bounces---either manually or automatically.

Adrian> But it will really get used to force users of free
Adrian> web-email to use the web mail interface to send email
Adrian> *only* (so the banner ads can be seen...)

When reading the web mails, you must read those little banner ads,
unless the site allows you for POP access, or you have somebody taking
the trouble to access the web to get your mail, filter out the banner
ad, and save it in your local mail spool. It just says the same can
also happen to sending: you must read those little banner ads, unless
the site allows you for MSA access, or you have somebody taking the
trouble to access the web to send your mail, ignoring those little
banner. So it is really nothing new.

Adrian> And it breaks '.forward' style forwarding.

(a) have your MTA support SRS, or (b) have your MTA process the SPF
and turn off SPF processing in your local computer.

Regards,
Isaac.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Erik Aronesty

2004-07-22, 8:48 pm

Isaac To <iketo2@netscape.net> wrote in message news:<2eDJN-1JN-11@gated-at.bofh.it>...
>
>
> Adrian> And it breaks '.forward' style forwarding.
>
> (a) have your MTA support SRS, or (b) have your MTA process the SPF
> and turn off SPF processing in your local computer.

SPF breaks forwarding and it breaks mail backup servers. SPF contains
a loophole called "SRS" that allows you to get forwarding to work.
Spammers can use this loophole to get around SPF. Thus SPF is ...
well ... broken.

Use IM2000.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Isaac To

2004-07-23, 2:50 am

>>>>> "Erik" == Erik Aronesty <erik@zoneedit.com> writes:

Erik> Spammers can use this loophole to get around SPF. Thus SPF
Erik> is ... well ... broken.

This complain to SRS is something new to me, and such knowledge will
enhance our understanding on naysayers of SPF. Care to take a look at

http://www.libsrs2.org/srs/srs.pdf

and tell everybody here what is your objection about the scheme that
would allow spammer to use SRS to send spam?

Regards,
Isaac.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Erik Aronesty

2004-07-23, 5:53 pm

Isaac To <iketo2@netscape.net> wrote in message news:<2kYrZ-u1-3@gated-at.bofh.it>...
>
> Erik> Spammers can use this loophole to get around SPF. Thus SPF
> Erik> is ... well ... broken.
>
> This complain to SRS is something new to me, and such knowledge will
> enhance our understanding on naysayers of SPF. Care to take a look at
>
> http://www.libsrs2.org/srs/srs.pdf

That pdf didn't work for me. I read this instead.
http://spf.pobox.com/srspng.html

I was thinking that a spammer could creates an envelope address with
"SRS0+hash=timestamp=aol.com=bob@throwawaydomain.com" and a From:
bob@aol.com with valid SPF info in throwawaydomain.com.

They, obviously, could do this. Someone who sees that spam will,
likely, blame aol.com and not "throwawaydomain.com". Just like
spammers use throwawar IP's to send mail, they will use throwaway
domains to masquerate as forwarding agents - just like they use
throwaway IP's now.

Does this tool justify the complexity and effort of implementing SPF?

Or should we be moving towards something like IM2000?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Isaac To

2004-07-28, 6:23 pm

>>>>> "Erik" == Erik Aronesty <erik@zoneedit.com> writes:
[vbcol=seagreen]

Erik> That pdf didn't work for me. I read this instead.
Erik> http://spf.pobox.com/srspng.html

That won't work: it's too brief to tell you what it actually had done
to try to prevent what you have suggested. Instead, please visit
Google, search for http://www.libsrs2.org/srs/srs.pdf and click on
"View as HTML".

Regards,
Isaac.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Isaac To

2004-07-28, 6:23 pm

>>>>> "Erik" == Erik Aronesty <erik@zoneedit.com> writes:

Erik> I was thinking that a spammer could creates an envelope
Erik> address with
Erik> "SRS0+hash=timestamp=aol.com=bob@throwawaydomain.com" and a
Erik> From: bob@aol.com with valid SPF info in
Erik> throwawaydomain.com.

Erik> They, obviously, could do this. Someone who sees that spam
Erik> will, likely, blame aol.com and not "throwawaydomain.com".
Erik> Just like spammers use throwawar IP's to send mail, they
Erik> will use throwaway domains to masquerate as forwarding
Erik> agents - just like they use throwaway IP's now.

BTW, forwarding is normally set up manually, e.g., you might want your
university to forward all mails to you home ISP account. So you know
exactly who are your valid forwarders (here, your university only).
Your case would then be trivially blocked in the client side.

Regards,
Isaac.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Erik Aronesty

2004-07-28, 6:23 pm

Isaac To <iketo2@netscape.net> wrote in message news:<2lxJ5-8oQ-17@gated-at.bofh.it>...
>
> Erik> I was thinking that a spammer could creates an envelope
> Erik> address with
> Erik> "SRS0+hash=timestamp=aol.com=bob@throwawaydomain.com" and a
> Erik> From: bob@aol.com with valid SPF info in
> Erik> throwawaydomain.com.
>
> Erik> They, obviously, could do this. Someone who sees that spam
> Erik> will, likely, blame aol.com and not "throwawaydomain.com".
> Erik> Just like spammers use throwawar IP's to send mail, they
> Erik> will use throwaway domains to masquerate as forwarding
> Erik> agents - just like they use throwaway IP's now.
>
> BTW, forwarding is normally set up manually, e.g., you might want your
> university to forward all mails to you home ISP account. So you know
> exactly who are your valid forwarders (here, your university only).
> Your case would then be trivially blocked in the client side.
>
> Regards,
> Isaac.

It cannot be stopped by the client.

If someone from AOL sends email to my university account and I forward
that to my roadrunner account without using SRS, Roadrunner could use
the SPF record on the original aol.com envelope header to see that my
university account is not a valid mail agent for AOL.com. and block my
forwarded files.

The only people involved in the blocking of my valid, forwarded mail
here would be AOL and Roadrunner... not me.

Remember, millions of people forward mail like this in many, varied
ways.

Every single one of them will need to modify their .forward scripts
and patch their MTA's, etc. to use SRS.

This solution is an enormous amount of work for everyone on the
Internet.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Isaac To

2004-07-28, 6:23 pm

>>>>> "Erik" == Erik Aronesty <erik@zoneedit.com> writes:

Erik> It cannot be stopped by the client.

Erik> If someone from AOL sends email to my university account and
Erik> I forward that to my roadrunner account without using SRS,
Erik> Roadrunner could use the SPF record on the original aol.com
Erik> envelope header to see that my university account is not a
Erik> valid mail agent for AOL.com. and block my forwarded files.

This is a problem completely orthogonal to your original post. Your
original post says that you're worry about the following sequence of
events, in an environment in which A@b.com, say normally receive
forwarded mails from his university, in the following way:

External mail => AA@univ.edu => A@b.com

and then a spammer says "let's register a throw-away domain", let's
say "TA.com", and pretend to be relaying mails from V@aol.com through
TA.com through the path

V@aol.com => SS@TA.com => A@b.com

and thus make it seems like V@aol.com is sending to A@b.com, with
nobody knowing that SS@TA.com is bad. This certainly does not work,
as SS@TA.com is not in the normal delivery path ofr A@b.com, so it is
trivial (more or less) for A@b.com to drop the mail without even
reading a single byte of it.

Your current concern is different: you are concerned that you, as
A@b.com, will not be able to receive mails forwarded from AA@univ.edu
because AA@univ.edu does not have SRS implemented. But if you think
clearly about it, the trouble comes only because you are running
roadrunner with spam detection turned on. If you don't, you've got no
trouble at all. And given that your university do not enable SRS you
have pretty much no option. So what it means is that *not* implement
SRS would force its users to receive spam, which shows that SRS is
part of an important weapon against spam. This is no worse than to
use no strategy against spam, and your recourse is of course to push
your university to use an MTA that implements SRS.

Erik> The only people involved in the blocking of my valid,
Erik> forwarded mail here would be AOL and Roadrunner... not me.

Current I still have no idea whether the popular choice of
implementation is to deliver the spam to the user and mark them as
spam for spam filtering, or to have the MTA directly filter out the
mail. Your concern would only matter in the second case. Most
in-house mail processing system will not delete those mails determined
as spam right away, so what it means is simply that you must ignore
the spam filter of your ISP. Again, it means that the lack of SRS
would force you to receive spam.

Erik> Remember, millions of people forward mail like this in many,
Erik> varied ways.

But not every of them are system admins. Only those system admins
need to take action, and the rest can reap from the result that mail
domains in mails being more reliable. System admins, by definition,
are people who have to continuously work towards making their systems
more usable to the user, and I believe that they will be happy to
provide the effort in making the MTA configuration.

Erik> Every single one of them will need to modify their .forward
Erik> scripts and patch their MTA's, etc. to use SRS.

Erik> This solution is an enormous amount of work for everyone on
Erik> the Internet.

This assumes that the amount of work needed for "everyone" is
"enormous". If this is the truth, then SPF simply won't take off. On
the other hand, I'm a bit more optimistic, and believe that the MTA
that most people actually use (e.g., sendmail, exim, postfix, etc)
will soon have SRS built-in, and to use it you only have to make a
configuration no more difficult than to enable forwarding in the first
place. (Indeed, I believe that it would be made difficult to
*disable* SRS in those mailers.)

Regards,
Isaac.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Erik Aronesty

2004-07-28, 6:23 pm

Isaac To <iketo2@netscape.net> wrote in message news:<2mAvh-2Yj-33@gated-at.bofh.it>...
>
> Erik> It cannot be stopped by the client.
> Erik> If someone from AOL sends email to my university account and
>
> This is a problem completely orthogonal to your original post. Your

Yes, but it was not orthogonal to the "it can be stopped by the
client" statement.

> ...
> External mail => AA@univ.edu => A@b.com
>
> and then a spammer says "let's register a throw-away domain", let's
> say "TA.com", and pretend to be relaying mails from V@aol.com through
> TA.com through the path
>
> V@aol.com => SS@TA.com => A@b.com
>
> and thus make it seems like V@aol.com is sending to A@b.com, with
> nobody knowing that SS@TA.com is bad. This certainly does not work,
> as SS@TA.com is not in the normal delivery path ofr A@b.com, so it is
> trivial (more or less) for A@b.com to drop the mail without even
> reading a single byte of it.

I see, this assumes that the client, not the ISP is dropping the mail
based on SPF, and that SPF filtering is never implemented by the ISP.
As long as ISP never use SPF to filter mail, I would agree that this
case is not a problem.

(1) In the real world, however, ISP's will use SPF to filter mail and
end users don't know their asses from their elbows when it comes to
"normal delivery paths". So SPF filtering *will* break a lot of legit
mail.

> Your current concern is different: you are concerned that you, as
> A@b.com, will not be able to receive mails forwarded from AA@univ.edu
> because AA@univ.edu does not have SRS implemented. But if you think
> clearly about it, the trouble comes only because you are running
> roadrunner with spam detection turned on. If you don't, you've got no

As if you can tell Time Warner whether or not to turn spam detection
on? The point is that SPF, as much as it prevents domain forgery,
equally gives ISP's a reason to block legit mail.

SPF makes claims to prevent spam. Preventing domain forgery is not
spam prevention. Domains are forged all the time for valid reasons.

> Erik> Remember, millions of people forward mail like this in many,
> Erik> varied ways.
>
> But not every of them are system admins. Only those system admins
> need to take action, and the rest can reap from the result that mail

Small business users with shareware mail servers are going to patch
their mail servers with SRS? Perhaps. Perhaps not.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Isaac To

2004-08-01, 5:50 pm

>>>>> "Erik" == Erik Aronesty <erik@zoneedit.com> writes:

Erik> (1) In the real world, however, ISP's will use SPF to filter
Erik> mail and end users don't know their asses from their elbows
Erik> when it comes to "normal delivery paths". So SPF filtering
Erik> *will* break a lot of legit mail.

Then your campaign should be asking ISPs not to directly filter out
mails without your knowledges based on SPF.

Erik> Small business users with shareware mail servers are going
Erik> to patch their mail servers with SRS? Perhaps. Perhaps
Erik> not.

I do think so as long as its users is using forwarding like .forward,
once the hurt is being felt by its users. The fault is that SRS is
not used, and the business has no actual power to stop others to put
out SPF records.

Regards,
Isaac.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Erik Aronesty

2004-08-02, 5:58 pm

Isaac To <iketo2@netscape.net> wrote in message news:<2ooJh-6zI-17@gated-at.bofh.it>...
>
> Erik> (1) In the real world, however, ISP's will use SPF to filter
> Erik> mail and end users don't know their asses from their elbows
> Erik> when it comes to "normal delivery paths". So SPF filtering
> Erik> *will* break a lot of legit mail.
>
> Then your campaign should be asking ISPs not to directly filter out
> mails without your knowledges based on SPF.

True! Do you know anyone over at AOL? They seem to be promoting
SPF...

> Erik> Small business users with shareware mail servers are going
> Erik> to patch their mail servers with SRS? Perhaps. Perhaps
> Erik> not.
>
> I do think so as long as its users is using forwarding like .forward,
> once the hurt is being felt by its users. The fault is that SRS is
> not used, and the business has no actual power to stop others to put
> out SPF records.

A good SPF filter will allow you to accept forwarded mail from non SRS
servers by listing the servers that you accept forwarded mail from.

SPF does not make it clear in the specification that it is to be used
by end-users/MUA's *only*, and that SPF filtering *must* be
configurable by the end user so the end user can turn on acceptance of
SRS rewritten headers from some sources (.forward) and not others
(throwaway domains).

This should be added to the specification immediately.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org