Mailing List Archive

On Wed, 14 Apr 2004, Eugene Crosser wrote:

> Gentlemen,
>
> maybe this have been discussed (many times) already; if so please excuse
> me and point me to archieves/documents. If not, I'd like to discuss it.
>
> Assume that SPF (or its equivalent) is widely deployed already. Now,
> what a spammer can do to overcome it? Purchase one or sevaral domains,
> and publish permissive SPF records for them, possibly within multiple
> subdomains. Given that domains are cheap, and blacklists will
> inevitably lag behind, this may become a significant problem.
>
> Did anyone think how to eliminate or minimize this threat? Maybe (just
> maybe) some provisions in the protocol might help? E.g., limitation on
> the depth of dubdomains? If so, it's time to think about them now,
> before the protocol is finalized.
>

I have never understood how SPF was supposed to "solve" the spam
problem with regard to domains owned by people who really want to
spam. This includes those using throw-aways.

I think that's an outside issue. SPF, as I understand it, is to
deal with the permissiveness of the SMTP protocol, where anybody
can send email that is ostensibly from *other* domains.

-mark

--
Mark Jeftovic <markjr@easydns.com>
Co-founder, easyDNS Technologies Inc.
ph. +1-(416)-535-8672 ext 225
fx. +1-(416)-535-0237

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Spammers do not have a huge rate of return, which is why they need to
send out millions of eMails. But they don't mind doing that, 'cuz it's
basically free.

However, if they have to keep buying a new domain every week, that eats
into their profit margin, and makes it much less attractive to become a
spammer.

After SPF starts to take hold, the community will need to become
increasingly aggressive at black-listing known spamming domains. I
suspect that could be brought down to inside 24 hours, and I suspect
spammers would not be so willing to purchase a new domain for every day
of the week.

Regards,
Nate



-----Original Message-----
From: owner-spf-devel@v2.listbox.com
[mailto:owner-spf-devel@v2.listbox.com] On Behalf Of Eugene Crosser
Sent: Wednesday, April 14, 2004 2:04 AM
To: spf-devel@v2.listbox.com
Subject: [spf-devel] SPF and throw-away domains


Gentlemen,

maybe this have been discussed (many times) already; if so please excuse
me and point me to archieves/documents. If not, I'd like to discuss it.

Assume that SPF (or its equivalent) is widely deployed already. Now,
what a spammer can do to overcome it? Purchase one or sevaral domains,
and publish permissive SPF records for them, possibly within multiple
subdomains. Given that domains are cheap, and blacklists will
inevitably lag behind, this may become a significant problem.

Did anyone think how to eliminate or minimize this threat? Maybe (just
maybe) some provisions in the protocol might help? E.g., limitation on
the depth of dubdomains? If so, it's time to think about them now,
before the protocol is finalized.

Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <E471DE25CFC1694E85FACE8D135EF222147A5C@paexchange.corp.mailfrontier.com> "Nate Leon" <nleon@mailfrontier.com> writes:

> After SPF starts to take hold, the community will need to become
> increasingly aggressive at black-listing known spamming domains. I
> suspect that could be brought down to inside 24 hours, and I suspect
> spammers would not be so willing to purchase a new domain for every day
> of the week.

Domains can be easily bought for less than $10 each. $10 per day is
not very much.

On the other hand, I think that RHSBLs will be able to react quicker
than within 24hrs and I think that the use of graylisting can hold off
a lot of spam until the RHSBLs have had time to react. The
combination of fast-acting RHSBLs and graylisting could mean that
spammers would have to use dozens of domains per day.


But, no matter what, they won't be using my domain.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Wed, 2004-04-14 at 20:05, Nate Leon wrote:
> Spammers do not have a huge rate of return, which is why they need to
> send out millions of eMails. But they don't mind doing that, 'cuz it's
> basically free.
>
> However, if they have to keep buying a new domain every week, that eats
> into their profit margin, and makes it much less attractive to become a
> spammer.
>
> After SPF starts to take hold, the community will need to become
> increasingly aggressive at black-listing known spamming domains. I
> suspect that could be brought down to inside 24 hours, and I suspect
> spammers would not be so willing to purchase a new domain for every day
> of the week.

Which means that blacklisting will have to be always done on the second
level domain, *not* the complete domain (spammer can publish spf records
for thousands subdomains in just seconds). This in turn will lead to
problems with "general purpose" second level domains, a la co.uk and the
like. Not strictly speaking an spf problem but a thing to keep in
mind...

