Sender with invalid domain

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Sender with invalid domain

Rick-140


Currently I block email with
smtpd_sender_restrictions  =
    reject_unknown_sender_domain
    check_sender_access hash:/etc/postfix/access
smtpd_data_restrictions =
    reject_multi_recipient_bounce
smtpd_recipient_restrictions =
    reject_non_fqdn_recipient
    reject_non_fqdn_sender
    reject_unknown_sender_domain
    permit_mynetworks
    permit_sasl_authenticated
    check_client_access hash:/etc/postfix/agencies
    reject_unauth_destination
    check_client_access hash:/etc/postfix/access
    check_helo_access pcre:/etc/postfix/helo_checks
    reject_rbl_client zen.spamhaus.org
    reject_rbl_client bl.spamcop.net
    reject_rbl_client dnsbl.sorbs.net
     reject_rbl_client cbl.abuseat.org


I've got a customer who has their  Mailer-Daemon address configured
to respond with an invalid domain so they get rejected:

Apr  9 16:53:44 agencymail postfix/smtpd[1703]: NOQUEUE: reject: RCPT
from theirotherbutvalid.example.com [x.x.x.x]: 450 4.1.8
<[hidden email]>: Sender address rejected: Domain
not found; from=<[hidden email]>
to=<[hidden email]> proto=ESMTP helo=<theirotherbutvalid.example.com>


I'd like to be able to whitelist their.example.com so it won't reject
(trying to convince them to fix it, but you know how it goes).   With
the above config, I think I would need to update /etc/postfix/access,
but also change the order to:
smtpd_sender_restrictions  =
    check_sender_access
hash:/etc/postfix/access           reject_unknown_sender_domain

would I also need to do something with    reject_non_fqdn_sender ?

Thx.

Rick





Rick Steeves
http://www.sinister.net

"Life is like a sausage: The more you pack into it, the longer it gets"

Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

Jorey Bump
[hidden email] wrote, at 04/10/2009 12:08 PM:

> Currently I block email with
> smtpd_sender_restrictions  =
>    reject_unknown_sender_domain
>    check_sender_access hash:/etc/postfix/access
> smtpd_data_restrictions =
>    reject_multi_recipient_bounce
> smtpd_recipient_restrictions =
>    reject_non_fqdn_recipient
>    reject_non_fqdn_sender
>    reject_unknown_sender_domain
>    permit_mynetworks
>    permit_sasl_authenticated
>    check_client_access hash:/etc/postfix/agencies
>    reject_unauth_destination
>    check_client_access hash:/etc/postfix/access
>    check_helo_access pcre:/etc/postfix/helo_checks
>    reject_rbl_client zen.spamhaus.org
>    reject_rbl_client bl.spamcop.net
>    reject_rbl_client dnsbl.sorbs.net
>     reject_rbl_client cbl.abuseat.org
>
>
> I've got a customer who has their  Mailer-Daemon address configured to
> respond with an invalid domain so they get rejected:
>
> Apr  9 16:53:44 agencymail postfix/smtpd[1703]: NOQUEUE: reject: RCPT
> from theirotherbutvalid.example.com [x.x.x.x]: 450 4.1.8
> <[hidden email]>: Sender address rejected: Domain not
> found; from=<[hidden email]> to=<[hidden email]>
> proto=ESMTP helo=<theirotherbutvalid.example.com>
>
>
> I'd like to be able to whitelist their.example.com so it won't reject
> (trying to convince them to fix it, but you know how it goes).   With
> the above config, I think I would need to update /etc/postfix/access,
> but also change the order to:
> smtpd_sender_restrictions  =
>    check_sender_access hash:/etc/postfix/access          
> reject_unknown_sender_domain
>
> would I also need to do something with    reject_non_fqdn_sender ?

Yes, that would also need to follow the map. I recommend that you
dedicate separate maps to check_sender_access and check_client_access;
combining everything into one map is risky. I use the default of
smtpd_delay_reject = yes and organize everything under
smtpd_recipient_restrictions, so the pertinent part looks like this:

