You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Michael Monnerie <mi...@it-management.at> on 2006/06/23 14:31:04 UTC
Re: [dns-operations] negative caching of throwaway spam domains
On Freitag, 23. Juni 2006 14:10 Jeff Chan wrote:
> http://www.bobparsons.com/DomainKiting.html
Very interesting page, I wasn't aware of Domain Kiting yet.
A check for new domains would be good implemented in the MTA directly,
so postfix could temporary reject delivery until the domain is at least
6 days old. OK, it would offend real people - but waiting 5 days for a
new company shouldn't be too problematic, the annoiance will stop
automatically.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660/4156531 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi3.asc | gpg --import"
// Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE
// Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Michael Monnerie <mi...@it-management.at>.
On Freitag, 23. Juni 2006 17:43 Jeff Chan wrote:
> Please see the topic of the original message. Such a BL has
> already been created by Rick Wesson of ar.com.
I've read it, but it didn't say how reliable that BL is. Does it 100%
cover all new domains world wide, or just for some? Is it directly from
registrar data?
> Yes, it's possible to use SA to reject at the MTA level, but it's
> not the typical use due to the significant overhead of running
> SA. Typically the MTA is used to first reject as many of the
> messages as possible due to RBL inclusion and other relatively
> quick and easy things to check. SA then processes the ones that
> survive.
I know, I do it that way currently. I mean that soon we will find us
having a third level of check, after the first HEL/MAILFROM/RCPTTO
rejects and before the SA checks. Because for this BL with "max. 5 days
old domains" to be used in a wise way you need to scan for URIs within
the mail. This is the only way to stop spammers from using <5 days old
domains. If they can't promote it cheaply, they won't use it.
This is some sort of greylisting, with the exception of using a central
BL. It could be called greydomaining or something like that. So the
name already gives an idea how it works.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660/4156531 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi3.asc | gpg --import"
// Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE
// Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Jeff Chan <je...@surbl.org>.
On Friday, June 23, 2006, 6:36:38 AM, Michael Monnerie wrote:
> On Freitag, 23. Juni 2006 14:49 Jeff Chan wrote:
>> 4. A DNSBL is a reasonably good technology for distributing
>> these data.
> Yes, some DNSBL. It should be one that contains newly registered
> domains, within the 5 day test period. This could only be provided by a
> registrar - could ANY registrar see that info, or only the one who
> registered a domain, or who is responsible for that TLD?
Please see the topic of the original message. Such a BL has
already been created by Rick Wesson of ar.com.
>> 3. It requires a program like SpamAssassin to deobfuscate and
>> exatract URIs to be checked.
> I believe soon the time will come that e-mail checks will change:
> 1) When new mail arrives, HELO, MAIL FROM, RCPT TO is passed and checked
> (is already done)
> 2) If mail passes, accept DATA
> 3) after DATA, but before the last OK, check URIBLs, and either make
> 200, or 4xx, or 5xx, depeding on the check
> 4) accept mail
> 5) check with SA more thoroughly
> For point 3), it's important that this is a very lightweight SA, only
> getting URIs withing the mail, and checking against some RBLs. Is it
> possible with SA in it's current form to say "do not apply ANY checks,
> just get me the list of URIs"? Then with the checks you posted, and a
> good return code, the MTA could 4xx or 5xx the connection for new
> domains.
Yes, it's possible to use SA to reject at the MTA level, but it's
not the typical use due to the significant overhead of running
SA. Typically the MTA is used to first reject as many of the
messages as possible due to RBL inclusion and other relatively
quick and easy things to check. SA then processes the ones that
survive.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Michael Monnerie <mi...@it-management.at>.
On Freitag, 23. Juni 2006 14:49 Jeff Chan wrote:
> 1. Getting domain ages from whois is difficult and very
> non-uniform between registrars.
> 2. We probably don't want millions of MTAs doing billions of
> whois queries per day or per hour.
I didn't think of whois, anyway.
> 4. A DNSBL is a reasonably good technology for distributing
> these data.
Yes, some DNSBL. It should be one that contains newly registered
domains, within the 5 day test period. This could only be provided by a
registrar - could ANY registrar see that info, or only the one who
registered a domain, or who is responsible for that TLD?
> 3. It requires a program like SpamAssassin to deobfuscate and
> exatract URIs to be checked.
I believe soon the time will come that e-mail checks will change:
1) When new mail arrives, HELO, MAIL FROM, RCPT TO is passed and checked
(is already done)
2) If mail passes, accept DATA
3) after DATA, but before the last OK, check URIBLs, and either make
200, or 4xx, or 5xx, depeding on the check
4) accept mail
5) check with SA more thoroughly
For point 3), it's important that this is a very lightweight SA, only
getting URIs withing the mail, and checking against some RBLs. Is it
possible with SA in it's current form to say "do not apply ANY checks,
just get me the list of URIs"? Then with the checks you posted, and a
good return code, the MTA could 4xx or 5xx the connection for new
domains.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660/4156531 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi3.asc | gpg --import"
// Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE
// Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Noel Jones <nj...@megan.vbhcs.org>.
At 02:15 PM 6/23/2006, Michael Monnerie wrote:
> > You can use the "rbl_reply_maps" feature to tell
> postfix to 454 defer
> > this mail rather than 554 reject it. See docs or
> postfix-users list
> > for details.
>
>OK, I X-post now to postfix-users, because this part
>belongs there.
>
>When I use rbl_reply_maps, I would have to specify like this?
(postfix-users, we are discussing a new rhsbl that lists
domains <= 5 days old.)
I don't expect this to catch much. As you and others have
said, fresh domains seem more likely to be used as links
within the spam payload and postfix can't check for them
there. But this will be an interesting experiment anyway.
rbl_reply_maps should contain the entire rbl reply
string. RBL's not listed in this map will get the default
response.
# main.cf
rbl_reply_maps hash:/path/to/rbl_reply_maps
# rbl_reply_maps
dob.sibl.support-intelligence.net 454 4.7.1 Service
unavailable; $rbl_class [$rbl_what] blocked using
$rbl_domain${rbl_reason?; $rbl_reason}
--
Noel Jones
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Michael Monnerie <mi...@it-management.at>.
On Freitag, 23. Juni 2006 20:55 Noel Jones wrote:
> add to your other rbl restrictions in postfix:
> reject_rhsbl_sender dob.sibl.support-intelligence.net
Yes, but it can of course only check the sender (MAIL FROM) of the
e-mail. This can be forged to be anything, and then within the mail is
the spammy text with a link to some site which is <5 days old. And this
cannot be caught with this.
I'll give it a try and implement it, to see if there are any hits with
MAIL FROM and <5days old domains.
> You can use the "rbl_reply_maps" feature to tell postfix to 454 defer
> this mail rather than 554 reject it. See docs or postfix-users list
> for details.
OK, I X-post now to postfix-users, because this part belongs there.
When I use rbl_reply_maps, I would have to specify like this?
black.list.name 5xx
other.black.list 4xx
or with the return text, like
black.list.name $rbl_code Service unavailable blabla
And would I have to specify all RBLs, or only the ones where I don't
want the default response, but a custom one?
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660/4156531 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi3.asc | gpg --import"
// Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE
// Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Michael Monnerie <mi...@it-management.at>.
On Samstag, 24. Juni 2006 02:31 jdow wrote:
> Create business plan.
> Acquire domains.
> Acquire machines, install software, setup website, yatta and yatta.
> # Bingo - five days are long gone before you:
> Turn on sendmail.
Yes, that could be the good thing, but there might be people quicker
than you and me :-)
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660/4156531 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi3.asc | gpg --import"
// Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE
// Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE
Re: [dns-operations] negative caching of throwaway spam domains
Posted by jdow <jd...@earthlink.net>.
From: "Michael Monnerie" <mi...@it-management.at>
> That way it would be a bit smoother. After all, there is a small
> percentage of new domains being legit, I heard. *g*
Create business plan.
Acquire domains.
Acquire machines, install software, setup website, yatta and yatta.
# Bingo - five days are long gone before you:
Turn on sendmail.
{^_-}
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Michael Monnerie <mi...@it-management.at>.
On Samstag, 24. Juni 2006 02:09 jdow wrote:
> However, doesn't a greylist perform much the same intent - a domain
> that has not been heard from before is held off for a second chance
> in half an hour to an hour.
Yes, but greylisting goes for the from/to/IP triplet.
> "Obviously" new domains would trigger
> the greylist. If the greylisting is done on a per domain basis it
> could be combined with the whois lookup. If the whois lookup did
> not provide age data the message is blocked per greylisting.
But this special greylisting - I would call it greydomaining - would
have to delay 5 days - too long for most sender servers.
> If it
> provides age data indicating an old domain it's blocked per
> greylisting. If it indicates a new domain it's blocked with a
> permanent error. (If the whois source is not trustworthy it's also
> blocked with a permanent error.)
It could be good to make it
* if the domain is 0-3 days old, REJECT with a permanent error.
* on 4-5 days, REJECT with a temporary error (greydomaining)
* after 5 days, use normal greylisting
That way it would be a bit smoother. After all, there is a small
percentage of new domains being legit, I heard. *g*
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660/4156531 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi3.asc | gpg --import"
// Fingerprint: 44A3 C1EC B71E C71A B4C2 9AA6 C818 847C 55CB A4EE
// Keyserver: www.keyserver.net Key-ID: 0x55CBA4EE
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Maurice Lucas <ms...@taos-it.nl>.
On Sat, 2006-06-24 at 05:08 -0700, Jeff Chan wrote:
> On Friday, June 23, 2006, 5:09:55 PM, jdow jdow wrote:
> > Jeff, it's probably quite good when the lookup is implemented on
> > spam traps and a small collection of servers. The domain registrars
> > who are honest might like it. It'd reduce the incentive and value
> > of domain kiting.
>
> Presumably the list doesn't include kited domains, or it would be
> 35 million records long. :-(
>
> > However, doesn't a greylist perform much the same intent - a domain
> > that has not been heard from before is held off for a second chance
> > in half an hour to an hour. "Obviously" new domains would trigger
> > the greylist. If the greylisting is done on a per domain basis it
> > could be combined with the whois lookup. If the whois lookup did
> > not provide age data the message is blocked per greylisting. If it
> > provides age data indicating an old domain it's blocked per greylisting.
> > If it indicates a new domain it's blocked with a permanent error.
> > (If the whois source is not trustworthy it's also blocked with a
> > permanent error.)
>
> Michael gives some good possibilities and a discussion of the
> difference with greylisting. Note that whois can't really be
> done on an automated, high-frequency basis.
>
DomainKitting must cost good registrars like Go daddy a lot of money due
to resource use. So it will make them money if they aren't being used
for this kind of abuse.
If we could get e.g. Go Daddy support the idea of greydomaining and they
will input the data of new domain names in the database and removing
5-day-refund addresses and payed-addresses then Go Daddy won't be a
registrar which will be used by spammers.
It will *cost* Go Daddy an amount of marketing items like:
- we have x million new domains every day/week/month
- we have a grand total of x million domain names
- ...
But it will *give* them a great support from serious users and admins.
They won't register that many domain names but if we, the serious
admins, do register we will use and pay for that domain.
and I like to give my money to a registrar that is doing whatever it
cost to keep the internet usable.
If Go Daddy does give the data of all the registrations there isn't any
need for whois queries.
--
With kind regards,
Maurice Lucas
TAOS-IT
Re: [dns-operations] negative caching of throwaway spam domains
Posted by "John D. Hardin" <jh...@impsec.org>.
On Sat, 24 Jun 2006, Jeff Chan wrote:
> Michael gives some good possibilities and a discussion of the
> difference with greylisting. Note that whois can't really be done
> on an automated, high-frequency basis.
Back when I first suggested this a couple of years ago, it was
possible to download a list of newly-registered domain names directly
from the InterNIC FTP server.
I haven't visited there in quite a while, I don't know if they still
provide that information in as neat a package.
--
John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The problem is when people look at Yahoo, slashdot, or groklaw and
jump from obvious and correct observations like "Oh my God, this
place is teeming with utter morons" to incorrect conclusions like
"there's nothing of value here". -- Al Petrofsky, in Y! SCOX
-----------------------------------------------------------------------
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Jeff Chan <je...@surbl.org>.
On Friday, June 23, 2006, 5:09:55 PM, jdow jdow wrote:
> Jeff, it's probably quite good when the lookup is implemented on
> spam traps and a small collection of servers. The domain registrars
> who are honest might like it. It'd reduce the incentive and value
> of domain kiting.
Presumably the list doesn't include kited domains, or it would be
35 million records long. :-(
> However, doesn't a greylist perform much the same intent - a domain
> that has not been heard from before is held off for a second chance
> in half an hour to an hour. "Obviously" new domains would trigger
> the greylist. If the greylisting is done on a per domain basis it
> could be combined with the whois lookup. If the whois lookup did
> not provide age data the message is blocked per greylisting. If it
> provides age data indicating an old domain it's blocked per greylisting.
> If it indicates a new domain it's blocked with a permanent error.
> (If the whois source is not trustworthy it's also blocked with a
> permanent error.)
Michael gives some good possibilities and a discussion of the
difference with greylisting. Note that whois can't really be
done on an automated, high-frequency basis.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [dns-operations] negative caching of throwaway spam domains
Posted by jdow <jd...@earthlink.net>.
From: "Jeff Chan" <je...@surbl.org>
> On Friday, June 23, 2006, 5:31:04 AM, Michael Monnerie wrote:
>> On Freitag, 23. Juni 2006 14:10 Jeff Chan wrote:
>>> http://www.bobparsons.com/DomainKiting.html
>
>> Very interesting page, I wasn't aware of Domain Kiting yet.
>
>> A check for new domains would be good implemented in the MTA directly,
>> so postfix could temporary reject delivery until the domain is at least
>> 6 days old. OK, it would offend real people - but waiting 5 days for a
>> new company shouldn't be too problematic, the annoiance will stop
>> automatically.
>
> That's an interesting idea, but probably impractical because:
>
> 1. Getting domain ages from whois is difficult and very
> non-uniform between registrars.
>
> 2. We probably don't want millions of MTAs doing billions of
> whois queries per day or per hour.
>
> 3. It requires a program like SpamAssassin to deobfuscate and
> exatract URIs to be checked.
>
> 4. A DNSBL is a reasonably good technology for distributing
> these data.
Jeff, it's probably quite good when the lookup is implemented on
spam traps and a small collection of servers. The domain registrars
who are honest might like it. It'd reduce the incentive and value
of domain kiting.
However, doesn't a greylist perform much the same intent - a domain
that has not been heard from before is held off for a second chance
in half an hour to an hour. "Obviously" new domains would trigger
the greylist. If the greylisting is done on a per domain basis it
could be combined with the whois lookup. If the whois lookup did
not provide age data the message is blocked per greylisting. If it
provides age data indicating an old domain it's blocked per greylisting.
If it indicates a new domain it's blocked with a permanent error.
(If the whois source is not trustworthy it's also blocked with a
permanent error.)
{^_^}
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Jeff Chan <je...@surbl.org>.
On Friday, June 23, 2006, 5:31:04 AM, Michael Monnerie wrote:
> On Freitag, 23. Juni 2006 14:10 Jeff Chan wrote:
>> http://www.bobparsons.com/DomainKiting.html
> Very interesting page, I wasn't aware of Domain Kiting yet.
> A check for new domains would be good implemented in the MTA directly,
> so postfix could temporary reject delivery until the domain is at least
> 6 days old. OK, it would offend real people - but waiting 5 days for a
> new company shouldn't be too problematic, the annoiance will stop
> automatically.
That's an interesting idea, but probably impractical because:
1. Getting domain ages from whois is difficult and very
non-uniform between registrars.
2. We probably don't want millions of MTAs doing billions of
whois queries per day or per hour.
3. It requires a program like SpamAssassin to deobfuscate and
exatract URIs to be checked.
4. A DNSBL is a reasonably good technology for distributing
these data.
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: [dns-operations] negative caching of throwaway spam domains
Posted by Noel Jones <no...@gmail.com>.
On 6/23/06, Michael Monnerie <mi...@it-management.at> wrote:
> A check for new domains would be good implemented in the MTA directly,
> so postfix could temporary reject delivery until the domain is at least
> 6 days old. OK, it would offend real people - but waiting 5 days for a
> new company shouldn't be too problematic, the annoiance will stop
> automatically.
>
You can do this already with the "day old bread" list talked about here.
add to your other rbl restrictions in postfix:
reject_rhsbl_sender dob.sibl.support-intelligence.net
If you want to test this without actually rejecting any mail
(reject_warning message will be logged, but mail will still be
accepted) use:
warn_if_reject reject_rhsbl_sender dob.sibl.support-intelligence.net
You can use the "rbl_reply_maps" feature to tell postfix to 454 defer
this mail rather than 554 reject it. See docs or postfix-users list
for details.
--
Noel Jones