> -----Original Message-----
> From: owner-spf-devel@v2.listbox.com
> [mailto:owner-spf-devel@v2.listbox.com] On Behalf Of Eugene Crosser
> Sent: Wednesday, April 14, 2004 2:04 AM
> To: spf-devel@v2.listbox.com
> Subject: [spf-devel] SPF and throw-away domains
>
>
> Gentlemen,
>
> maybe this have been discussed (many times) already; if so please excuse
> me and point me to archieves/documents. If not, I'd like to discuss it.
>
> Assume that SPF (or its equivalent) is widely deployed already. Now,
> what a spammer can do to overcome it? Purchase one or sevaral domains,
> and publish permissive SPF records for them, possibly within multiple
> subdomains. Given that domains are cheap, and blacklists will
> inevitably lag behind, this may become a significant problem.
>
> Did anyone think how to eliminate or minimize this threat? Maybe (just
> maybe) some provisions in the protocol might help? E.g., limitation on
> the depth of dubdomains? If so, it's time to think about them now,
> before the protocol is finalized.
>
> Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Eugene Crosser wrote:

>
> Which means that blacklisting will have to be always done on the second
> level domain, *not* the complete domain (spammer can publish spf records
> for thousands subdomains in just seconds). This in turn will lead to
> problems with "general purpose" second level domains, a la co.uk and the
> like. Not strictly speaking an spf problem but a thing to keep in
> mind...
>
>

Wildcard DNS work just fine at solving this issue without forcing
'second level' lookups or anything like that. Technically this is both
outside the scope of SPF (I think) and more appropriate for the
spf-discuss list if we should need to discuss it anywhere.

Cheers,

Jonathan Steinert

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In nleon@mailfrontier.com writes:

> > Spammers do not have a huge rate of return, which is why they need to
> > send out millions of eMails. But they don't mind doing that, 'cuz it's
> > basically free.
> >
> > However, if they have to keep buying a new domain every week, that eats
> > into their profit margin, and makes it much less attractive to become a
> > spammer.
> >
> > After SPF starts to take hold, the community will need to become
> > increasingly aggressive at black-listing known spamming domains. I
> > suspect that could be brought down to inside 24 hours, and I suspect
> > spammers would not be so willing to purchase a new domain for every day
> > of the week.

Just to play devil's advocate for a minute;

If SPF gets deployed widely enough for spammers to even notice, I would
expect spamware version n+1 to include a simple feature that does a
dictionary or list scan of domain names, doing DNS lookups for SPF records.
Pick the first domain name it finds that doesn't have SPF records
published, and the spam fires off from @unluckyusers-domain.com.

Spammers don't care about the return email addresses; they want to get their
ad in front of you; or for the brave ones with real web sites (usually
published in china or other "complaint immune" regions) they want to get
the victim to view their website (which seem often to be simple numeric
IPs as often as named URLs).

I GUARANTEE they can find available (non-SPF) domain names alot faster
than ANYONE can blacklist the domains... or play catch-up publishing SPF
records.

While I'm in favor of SPF - I've published records for my domain already -
to eliminate (or hopefully cut down) spams forging MY domain; it's not
realistic to expect it to ever reach a deployment level *worldwide* that
would make a LARGE impact on spam volume... Bill it as "protection of your
domain name in email headers"... nothing more.

As a frustrating aside, I get just as many (maybe more) joe-job emails
now than I did before publishing SPF records. All get directed to me as
bounces from "legit" mail servers (that obviously DON'T check SPF - but whom
I can't afford to block either!). No automated checks I can think of could
stop them, seeing as the bounce formats vary so widely among the various
MTAs... Even scanning for a unique header generated by my MTA wouldn't help
as many of the bounces only provide a subset (or none) of the original email
headers. I have well published email addresses that I can't afford to
obfuscate, and I can't afford to force cookie-style return addresses. SPF
deployment has a LONG way to go to even provide noticeable help in the arena
it's designed for.

Our MTA does alot of SPF-like lookups/reverse-validations already... Still
contemplating adding SPF to it's list. For now I'm a lurker :-)

-Chris Bartram
3k Associates, Inc.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