smtpd_recipient_restrictions =
    ...
    check_sender_access hash:/etc/postfix/sender
    reject_non_fqdn_sender
    reject_unknown_sender_domain
    permit_mynetworks
    permit_sasl_authenticated
    reject_unauth_destination
    ...
    reject_rbl_client ...

The addresses I want to whitelist are in /etc/postfix/sender:

    [hidden email]    permit_auth_destination

Note that I'm only allowing delivery to my domains; they don't get relay
privileges.

If you want/need to continue using smtpd_sender_restrictions, you might
need a more elaborate configuration. Otherwise, put it under
smtpd_recipient_restrictions and be done with it.

Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

Rick-140
At 01:31 PM 4/10/2009, Jorey Bump wrote:

>Yes, that would also need to follow the map. I recommend that you
>dedicate separate maps to check_sender_access and check_client_access;
>combining everything into one map is risky.

Actually it looks like there was a typo there:
 >    check_client_access hash:/etc/postfix/agencies
 >    reject_unauth_destination
 >    check_client_access hash:/etc/postfix/access

since check_client_access was in there twice, and "access" wasn't a
client list. I removed the second one ("agencies" can send mail,
"access" controls who mail can be from).

Huh, check_unknown_sender_domain was also duplicated.

thanks for the input.

Rick


>I use the default of
>smtpd_delay_reject = yes and organize everything under
>smtpd_recipient_restrictions, so the pertinent part looks like this:
>
>smtpd_recipient_restrictions =
>     ...
>     check_sender_access hash:/etc/postfix/sender
>     reject_non_fqdn_sender
>     reject_unknown_sender_domain
>     permit_mynetworks
>     permit_sasl_authenticated
>     reject_unauth_destination
>     ...
>     reject_rbl_client ...
>
>The addresses I want to whitelist are in /etc/postfix/sender:
>
>     [hidden email]    permit_auth_destination
>
>Note that I'm only allowing delivery to my domains; they don't get relay
>privileges.
>
>If you want/need to continue using smtpd_sender_restrictions, you might
>need a more elaborate configuration. Otherwise, put it under
>smtpd_recipient_restrictions and be done with it.



Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

mouss-4
In reply to this post by Jorey Bump
Jorey Bump a écrit :

> [hidden email] wrote, at 04/10/2009 12:08 PM:
>
>>  [snip]
>>
>> I've got a customer who has their  Mailer-Daemon address configured to
>> respond with an invalid domain so they get rejected:
>>
>> Apr  9 16:53:44 agencymail postfix/smtpd[1703]: NOQUEUE: reject: RCPT
>> from theirotherbutvalid.example.com [x.x.x.x]: 450 4.1.8
>> <[hidden email]>: Sender address rejected: Domain not
>> found; from=<[hidden email]> to=<[hidden email]>
>> proto=ESMTP helo=<theirotherbutvalid.example.com>
>>
>> [snip]


does reject_unknown_sender_domain really reject that many spam (that is
not rejected by zen among other things)?

> [snip]

Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

Paweł Leśniak
W dniu 2009-04-13 22:46, mouss pisze:
> does reject_unknown_sender_domain really reject that many spam (that is
> not rejected by zen among other things)?
>    
According to RFC1912:
(...)
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host *should* have a name.  The consequences of
this are becoming more and more obvious.  Many services available on the
Internet will not talk to you if you aren't correctly registered in the
DNS.
Make sure your PTR and A records match.  For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
(...)

Assuming that spam is a global problem, and above RFC is something to
obey with, it's not really important how many spams we'll block with
reject_unknown_sender_domain. If message is blocked with
reject_unknown_sender_domain, it means sender's server has some problem
with DNS configuration. It's of no cost to configure DNS records for
mailserver, and it makes lots less questions to zen. If mailserver's
admin doesn't care about DNS entries I don't feel any need to care about
emails coming from this mailserver. Fortunately all large public
mailservers we're getting emails from have DNS records set up correctly.
On one of my mailservers I've got:
1859 x Client host rejected: cannot find your hostname
1861 x Client host rejected: cannot find your reverse hostname
2466 x blocked using zen.spamhaus.org
As given above I need less than half of questions to zen RBL. Of course
these numbers can be quite different depending on configuration and type
of email traffic.

