I already have the feature
accept_unresolvable_domains
but, sendmail still appears to reverse resolve the hostname from IP
address (PTR). I'm perfectly happy with plain IP-addresses in logs and
headers.
--
Markku Savela
On Sun, 30 Sep 2007, Markku Savela wrote:
> I already have the feature
>
> accept_unresolvable_domains
Why the hell would you do that? Do you know how severe the consequences
are by doing this? spammer scum will love you :)
> but, sendmail still appears to reverse resolve the hostname from IP
> address (PTR). I'm perfectly happy with plain IP-addresses in logs and
> headers.
This is also crazy not to do.
However, Sendmail by default does not block by no/invalid PTR, you have to
specifically enable this feature, it will try do PTR lookups anyway, but
who cares if you ae not blocking and it wont block unless told to do so
by using FEATURE(`require_rdns')
--
Cheers
Res
Res wrote:
> On Sun, 30 Sep 2007, Markku Savela wrote:
>
>> I already have the feature
>>
>> accept_unresolvable_domains
>
> Why the hell would you do that? Do you know how severe the consequences
> are by doing this? spammer scum will love you :)
>
He could be using this for a intranet :) At least I hope he is with a setting
like that. If not dude needs to go back to school again.
>> but, sendmail still appears to reverse resolve the hostname from IP
>> address (PTR). I'm perfectly happy with plain IP-addresses in logs and
>> headers.
>
> This is also crazy not to do.
> However, Sendmail by default does not block by no/invalid PTR, you have to
> specifically enable this feature, it will try do PTR lookups anyway, but
> who cares if you ae not blocking and it wont block unless told to do so
> by using FEATURE(`require_rdns')
>
>
On Sun, 30 Sep 2007, Scott Grayban wrote:
> Res wrote:
>> On Sun, 30 Sep 2007, Markku Savela wrote:
>>
>>> I already have the feature
>>>
>>> accept_unresolvable_domains
>>
>> Why the hell would you do that? Do you know how severe the consequences
>> are by doing this? spammer scum will love you :)
>>
>
> He could be using this for a intranet :) At least I hope he is with a setting
One sure hopes so!
> like that. If not dude needs to go back to school again.
Yep :)
--
Cheers
Res
Slackware -V- sloooUbuntoooou
http://lxer.com/module/newswire/view/93393/
Res
>> I already have the feature
>>
>> accept_unresolvable_domains
>
> Why the hell would you do that? Do you know how severe the consequences
> are by doing this? spammer scum will love you :)
Because it serves no useful purpose. Most dynamic setups have default
reverse setups. I use Spamhaus blocking, which yesterday blocked over
8000 attempts. Additional 2000 was blocked becuase of "user
unknown". By not doing the reverse queries, I would have saved 10000
DNS queries, some of which take long time due to broken DNS servers
out there.
And, note, this is private system, there is only mail for myself.
> This is also crazy not to do.
Again, I have no use for reverse queried domain names. Getting them
just wastes CPU cycles.
On Mon, 1 Oct 2007, Markku Savela wrote:
> Res
>
>>> I already have the feature
>>>
>>> accept_unresolvable_domains
>>
>> Why the hell would you do that? Do you know how severe the consequences
>> are by doing this? spammer scum will love you :)
>
> Because it serves no useful purpose. Most dynamic setups have default
serves NO usefull purpose? *shakes head* go back to using winshit
> reverse setups. I use Spamhaus blocking, which yesterday blocked over
> 8000 attempts. Additional 2000 was blocked becuase of "user
> unknown". By not doing the reverse queries, I would have saved 10000
> DNS queries, some of which take long time due to broken DNS servers
> out there.
hint: its gunna do them anyway :)
>
> And, note, this is private system, there is only mail for myself.
>
>> This is also crazy not to do.
>
> Again, I have no use for reverse queried domain names. Getting them
> just wastes CPU cycles.
enjoy your spam that you will soon get once the spambots pick up on your
post :)
--
Cheers
Res
Slackware -V- sloooUbuntoooou
http://lxer.com/module/newswire/view/93393/
In article <87y7enb8wn.fsf@burp.tkv.asdf.org> Markku Savela
>Res
>
>>> I already have the feature
>>>
>>> accept_unresolvable_domains
>>
>> Why the hell would you do that? Do you know how severe the consequences
>> are by doing this? spammer scum will love you :)
>
>Because it serves no useful purpose. Most dynamic setups have default
>reverse setups.
You're confused about what accept_unresolvable_domains does - read
cf/README to find out. That verification used to catch a lot of spam
with forged sender addresses, I'm not sure how useful it is these days
though (i.e. spammers tend to use real domain names and often even real
usernames in the domain - not their own though...).
--Per Hedeland
per@hedeland.org
Res wrote:
> On Mon, 1 Oct 2007, Markku Savela wrote:
>
>> Res
>>
>>>> I already have the feature
>>>>
>>>> accept_unresolvable_domains
>>> Why the hell would you do that? Do you know how severe the consequences
>>> are by doing this? spammer scum will love you :)
>> Because it serves no useful purpose. Most dynamic setups have default
>
> serves NO usefull purpose? *shakes head* go back to using winshit
>
>
>> reverse setups. I use Spamhaus blocking, which yesterday blocked over
>> 8000 attempts. Additional 2000 was blocked becuase of "user
>> unknown". By not doing the reverse queries, I would have saved 10000
>> DNS queries, some of which take long time due to broken DNS servers
>> out there.
>
> hint: its gunna do them anyway :)
>
>> And, note, this is private system, there is only mail for myself.
>>
>>> This is also crazy not to do.
>> Again, I have no use for reverse queried domain names. Getting them
>> just wastes CPU cycles.
>
> enjoy your spam that you will soon get once the spambots pick up on your
> post :)
>
>
I don't think he really wants help. It's pretty obvious that he can't read.
On Mon, 1 Oct 2007, Scott Grayban wrote:
> Res wrote:
>> On Mon, 1 Oct 2007, Markku Savela wrote:
>>
>>> Res
>>>
>>>>> I already have the feature
>>>>>
>>>>> accept_unresolvable_domains
>>>> Why the hell would you do that? Do you know how severe the consequences
>>>> are by doing this? spammer scum will love you :)
>>> Because it serves no useful purpose. Most dynamic setups have default
>>
>> serves NO usefull purpose? *shakes head* go back to using winshit
>>
>>
>>> reverse setups. I use Spamhaus blocking, which yesterday blocked over
>>> 8000 attempts. Additional 2000 was blocked becuase of "user
>>> unknown". By not doing the reverse queries, I would have saved 10000
>>> DNS queries, some of which take long time due to broken DNS servers
>>> out there.
>>
>> hint: its gunna do them anyway :)
>>
>>> And, note, this is private system, there is only mail for myself.
>>>
>>>> This is also crazy not to do.
>>> Again, I have no use for reverse queried domain names. Getting them
>>> just wastes CPU cycles.
>>
>> enjoy your spam that you will soon get once the spambots pick up on your
>> post :)
>>
>>
>
> I don't think he really wants help. It's pretty obvious that he can't read.
Yeah Scotty, some people just should have stayed with winblow$ hey :)
>
--
Cheers
Res
Slackware -V- sloooUbuntoooou
http://lxer.com/module/newswire/view/93393/
In article <87y7enb8wn.fsf@burp.tkv.asdf.org>,
Markku Savela
> Res
>
> >> I already have the feature
> >>
> >> accept_unresolvable_domains
> >
> > Why the hell would you do that? Do you know how severe the consequences
> > are by doing this? spammer scum will love you :)
>
> Because it serves no useful purpose. Most dynamic setups have default
> reverse setups. I use Spamhaus blocking, which yesterday blocked over
> 8000 attempts. Additional 2000 was blocked becuase of "user
> unknown". By not doing the reverse queries, I would have saved 10000
> DNS queries, some of which take long time due to broken DNS servers
> out there.
>
> And, note, this is private system, there is only mail for myself.
>
The simplest approach then would be to point your resolution at a local
DNS server that sees itself as an authority for an empty in-addr.arpa
zone. Sendmail will continue to do the reverse lookups, but they will
complete fast with no results.
> > This is also crazy not to do.
>
> Again, I have no use for reverse queried domain names. Getting them
> just wastes CPU cycles.
That is not likely to be significant on most systems capable of running
Sendmail. For the most part, a DNS query does not so much use CPU time
as it does slow down the handling of SMTP connections and transactions
because you are waiting for a DNS response. That might take many
seconds, but the waiting does not use significant CPU cycles for those
seconds.
--
Now where did I hide that website...
per@hedeland.org (Per Hedeland) writes:
> You're confused about what accept_unresolvable_domains does - read
> cf/README to find out. That verification used to catch a lot of spam
> with forged sender addresses, I'm not sure how useful it is these days
> though (i.e. spammers tend to use real domain names and often even real
> usernames in the domain - not their own though...).
Ahh, thanks, I did suspect that that was not the right control, and
from other messages I pretty much deduce that sendmail cannot be
configured not to do the reverse (PTR) query.
Queries don't eat up much CPU, that was my typing on the hip. What
does bother me is the long delays on some queries and lots of log
messages on server failures and lame resolvers, which I wanted to get
rid of.
And those, who claim that reverse PTR query is somehow useful for the
sendmail, please tell me how?
If you are actually using the result of PTR query for some important
security decision, then your security sucks in major way. Or, does
sendmail actually do the "paranoid" procedure:
1) reverse PTR query
2) forward query with result of PTR
3) verify *somehow* that addresses match
If you do this, step (3) will often fail, when hosts have multiple IP
addresses.
If you don't do "paranoid" test, I can easily fool yoy by making
reverse query of my IP-address to return *ANY* domain name I wish,
like "microsoft.com" or whatever.
In article <87sl4ualrd.fsf@burp.tkv.asdf.org>,
Markku Savela
[...]
> And those, who claim that reverse PTR query is somehow useful for the
> sendmail, please tell me how?
Patterns in validated rDNS for high-certainty abuse are useful as scored
heuristics and in some cases as dead-certain spamsign.
Examples:
1. The rDNS names on many consumer access accounts are derived from the
IP address, and some of those derivations are programmatically
detectable. Such rDNS is not a perfect sign of spam, but it is a strong
correlator and is a perfect sign of a system whose owner is unconcerned
about the ability to act as an SMTP client reliably.
2. Some spammers use 'real' domains in rDNS and HELO and in sender
addresses in an attempt to look less suspicious, while cycling through
fresh domains rapidly using a particular set of DNS servers for the
domains and the "domain tasting" misfeature of some TLD's. This results
in an ability to detect particular spammers by determining the DNS
authorities for their technically valid rDNS names.
> If you are actually using the result of PTR query for some important
> security decision, then your security sucks in major way. Or, does
> sendmail actually do the "paranoid" procedure:
>
> 1) reverse PTR query
> 2) forward query with result of PTR
> 3) verify *somehow* that addresses match
>
> If you do this, step (3) will often fail, when hosts have multiple IP
> addresses.
>
> If you don't do "paranoid" test, I can easily fool yoy by making
> reverse query of my IP-address to return *ANY* domain name I wish,
> like "microsoft.com" or whatever.
Sendmail does that return-trip check and marks validation failures as
"may be forged" in both log lines and Received headers. After all, it is
mature software written by non-naive people.
--
Now where did I hide that website...
On Mon, 1 Oct 2007, Markku Savela wrote:
>
> And those, who claim that reverse PTR query is somehow useful for the
> sendmail, please tell me how?
how does a reduction of about 80% in spam sound
>
> If you are actually using the result of PTR query for some important
> security decision, then your security sucks in major way. Or, does
> sendmail actually do the "paranoid" procedure:
it can do a sort of paranoid checking
--
Cheers
Res
Slackware -V- sloooUbuntoooou
http://lxer.com/module/newswire/view/93393/
Markku Savela wrote:
> Because it serves no useful purpose. Most dynamic setups have default
> reverse setups. I use Spamhaus ...
And what's wrong with the "default reverse" setups? There are some of
us that look carefully at the dummy name that they return and if
there's an IP(v4) address or certain key words (e.g. "dynamic", "dsl",
etc.) in the string, they are denied by policy without even having to
check a DNSBL.
You make it sound as if these default reverse names are meant to
bypass certain checks. They don't. They make it EASIER for us to
find them.
--
That's all we need: The clueless leading the blind.
In article <87sl4ualrd.fsf@burp.tkv.asdf.org>,
Markku Savela
>per@hedeland.org (Per Hedeland) writes:
>
>> You're confused about what accept_unresolvable_domains does - read
>> cf/README to find out. That verification used to catch a lot of spam
>> with forged sender addresses, I'm not sure how useful it is these days
>> though (i.e. spammers tend to use real domain names and often even real
>> usernames in the domain - not their own though...).
>
>Ahh, thanks, I did suspect that that was not the right control, and
>from other messages I pretty much deduce that sendmail cannot be
>configured not to do the reverse (PTR) query.
>
>Queries don't eat up much CPU, that was my typing on the hip. What
>does bother me is the long delays on some queries and lots of log
>messages on server failures and lame resolvers, which I wanted to get
>rid of.
>
>And those, who claim that reverse PTR query is somehow useful for the
>sendmail, please tell me how?
>
>If you are actually using the result of PTR query for some important
>security decision, then your security sucks in major way. Or, does
>sendmail actually do the "paranoid" procedure:
who do you think invented the 'paraoid' procedure?
And how it came to be called that?