At 07:40 PM 4/16/2004 -0400, you wrote:
> In nleon@mailfrontier.com writes:
>
>Just to play devil's advocate for a minute;
>
>If SPF gets deployed widely enough for spammers to even notice, I would
>expect spamware version n+1 to include a simple feature that does a
>dictionary or list scan of domain names, doing DNS lookups for SPF records.
>Pick the first domain name it finds that doesn't have SPF records
>published, and the spam fires off from @unluckyusers-domain.com.
>
****************** REPLY SEPARATER *********************
You are 100% correct as far as Spam in concerned. SPF only protects your
domain name from being abused. It will not stop Spam completely, but it
will help. But for Virus mail, it is a completely different story. The
currrent crop of virus's contain their own SMTP engine and send direct to
the recipients mail server. Unlike CallerID, SPF checks the MAIL FROM:
against the IP address of the sender, and virus traffic is stopped dead in
its tracks. Virus traffic that is sent through a regular mail server is
easy to detect, and can be shut down quickly by the affected ISP. All you
have to worry about is the "clueless" email administrator, and those can be
easily blocked.

J.A. Coutts


J.A. Coutts
Systems Engineer
MantaNet/TravPro

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Fri, Apr 16, 2004 at 06:09:47PM -0600, administrator@yellowhead.com wrote:
| At 07:40 PM 4/16/2004 -0400, you wrote:
| > In nleon@mailfrontier.com writes:
| >
| >Just to play devil's advocate for a minute;
| >
| >If SPF gets deployed widely enough for spammers to even notice, I would
| >expect spamware version n+1 to include a simple feature that does a
| >dictionary or list scan of domain names, doing DNS lookups for SPF records.
| >Pick the first domain name it finds that doesn't have SPF records
| >published, and the spam fires off from @unluckyusers-domain.com.
| >
| ****************** REPLY SEPARATER *********************
| You are 100% correct as far as Spam in concerned. SPF only protects your
| domain name from being abused. It will not stop Spam completely, but it
| will help. But for Virus mail, it is a completely different story. The
| currrent crop of virus's contain their own SMTP engine and send direct to
| the recipients mail server. Unlike CallerID, SPF checks the MAIL FROM:
| against the IP address of the sender, and virus traffic is stopped dead in
| its tracks. Virus traffic that is sent through a regular mail server is
| easy to detect, and can be shut down quickly by the affected ISP. All you
| have to worry about is the "clueless" email administrator, and those can be
| easily blocked.

Actually, I think the original scenario works for viruses too.

But he's right. that's exactly the reason we're hoping SPF will work:
if viruses do that, they've just given unluckyusers-domain.com incentive
to publish SPF records. This stands in contrast to the scenario where

From: paypal.com
Sender: unluckyusers-domain.com

which will not get any bounces; this is why we hope RFC2821 antispoofing
will drive publication of records, and then we can piggyback RFC2822
antispoofing on top of existing SPF, as an interim measure toward
eventual crypto.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Thu, 2004-04-15 at 00:36, Jonathan Steinert wrote:

> > Which means that blacklisting will have to be always done on the second
> > level domain, *not* the complete domain (spammer can publish spf records
> > for thousands subdomains in just seconds). This in turn will lead to
> > problems with "general purpose" second level domains, a la co.uk and the
> > like. Not strictly speaking an spf problem but a thing to keep in
> > mind...

> Wildcard DNS work just fine at solving this issue without forcing
> 'second level' lookups or anything like that.

I don't see how it solves the issue. Rather, it makes the problem
worse. Suppose a spammer purchases abc.com, publishes

*.abc.com. IN TXT "v=spf1 +all"

and starts sending with envelope froms like xyz@001.001.abc.com,
xyz@002.001.abc.com etc. Blacklists will need to block
<anything>.abc.com (not <anything>.001.abc.com).

Now, another spammer purchases 001.co.uk, and again starts sending from
xyz@001.001.co.uk, xyz@002.001.co.uk. Now blacklists should block
<anything>.001.co.uk, *NOT* <anything>.co.uk.

The question is: now does the blacklist maintainter know at which level
to block?

> Technically this is both
> outside the scope of SPF (I think) and more appropriate for the
> spf-discuss list if we should need to discuss it anywhere.

Maybe (just maybe!) SPF protocol could define a way for the top level
domains to specify which of their subdomains are in "common use" and
delegate their third level subdomains to independant parties, and which
take full responsibility for all their subdomains.

Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> and starts sending with envelope froms like xyz@001.001.abc.com,
> xyz@002.001.abc.com etc. Blacklists will need to block
> <anything>.abc.com (not <anything>.001.abc.com).