In my opinion, *if* one can afford loosing some legitimate mails from
hosts without correct DNS entries, reject_unknown_* rules are worth
using. Still if mail gets rejected, sender has possibility to ask
his/her mailserver's admin to solve the problem.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

mouss-4
Paweł Leśniak a écrit :

> W dniu 2009-04-13 22:46, mouss pisze:
>> does reject_unknown_sender_domain really reject that many spam (that is
>> not rejected by zen among other things)?
>>    
> According to RFC1912:
> (...)
> 2.1 Inconsistent, Missing, or Bad Data
> Every Internet-reachable host *should* have a name.  The consequences of
> this are becoming more and more obvious.  Many services available on the
> Internet will not talk to you if you aren't correctly registered in the
> DNS.
> Make sure your PTR and A records match.  For every IP address, there
> should be a matching PTR record in the in-addr.arpa domain.
> (...)
>
> Assuming that spam is a global problem, and above RFC is something to
> obey with, it's not really important how many spams we'll block with
> reject_unknown_sender_domain.

I disagree:
- I prefer to avoid dns checks if they don't bring me much
- My focus is on stopping spam, not on enforcing RFC conformance. I do
get legitimate mail from non conformant sites, and I do accept it.
- the sender DNS server may be under DoS attack, and I prefer not to add
to the trouble
- the sender may be forged, so I prefer not to knock the sender domain
DNS server unless it brings a reasonable value.


> If message is blocked with
> reject_unknown_sender_domain, it means sender's server has some problem
> with DNS configuration. It's of no cost to configure DNS records for
> mailserver, and it makes lots less questions to zen. If mailserver's
> admin doesn't care about DNS entries I don't feel any need to care about
> emails coming from this mailserver.

possible, but most recipients don't care about DNS: they want legitimate
mail in. not so long ago, I have seen financial mail failing this check.
 this was due to a web app upgrade when the guy who did the upgrade
configured the (local) hostname, not realizing that it was used as the
sender domain. sure, they did something bad. but am I here to watch what
others are doing? certainly not...


> Fortunately all large public
> mailservers we're getting emails from have DNS records set up correctly.

and spammers seem to forge valid addresses, so the check looks useless
to me.

> On one of my mailservers I've got:
> 1859 x Client host rejected: cannot find your hostname
> 1861 x Client host rejected: cannot find your reverse hostname

these also reject legitimate mail. YMMV.

> 2466 x blocked using zen.spamhaus.org
> As given above I need less than half of questions to zen RBL. Of course
> these numbers can be quite different depending on configuration and type
> of email traffic.
>
> In my opinion, *if* one can afford loosing some legitimate mails from
> hosts without correct DNS entries, reject_unknown_* rules are worth
> using. Still if mail gets rejected, sender has possibility to ask
> his/her mailserver's admin to solve the problem.
>