I agree.

> The question is: now does the blacklist maintainer know at which level
> to block?

Hardcoded... It would be 2nd level on .com, .net, .dk etc., and 3rd
level on .co.uk etc. But the code for this can be in the blacklisting
service, so that you don't have to replicate it to all SPF filters for
each change.

> Maybe (just maybe!) SPF protocol could define a way for the top level
> domains to specify which of their subdomains are in "common use" and
> delegate their third level subdomains to independant parties, and
which
> take full responsibility for all their subdomains.

I believe, that this should be solved at the blacklist provider, not via
SPF specs. If you want different SPF specs for a subdomain, just put it
into your DNS. It is then up to the domain owner to tell all
adminitrators of subdomain e-mails, that they may not send spam. Good
blacklists can communicate with large ISPs to make it possible to block
at a higher level (something like what Spamcop does).

Lars.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> I don't see how it solves the issue. Rather, it makes the problem
> worse. Suppose a spammer purchases abc.com, publishes
>
> *.abc.com. IN TXT "v=spf1 +all"

Mayby spf client set configuration limit how many servers range allow as
PASS, and change this to SOFTFAIL.

example:
pass_range_limit=24
get: v=spf1 a/24 mx/16 -all
parse: v=spf1 a/24 ~mx/16 -all

--
Sergiusz Ró¿añski rozanski.at.sergiusz.dot.com sq3bkn
RTG project http://gg.overwap.net
RMXF Postfix project http://rmxf.comm.pl

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Mon, 2004-04-19 at 13:53, Lars Dybdahl wrote:

> > The question is: now does the blacklist maintainer know at which level
> > to block?
>
> Hardcoded... It would be 2nd level on .com, .net, .dk etc., and 3rd
> level on .co.uk etc. But the code for this can be in the blacklisting
> service, so that you don't have to replicate it to all SPF filters for
> each change.

In the .ru tld there are both private domains (e.g. rol.ru) and public
ones (e.g. co.ru). Did you know that? I know because I live here.
Now, what about .ke tld?

> > Maybe (just maybe!) SPF protocol could define a way for the top level
> > domains to specify which of their subdomains are in "common use" and
> > delegate their third level subdomains to independant parties, and
> which
> > take full responsibility for all their subdomains.
>
> I believe, that this should be solved at the blacklist provider, not via
> SPF specs. If you want different SPF specs for a subdomain, just put it
> into your DNS. It is then up to the domain owner to tell all
> adminitrators of subdomain e-mails, that they may not send spam.

It does not solve the problem of "malicious subdomains". It sould be up
to the "upstairs" domain to tell us if its subdomain is entitled to
delegate responsibility further downwards or not.

SPF attempts to shift as much responsibility as it can from blacklist
providers to the domain owners. Now, it might be logical to let the
domain owners tell the world about how they are going to delegate
responsibilites, i.e. how deep down.

Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

>On Mon, 2004-04-19 at 13:53, Lars Dybdahl wrote:
>> Hardcoded... It would be 2nd level on .com, .net, .dk etc., and 3rd
>> level on .co.uk etc. But the code for this can be in the blacklisting
>In the .ru tld there are both private domains (e.g. rol.ru) and public
>ones (e.g. co.ru). Did you know that? I know because I live here.
>Now, what about .ke tld?

I just made a domain check system for a large webhotel, and I had to
hardcode whois lookups, DNS checks etc. independently for each TLD. Did
you know that whois for .dk domains don't work with ascii encoded
(punycode) domain names? You have to iso-8859-1 encode them... And the
output is also iso-8859-1 encoded. The important thing here is to keep
the code centralized (at the blacklist provider), so that errors and

It's a good idea to have this centralized on the blacklist. If a certain
tld hasn't been implemented, yet, it should just answer "I don't know"
to requests about this domain.

>> I believe, that this should be solved at the blacklist provider, not
via
>> SPF specs. If you want different SPF specs for a subdomain, just put
it
>> into your DNS. It is then up to the domain owner to tell all
>> adminitrators of subdomain e-mails, that they may not send spam.
>It does not solve the problem of "malicious subdomains". It sould be
up
>to the "upstairs" domain to tell us if its subdomain is entitled to
>delegate responsibility further downwards or not.

> SPF attempts to shift as much responsibility as it can from blacklist
> providers to the domain owners. Now, it might be logical to let the
> domain owners tell the world about how they are going to delegate
> responsibilites, i.e. how deep down.

That won't work. You can't ask a liar whether he is a liar... And the
problem here is, that the domain owner is a spammer and wants to trick
your filter into letting his/her spam e-mails through.

A blacklist is not a re-publication of what the spammer's tell you. It's
a documentation of a domain's behaviour, and it's up to the e-mail
admins to use that information or not. Also, a blacklist is useless, if
the domain owner can trick the blacklist into not blacklisting his 2nd
level domain, if he uses it for throw-away subdomains.

Med venlig hilsen - Best regards
Lars B. Dybdahl, M.Sc.

Technical Support

Phone: +45 45880888

This email and any files transmitted with it may contain confidential
information intended for the addressee(s) only. The information is not
to be surrendered or copied to unauthorised persons. If you have
received this communication in error, please notify us immediately by
telephone: +45 45880888 or e-mail: info@cohaesio.com. Thank you.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Mon, 2004-04-19 at 15:51, Lars Dybdahl wrote:

> > SPF attempts to shift as much responsibility as it can from blacklist
> > providers to the domain owners. Now, it might be logical to let the
> > domain owners tell the world about how they are going to delegate
> > responsibilites, i.e. how deep down.
>
> That won't work. You can't ask a liar whether he is a liar... And the
> problem here is, that the domain owner is a spammer and wants to trick
> your filter into letting his/her spam e-mails through.

This is *exactly* the problem that I am trying to overcome. You cannot
trust the domain owner when he says "trust my subdomain SPF records".
Therefore, there needs to be a way for the upper level domain (TLD) to
tell: "when my subdomain co.ru asks you to trust its subdomains'
records, beleive him. All others, distrust" - something like that.

> A blacklist is not a re-publication of what the spammer's tell you. It's
> a documentation of a domain's behaviour...

... if the blacklist admin has a way to learn how delegation of
responsibility is organized within that particular TLD...

Eugene

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

> Therefore, there needs to be a way for the upper level domain (TLD) to
> tell: "when my subdomain co.ru asks you to trust its subdomains'
> records, beleive him. All others, distrust" - something like that.

So it's a kind of DNS based blacklist system... I don't think that DNS
should be used for that purpose. There are many ways you can define
"trust", and there are potentially hundred thousands of subdomains for a
TLD that could be handled this way - do you honestly believe, that you
can make all TLDs worldwide spend enough time and money to implement
this? If you do, you should start asking them. My guess is, that they
might not even respond to your request. And you will need to make them
all implement it well, if you want a better system than hardcoding it
into the blacklist system.

Lars.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Eugene Crosser wrote:
> On Thu, 2004-04-15 at 00:36, Jonathan Steinert wrote:
>>Wildcard DNS work just fine at solving this issue without forcing
>>'second level' lookups or anything like that.
>
>
> I don't see how it solves the issue. Rather, it makes the problem
> worse. Suppose a spammer purchases abc.com, publishes
>
> *.abc.com. IN TXT "v=spf1 +all"
>
> and starts sending with envelope froms like xyz@001.001.abc.com,
> xyz@002.001.abc.com etc. Blacklists will need to block
> <anything>.abc.com (not <anything>.001.abc.com).

Unless I'm crazy, wildcard domain names in the blacklist work just fine.

@ORIGIN myblacklist.mydomain
*.abc.com A 127.0.0.1

That /is/ the standard operational design in an RHSBL, right?

>
> Now, another spammer purchases 001.co.uk, and again starts sending from
> xyz@001.001.co.uk, xyz@002.001.co.uk. Now blacklists should block
> <anything>.001.co.uk, *NOT* <anything>.co.uk.

@ORIGIN myblacklist.mydomain
*.001.co.uk A 127.0.0.1

>
> The question is: now does the blacklist maintainter know at which level
> to block?

Existing RHSBLs face this issue already, does anyone know how they
solved it from an automation standpoint? Parsing whois records is not
very reliable; perhaps they learn this information via NS and SOA record
hints?

> Maybe (just maybe!) SPF protocol could define a way for the top level
> domains to specify which of their subdomains are in "common use" and
> delegate their third level subdomains to independant parties, and which
> take full responsibility for all their subdomains.

The dnsbls can use the concept above to blacklist any portion of a full
domain name easily. Also, defining the delegation layout of the internet
DNS heirarchy is most definately outside the scope of SPF.

--Jonathan Steinert

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com