it really depends on your situation. for my own mail, I can do whatever
I want (although I consider myself as my own customer, so I would fire
myself if my-other-self rejects a legitimate mail ;-). but for other
people's mail, a balance is needed: you may want to reject fully
conformant mail (because user doesn't want it, even if it is not spam!)
and you may want to accept mail from "weakly configured" sites.
Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

Paweł Leśniak
W dniu 2009-04-14 23:00, mouss pisze:
Paweł Leśniak a écrit :
  
W dniu 2009-04-13 22:46, mouss pisze:
    
does reject_unknown_sender_domain really reject that many spam (that is
not rejected by zen among other things)?
   
      
According to RFC1912:
(...)
2.1 Inconsistent, Missing, or Bad Data
Every Internet-reachable host *should* have a name.  The consequences of
this are becoming more and more obvious.  Many services available on the
Internet will not talk to you if you aren't correctly registered in the
DNS.
Make sure your PTR and A records match.  For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
(...)

Assuming that spam is a global problem, and above RFC is something to
obey with, it's not really important how many spams we'll block with
reject_unknown_sender_domain.
    

I disagree:
- I prefer to avoid dns checks if they don't bring me much
  
Look at numbers below. I think they bring a lot.
- My focus is on stopping spam, not on enforcing RFC conformance. I do
get legitimate mail from non conformant sites, and I do accept it.
  
Well. it depends on type of service. If I were an ISP, I think I'd take more care to avoid getting "false positives". As long as these are not RFC conformant, I won't call them legitimate emails.
- the sender DNS server may be under DoS attack, and I prefer not to add
to the trouble
  
Well, I do not agree with that. It's just one more DNS query from my host. It's far less offensive then sending single email to this site.
- the sender may be forged, so I prefer not to knock the sender domain
DNS server unless it brings a reasonable value.
  
You can't cure all sites your server is talking to. So you have to choose what you believe is best for you.
If message is blocked with
reject_unknown_sender_domain, it means sender's server has some problem
with DNS configuration. It's of no cost to configure DNS records for
mailserver, and it makes lots less questions to zen. If mailserver's
admin doesn't care about DNS entries I don't feel any need to care about
emails coming from this mailserver. 
    

possible, but most recipients don't care about DNS: they want legitimate
mail in. not so long ago, I have seen financial mail failing this check.
 this was due to a web app upgrade when the guy who did the upgrade
configured the (local) hostname, not realizing that it was used as the
sender domain. sure, they did something bad. but am I here to watch what
others are doing? certainly not...
  
But these recipients care about amount of spam they get. If my server rejects some mails, the other side has to choose if they want me to get their mail or not. If there are not enough rules to stop spam, we have to obey with what we have (RFCs).

Fortunately all large public
mailservers we're getting emails from have DNS records set up correctly.
    

and spammers seem to forge valid addresses, so the check looks useless
to me.
  
How do they forge a client DNS A records consistent with PTR records?
On one of my mailservers I've got:
1859 x Client host rejected: cannot find your hostname
1861 x Client host rejected: cannot find your reverse hostname
    

these also reject legitimate mail. YMMV.
  
I'd call those "legitimate mail". Server *should* have DNS records. If client address has no DNS enrtries, it's RFC-ignorant.
In my opinion, *if* one can afford loosing some legitimate mails from
hosts without correct DNS entries, reject_unknown_* rules are worth
using. Still if mail gets rejected, sender has possibility to ask
his/her mailserver's admin to solve the problem.
    

it really depends on your situation. for my own mail, I can do whatever
I want (although I consider myself as my own customer, so I would fire
myself if my-other-self rejects a legitimate mail ;-). but for other
people's mail, a balance is needed: you may want to reject fully
conformant mail (because user doesn't want it, even if it is not spam!)
and you may want to accept mail from "weakly configured" sites.
  
I do agree with your last sentences in 100%.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

mouss-4
Paweł Leśniak a écrit :
> W dniu 2009-04-14 23:00, mouss pisze:
>> [snip]
>> and spammers seem to forge valid addresses, so the check looks useless
>> to me.
>>  
> How do they forge a client DNS A records consistent with PTR records?

I meant they use forged sender addresses where the domain is valid. for
example, you may get spam with the sender set to <[hidden email]>.

>[snip]
Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

Paweł Leśniak
W dniu 2009-04-14 23:47, mouss pisze:
Paweł Leśniak a écrit :
  
W dniu 2009-04-14 23:00, mouss pisze:
    
[snip]
and spammers seem to forge valid addresses, so the check looks useless
to me.
  
      
How do they forge a client DNS A records consistent with PTR records?
    

I meant they use forged sender addresses where the domain is valid. for
example, you may get spam with the sender set to [hidden email].

  
Sure. If this will be sent from host without correct DNS entries it could be blocked with reject_unknown_*.
Anyways - question was about sender with *invalid* domain.

Pawel Lesniak

Reply | Threaded
Open this post in threaded view
|

Re: Sender with invalid domain

@lbutlr
In reply to this post by mouss-4
On Apr 13, 2009, at 14:46, mouss <[hidden email]> wrote:

> does reject_unknown_sender_domain really reject that many spam (that  
> is
>>>
> not rejected by zen among other things)?

Yes. Especially before IPs get listed in zen.