Mail server in loopback network (fairly common?)

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

Mail server in loopback network (fairly common?)

Juan Miscaro-2
So I have the following lines in main.cf:

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient
        reject_non_fqdn_sender
        reject_unknown_sender_domain
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination
        reject_unknown_reverse_client_hostname
        check_helo_access regexp:/etc/postfix/helo_checks
        check_sender_mx_access cidr:/etc/postfix/bogus_mx
        reject_rbl_client zen.spamhaus.org
        permit

I hope that block is OK.

However, this post is about the 'check_sender_mx_access' line.

Contents of 'bogus_mx':

# bogus networks
0.0.0.0/8               550 Mail server in broadcast network
10.0.0.0/8              550 No route to your RFC 1918 network
127.0.0.0/8             550 Mail server in loopback network
224.0.0.0/4             550 Mail server in class D multicast network
192.168.0.0/16          550 No route to your RFC 1918 network

Now I see in my logs:

postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
<[hidden email]>: Sender address rejected: Mail server in loopback
network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
helo=<toq1-srv.bellnexxia.net>
postfix/smtpd[10896]: disconnect from toq1-srv.bellnexxia.net[209.226.175.120]
postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
postfix/smtpd[10896]: 0CA7F20EEE15:
client=toq1-srv.bellnexxia.net[209.226.175.120]
postfix/cleanup[4433]: 0CA7F20EEE15:
message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>

So here we have a user sending mail to another user in the same
domain.  It makes sense that the mailserver uses its loopback address.
 I just thought that what I'm doing is standard but obviously it
breaks in such a common scenario.  Comments?

/juan
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Sahil Tandon
Juan Miscaro <[hidden email]> wrote:

> So I have the following lines in main.cf:

Please read the DEBUG_README; instead of posting snippets of your
main.cf, please paste the output of 'postconf -n'.

> smtpd_recipient_restrictions =
>         reject_non_fqdn_recipient
>         reject_non_fqdn_sender
>         reject_unknown_sender_domain
>         permit_mynetworks
>         permit_sasl_authenticated
>         reject_unauth_destination
>         reject_unknown_reverse_client_hostname
>         check_helo_access regexp:/etc/postfix/helo_checks
>         check_sender_mx_access cidr:/etc/postfix/bogus_mx
>         reject_rbl_client zen.spamhaus.org
>         permit

This "permit" is unnecessary.

> Contents of 'bogus_mx':
>
> # bogus networks
> 0.0.0.0/8               550 Mail server in broadcast network
> 10.0.0.0/8              550 No route to your RFC 1918 network
> 127.0.0.0/8             550 Mail server in loopback network
> 224.0.0.0/4             550 Mail server in class D multicast network
> 192.168.0.0/16          550 No route to your RFC 1918 network
>
> Now I see in my logs:
>
> postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
> toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
> <[hidden email]>: Sender address rejected: Mail server in loopback
> network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<toq1-srv.bellnexxia.net>
> postfix/smtpd[10896]: disconnect from toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/smtpd[10896]: 0CA7F20EEE15:
> client=toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/cleanup[4433]: 0CA7F20EEE15:
> message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>
>
> So here we have a user sending mail to another user in the same
> domain.  It makes sense that the mailserver uses its loopback address.
>  I just thought that what I'm doing is standard but obviously it
> breaks in such a common scenario.  Comments?

What is 'example.com' really?  The way I understand it,
check_sender_mx_access checks whether the MX host(s) for the MAIL FROM
address match whatever you may have in your access table.  Just because
one user is sending to another in the same domain, that does not mean
the domain itself should have an MX record that points to loopback.

--
Sahil Tandon <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Juan Miscaro-2
2008/9/24 Sahil Tandon <[hidden email]>:

> Juan Miscaro <[hidden email]> wrote:
>
>> So I have the following lines in main.cf:
>
>> smtpd_recipient_restrictions =
>>         reject_non_fqdn_recipient
>>         reject_non_fqdn_sender
>>         reject_unknown_sender_domain
>>         permit_mynetworks
>>         permit_sasl_authenticated
>>         reject_unauth_destination
>>         reject_unknown_reverse_client_hostname
>>         check_helo_access regexp:/etc/postfix/helo_checks
>>         check_sender_mx_access cidr:/etc/postfix/bogus_mx
>>         reject_rbl_client zen.spamhaus.org
>>         permit
>
> This "permit" is unnecessary.
>
>> Contents of 'bogus_mx':
>>
>> # bogus networks
>> 0.0.0.0/8               550 Mail server in broadcast network
>> 10.0.0.0/8              550 No route to your RFC 1918 network
>> 127.0.0.0/8             550 Mail server in loopback network
>> 224.0.0.0/4             550 Mail server in class D multicast network
>> 192.168.0.0/16          550 No route to your RFC 1918 network
>>
>> Now I see in my logs:
>>
>> postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
>> toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
>> <[hidden email]>: Sender address rejected: Mail server in loopback
>> network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
>> helo=<toq1-srv.bellnexxia.net>
>> postfix/smtpd[10896]: disconnect from toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/smtpd[10896]: 0CA7F20EEE15:
>> client=toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/cleanup[4433]: 0CA7F20EEE15:
>> message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>
>>
>> So here we have a user sending mail to another user in the same
>> domain.  It makes sense that the mailserver uses its loopback address.
>>  I just thought that what I'm doing is standard but obviously it
>> breaks in such a common scenario.  Comments?
>
> What is 'example.com' really?


'example.com' is a domain for which my mailserver accepts mail for.


> The way I understand it,
> check_sender_mx_access checks whether the MX host(s) for the MAIL FROM
> address match whatever you may have in your access table.  Just because
> one user is sending to another in the same domain, that does not mean
> the domain itself should have an MX record that points to loopback.


The floor is open.

/juan
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Sahil Tandon
Juan Miscaro <[hidden email]> wrote:

> 'example.com' is a domain for which my mailserver accepts mail for.

On the Postfix machine, what is the output of 'dig +short mx
example.com'?

> > The way I understand it,
> > check_sender_mx_access checks whether the MX host(s) for the MAIL FROM
> > address match whatever you may have in your access table.  Just because
> > one user is sending to another in the same domain, that does not mean
> > the domain itself should have an MX record that points to loopback.
>
> The floor is open.

Better fix it then.  Rather than reciting cliches, your time is probably
better spent reading the DEBUG_README.

--
Sahil Tandon <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Noel Jones-2
In reply to this post by Juan Miscaro-2
Juan Miscaro wrote:

> So I have the following lines in main.cf:
>
> smtpd_recipient_restrictions =
>         reject_non_fqdn_recipient
>         reject_non_fqdn_sender
>         reject_unknown_sender_domain
>         permit_mynetworks
>         permit_sasl_authenticated
>         reject_unauth_destination
>         reject_unknown_reverse_client_hostname
>         check_helo_access regexp:/etc/postfix/helo_checks
>         check_sender_mx_access cidr:/etc/postfix/bogus_mx
>         reject_rbl_client zen.spamhaus.org
>         permit
>
> I hope that block is OK.
>
> However, this post is about the 'check_sender_mx_access' line.
>
> Contents of 'bogus_mx':
>
> # bogus networks
> 0.0.0.0/8               550 Mail server in broadcast network
> 10.0.0.0/8              550 No route to your RFC 1918 network
> 127.0.0.0/8             550 Mail server in loopback network
> 224.0.0.0/4             550 Mail server in class D multicast network
> 192.168.0.0/16          550 No route to your RFC 1918 network
>
> Now I see in my logs:
>
> postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
> toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
> <[hidden email]>: Sender address rejected: Mail server in loopback
> network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<toq1-srv.bellnexxia.net>
> postfix/smtpd[10896]: disconnect from toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/smtpd[10896]: connect from toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/smtpd[10896]: 0CA7F20EEE15:
> client=toq1-srv.bellnexxia.net[209.226.175.120]
> postfix/cleanup[4433]: 0CA7F20EEE15:
> message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>
>
> So here we have a user sending mail to another user in the same
> domain.  It makes sense that the mailserver uses its loopback address.
>  I just thought that what I'm doing is standard but obviously it
> breaks in such a common scenario.  Comments?
>
> /juan


I don't think it's common to have localhost as an MX, but it
is common to have local/internal domains with an RFC1918 MX.

At any rate, domains that should not be rejected by this rule
need to be exempted somehow.  There are several ways...

The easy way is to put this check under
smtpd_sender_restrictions (and Not under
smtpd_recipient_restrictions) proceeded by a whitelist:
smtpd_sender_restrictions =
   check_sender_access hash:/etc/postfix/domain_mx_whitelist
   check_sender_mx_access cidr:/etc/postfix/bogus_mx

# domain_mx_whitelist
example.com  OK
example.net  OK


--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Juan Miscaro-2
2008/9/25 Noel Jones <[hidden email]>:

> Juan Miscaro wrote:
>>
>> So I have the following lines in main.cf:
>>
>> smtpd_recipient_restrictions =
>>        reject_non_fqdn_recipient
>>        reject_non_fqdn_sender
>>        reject_unknown_sender_domain
>>        permit_mynetworks
>>        permit_sasl_authenticated
>>        reject_unauth_destination
>>        reject_unknown_reverse_client_hostname
>>        check_helo_access regexp:/etc/postfix/helo_checks
>>        check_sender_mx_access cidr:/etc/postfix/bogus_mx
>>        reject_rbl_client zen.spamhaus.org
>>        permit
>>
>> I hope that block is OK.
>>
>> However, this post is about the 'check_sender_mx_access' line.
>>
>> Contents of 'bogus_mx':
>>
>> # bogus networks
>> 0.0.0.0/8               550 Mail server in broadcast network
>> 10.0.0.0/8              550 No route to your RFC 1918 network
>> 127.0.0.0/8             550 Mail server in loopback network
>> 224.0.0.0/4             550 Mail server in class D multicast network
>> 192.168.0.0/16          550 No route to your RFC 1918 network
>>
>> Now I see in my logs:
>>
>> postfix/smtpd[10896]: connect from
>> toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
>> toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
>> <[hidden email]>: Sender address rejected: Mail server in loopback
>> network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
>> helo=<toq1-srv.bellnexxia.net>
>> postfix/smtpd[10896]: disconnect from
>> toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/smtpd[10896]: connect from
>> toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/smtpd[10896]: 0CA7F20EEE15:
>> client=toq1-srv.bellnexxia.net[209.226.175.120]
>> postfix/cleanup[4433]: 0CA7F20EEE15:
>> message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>
>>
>> So here we have a user sending mail to another user in the same
>> domain.  It makes sense that the mailserver uses its loopback address.
>>  I just thought that what I'm doing is standard but obviously it
>> breaks in such a common scenario.  Comments?
>>
>> /juan
>
>
> I don't think it's common to have localhost as an MX, but it is common to
> have local/internal domains with an RFC1918 MX.
>
> At any rate, domains that should not be rejected by this rule need to be
> exempted somehow.  There are several ways...
>
> The easy way is to put this check under smtpd_sender_restrictions (and Not
> under smtpd_recipient_restrictions) proceeded by a whitelist:
> smtpd_sender_restrictions =
>  check_sender_access hash:/etc/postfix/domain_mx_whitelist
>  check_sender_mx_access cidr:/etc/postfix/bogus_mx
>
> # domain_mx_whitelist
> example.com  OK
> example.net  OK

Thank you Noel.

However, since there will be many more domains hosted on this server
is there not a better way?  Or perhaps my server is misconfigured.  My
server evidently resides on a protected internal network and so, yes,
it also has an RFC1918 address.  Right now my hosts file has both
127.0.0.1 and an RFC1918 address listed there.

/juan
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

mouss-2
Juan Miscaro wrote:

> 2008/9/25 Noel Jones <[hidden email]>:
>> Juan Miscaro wrote:
>>> So I have the following lines in main.cf:
>>>
>>> smtpd_recipient_restrictions =
>>>        reject_non_fqdn_recipient
>>>        reject_non_fqdn_sender
>>>        reject_unknown_sender_domain
>>>        permit_mynetworks
>>>        permit_sasl_authenticated
>>>        reject_unauth_destination
>>>        reject_unknown_reverse_client_hostname
>>>        check_helo_access regexp:/etc/postfix/helo_checks
>>>        check_sender_mx_access cidr:/etc/postfix/bogus_mx
>>>        reject_rbl_client zen.spamhaus.org
>>>        permit
>>>
>>> I hope that block is OK.
>>>
>>> However, this post is about the 'check_sender_mx_access' line.
>>>
>>> Contents of 'bogus_mx':
>>>
>>> # bogus networks
>>> 0.0.0.0/8               550 Mail server in broadcast network
>>> 10.0.0.0/8              550 No route to your RFC 1918 network
>>> 127.0.0.0/8             550 Mail server in loopback network
>>> 224.0.0.0/4             550 Mail server in class D multicast network
>>> 192.168.0.0/16          550 No route to your RFC 1918 network
>>>
>>> Now I see in my logs:
>>>
>>> postfix/smtpd[10896]: connect from
>>> toq1-srv.bellnexxia.net[209.226.175.120]
>>> postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
>>> toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
>>> <[hidden email]>: Sender address rejected: Mail server in loopback
>>> network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
>>> helo=<toq1-srv.bellnexxia.net>
>>> postfix/smtpd[10896]: disconnect from
>>> toq1-srv.bellnexxia.net[209.226.175.120]
>>> postfix/smtpd[10896]: connect from
>>> toq1-srv.bellnexxia.net[209.226.175.120]
>>> postfix/smtpd[10896]: 0CA7F20EEE15:
>>> client=toq1-srv.bellnexxia.net[209.226.175.120]
>>> postfix/cleanup[4433]: 0CA7F20EEE15:
>>> message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>
>>>
>>> So here we have a user sending mail to another user in the same
>>> domain.  It makes sense that the mailserver uses its loopback address.
>>>  I just thought that what I'm doing is standard but obviously it
>>> breaks in such a common scenario.  Comments?
>>>
>>> /juan
>>
>> I don't think it's common to have localhost as an MX, but it is common to
>> have local/internal domains with an RFC1918 MX.
>>
>> At any rate, domains that should not be rejected by this rule need to be
>> exempted somehow.  There are several ways...
>>
>> The easy way is to put this check under smtpd_sender_restrictions (and Not
>> under smtpd_recipient_restrictions) proceeded by a whitelist:
>> smtpd_sender_restrictions =
>>  check_sender_access hash:/etc/postfix/domain_mx_whitelist
>>  check_sender_mx_access cidr:/etc/postfix/bogus_mx
>>
>> # domain_mx_whitelist
>> example.com  OK
>> example.net  OK
>
> Thank you Noel.
>
> However, since there will be many more domains hosted on this server
> is there not a better way?

yes, there is: remove your check_sender_mx_access. did it ever catch
spam on your server? it never caught anything here.

> Or perhaps my server is misconfigured.  My
> server evidently resides on a protected internal network and so, yes,
> it also has an RFC1918 address.  Right now my hosts file has both
> 127.0.0.1 and an RFC1918 address listed there.
>
> /juan

Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Juan Miscaro-2
2008/9/25 mouss <[hidden email]>:

> Juan Miscaro wrote:
>>
>> 2008/9/25 Noel Jones <[hidden email]>:
>>>
>>> Juan Miscaro wrote:
>>>>
>>>> So I have the following lines in main.cf:
>>>>
>>>> smtpd_recipient_restrictions =
>>>>       reject_non_fqdn_recipient
>>>>       reject_non_fqdn_sender
>>>>       reject_unknown_sender_domain
>>>>       permit_mynetworks
>>>>       permit_sasl_authenticated
>>>>       reject_unauth_destination
>>>>       reject_unknown_reverse_client_hostname
>>>>       check_helo_access regexp:/etc/postfix/helo_checks
>>>>       check_sender_mx_access cidr:/etc/postfix/bogus_mx
>>>>       reject_rbl_client zen.spamhaus.org
>>>>       permit
>>>>
>>>> I hope that block is OK.
>>>>
>>>> However, this post is about the 'check_sender_mx_access' line.
>>>>
>>>> Contents of 'bogus_mx':
>>>>
>>>> # bogus networks
>>>> 0.0.0.0/8               550 Mail server in broadcast network
>>>> 10.0.0.0/8              550 No route to your RFC 1918 network
>>>> 127.0.0.0/8             550 Mail server in loopback network
>>>> 224.0.0.0/4             550 Mail server in class D multicast network
>>>> 192.168.0.0/16          550 No route to your RFC 1918 network
>>>>
>>>> Now I see in my logs:
>>>>
>>>> postfix/smtpd[10896]: connect from
>>>> toq1-srv.bellnexxia.net[209.226.175.120]
>>>> postfix/smtpd[10896]: NOQUEUE: reject: RCPT from
>>>> toq1-srv.bellnexxia.net[209.226.175.120]: 550 5.7.1
>>>> <[hidden email]>: Sender address rejected: Mail server in loopback
>>>> network; from=<[hidden email]> to=<[hidden email]> proto=ESMTP
>>>> helo=<toq1-srv.bellnexxia.net>
>>>> postfix/smtpd[10896]: disconnect from
>>>> toq1-srv.bellnexxia.net[209.226.175.120]
>>>> postfix/smtpd[10896]: connect from
>>>> toq1-srv.bellnexxia.net[209.226.175.120]
>>>> postfix/smtpd[10896]: 0CA7F20EEE15:
>>>> client=toq1-srv.bellnexxia.net[209.226.175.120]
>>>> postfix/cleanup[4433]: 0CA7F20EEE15:
>>>> message-id=<20080923185145.MZWL2539.toq1-srv.bellnexxia.net@toq1-srv>
>>>>
>>>> So here we have a user sending mail to another user in the same
>>>> domain.  It makes sense that the mailserver uses its loopback address.
>>>>  I just thought that what I'm doing is standard but obviously it
>>>> breaks in such a common scenario.  Comments?
>>>>
>>>> /juan
>>>
>>> I don't think it's common to have localhost as an MX, but it is common to
>>> have local/internal domains with an RFC1918 MX.
>>>
>>> At any rate, domains that should not be rejected by this rule need to be
>>> exempted somehow.  There are several ways...
>>>
>>> The easy way is to put this check under smtpd_sender_restrictions (and
>>> Not
>>> under smtpd_recipient_restrictions) proceeded by a whitelist:
>>> smtpd_sender_restrictions =
>>>  check_sender_access hash:/etc/postfix/domain_mx_whitelist
>>>  check_sender_mx_access cidr:/etc/postfix/bogus_mx
>>>
>>> # domain_mx_whitelist
>>> example.com  OK
>>> example.net  OK
>>
>> Thank you Noel.
>>
>> However, since there will be many more domains hosted on this server
>> is there not a better way?
>
> yes, there is: remove your check_sender_mx_access. did it ever catch spam on
> your server? it never caught anything here.

Nicely said mouss, nicely said.

>> Or perhaps my server is misconfigured.  My
>> server evidently resides on a protected internal network and so, yes,
>> it also has an RFC1918 address.  Right now my hosts file has both
>> 127.0.0.1 and an RFC1918 address listed there.
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Henrik K
In reply to this post by mouss-2
On Thu, Sep 25, 2008 at 03:30:18PM +0200, mouss wrote:
>>
>> However, since there will be many more domains hosted on this server
>> is there not a better way?
>
> yes, there is: remove your check_sender_mx_access. did it ever catch  
> spam on your server? it never caught anything here.

I don't use it purely for spam prevention. Checking that that sender and
recipient MX's arent pointing to places such as localhost prevents all sorts
of funny things. What's the point of receiving mail if you can't reply to it
anyway?

The REAL solution is not to check mx access for local mail. If sender and
recipient are on same domain, then mostly likely you should use
permit_mynetworks or such before the check.

Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

mouss-2
Henrik K wrote:

> On Thu, Sep 25, 2008 at 03:30:18PM +0200, mouss wrote:
>>> However, since there will be many more domains hosted on this server
>>> is there not a better way?
>> yes, there is: remove your check_sender_mx_access. did it ever catch  
>> spam on your server? it never caught anything here.
>
> I don't use it purely for spam prevention. Checking that that sender and
> recipient MX's arent pointing to places such as localhost prevents all sorts
> of funny things. What's the point of receiving mail if you can't reply to it
> anyway?

I agree on the principle of "reachable senders", but I have used it for
so long and it never caught any spam. so why query dns for every email
when it catches nothing. and given that the sender may be forged, you'll
be hitting an innocent dns server. not a serious issue, but if the
benefit is 0 hit, ...

note also that a wrong envelope sender doesn't mean you can't reply. The
From: header may still be ok.

The only times I've seen an "unreachable" sender (not blocked by zen and
other checks) was with legitimate mail. the most noticeable was very
important mail (financial!) caused by an upgrade of the remote
application server.

>
> The REAL solution is not to check mx access for local mail. If sender and
> recipient are on same domain, then mostly likely you should use
> permit_mynetworks or such before the check.
>

He already has permit_mynetworks and so on. so his problem is different
(and probably rare). He needs to exclude his domains from
check_mx_access. If he puts check_mx_access at the end of his
restrictions, he can use permit_auth_destination. but again, is all this
worth the pain?
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Noel Jones-2
mouss wrote:
>
> He already has permit_mynetworks and so on. so his problem is different
> (and probably rare). He needs to exclude his domains from
> check_mx_access.

Using a check_sender_access whitelist as posted earlier is one
solution.

a few other obvious solutions:
- not rejecting either localhost nor the servers own RFC1918
IP. (use DUNNO to whitelist internal host IPs in the cidr table).
- don't reject any RFC1928 addresses.
- don't use this feature.


> If he puts check_mx_access at the end of his
> restrictions, he can use permit_auth_destination.

No, permit_auth_destination will whitelist the recipient, OP
needs to whitelist the sender.  (I nearly fell into this same
trap earlier today).


--
Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

mouss-2
Noel Jones wrote:

> mouss wrote:
>>
>> He already has permit_mynetworks and so on. so his problem is
>> different (and probably rare). He needs to exclude his domains from
>> check_mx_access.
>
> Using a check_sender_access whitelist as posted earlier is one solution.
>
> a few other obvious solutions:
> - not rejecting either localhost nor the servers own RFC1918 IP. (use
> DUNNO to whitelist internal host IPs in the cidr table).
> - don't reject any RFC1928 addresses.
> - don't use this feature.

or don't set the MX to such IPs.

>
>
>> If he puts check_mx_access at the end of his restrictions, he can use
>> permit_auth_destination.
>
> No, permit_auth_destination will whitelist the recipient, OP needs to
> whitelist the sender.  (I nearly fell into this same trap earlier today).
>

argh! indeed.

Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Brian Evans - Postfix List
In reply to this post by mouss-2
mouss wrote:

> Henrik K wrote:
>> On Thu, Sep 25, 2008 at 03:30:18PM +0200, mouss wrote:
>>>> However, since there will be many more domains hosted on this server
>>>> is there not a better way?
>>> yes, there is: remove your check_sender_mx_access. did it ever
>>> catch  spam on your server? it never caught anything here.
>>
>> I don't use it purely for spam prevention. Checking that that sender and
>> recipient MX's arent pointing to places such as localhost prevents
>> all sorts
>> of funny things. What's the point of receiving mail if you can't
>> reply to it
>> anyway?
>
> I agree on the principle of "reachable senders", but I have used it
> for so long and it never caught any spam. so why query dns for every
> email when it catches nothing. and given that the sender may be
> forged, you'll be hitting an innocent dns server. not a serious issue,
> but if the benefit is 0 hit, ...
>
> note also that a wrong envelope sender doesn't mean you can't reply.
> The From: header may still be ok.
>
> The only times I've seen an "unreachable" sender (not blocked by zen
> and other checks) was with legitimate mail. the most noticeable was
> very important mail (financial!) caused by an upgrade of the remote
> application server.
>
>>
>> The REAL solution is not to check mx access for local mail. If sender
>> and
>> recipient are on same domain, then mostly likely you should use
>> permit_mynetworks or such before the check.
>>
>
> He already has permit_mynetworks and so on. so his problem is
> different (and probably rare). He needs to exclude his domains from
> check_mx_access. If he puts check_mx_access at the end of his
> restrictions, he can use permit_auth_destination. but again, is all
> this worth the pain?

The Problem the OP appears to fall into is that mail coming from outside
the mynetworks is being trapped to do a "local" DNS MX/A record.
It is probably pointing mail to the "example.com" as 127.0.0.1 (not
uncommon).

Without knowing the result of 'host example.com' on the Postfix box, we
will never know.

Brian
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Henrik K
In reply to this post by mouss-2
On Thu, Sep 25, 2008 at 07:07:41PM +0200, mouss wrote:
>
> and given that the sender may be forged, you'll be hitting an innocent dns
> server. not a serious issue, but if the benefit is 0 hit, ...

I do have hits every day. Even if it's in the 0.01% region..

You are right, the point of dns queries is pretty desperate. MX's usually
have high TTL and will pretty much always come from your cache.

> note also that a wrong envelope sender doesn't mean you can't reply. The  
> From: header may still be ok.

Ok that's true. But it still doesn't make it right to have a non-working
envelope sender.

Reply | Threaded
Open this post in threaded view
|

Delivery delay problems

Marco TCHI HONG
Hello,
I am using Postfix 2.3.3 and Kaspersky Antispam/Antivirus on our MX.
Mailboxes are hosted on another server.
The MX is relaying 250 domains or so, and it doesn't have resources
issues.

Our problem is that mail stay a long time in the active queue before the
content filter, but when it's sent to the server where mailboxes are
stored there's no problem:

Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411:
to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5,
delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok
(2.0.0 Ok: queued as 5A0B6718ACF ))

Sep 26 10:11:57 mx postfix/smtp[744]: 5A0B6718ACF:
to=<[hidden email]>, relay=zsmtp.dts.mg[196.192.32.54]:25,
delay=0.12, delays=0.08/0.01/0/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok:
queued as 6D55BF70AA2)

So I went debug mode for the queue manager, and I don't see any
errors...but it takes 3 minutes and 30 seconds (see logs below) before the
mail is sent to the content filter. What could be the cause?

Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_active_feed: queue incoming
Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_active_feed:
incoming/1906C718411
Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_message_alloc: active
1906C718411
Sep 26 10:08:08 mx postfix/qmgr[669]: record C             529
565               1
         0
Sep 26 10:08:08 mx postfix/qmgr[669]: record T 1222412887 94462
Sep 26 10:08:08 mx postfix/qmgr[669]: record A create_time=1222412887
Sep 26 10:08:08 mx postfix/qmgr[669]: record L kas3scan:127.0.0.1:9026
Sep 26 10:08:08 mx postfix/qmgr[669]: record A rewrite_context=remote
Sep 26 10:08:08 mx postfix/qmgr[669]: record S [hidden email]
Sep 26 10:08:08 mx postfix/qmgr[669]: 1906C718411:
from=<[hidden email]>, size=529, nrcpt=1 (queu
e active)
Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_client_name=dts.dts.mg
Sep 26 10:08:08 mx postfix/qmgr[669]: record A
log_client_address=193.251.140.178
Sep 26 10:08:08 mx postfix/qmgr[669]: record A
log_message_origin=dts.dts.mg[193.251.140.178]
Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_helo_name=[127.0.0.1]
Sep 26 10:08:08 mx postfix/qmgr[669]: record A log_protocol_name=ESMTP
Sep 26 10:08:08 mx postfix/qmgr[669]: record A client_name=dts.dts.mg
Sep 26 10:08:08 mx postfix/qmgr[669]: record A
reverse_client_name=dts.dts.mg
Sep 26 10:08:08 mx postfix/qmgr[669]: record A
client_address=193.251.140.178
Sep 26 10:08:08 mx postfix/qmgr[669]: record A helo_name=[127.0.0.1]
Sep 26 10:08:08 mx postfix/qmgr[669]: record A client_address_type=2
Sep 26 10:08:08 mx postfix/qmgr[669]: record A
dsn_orig_rcpt=rfc822;[hidden email]
Sep 26 10:08:08 mx postfix/qmgr[669]: record O [hidden email]
Sep 26 10:08:08 mx postfix/qmgr[669]: record R [hidden email]
Sep 26 10:08:08 mx postfix/qmgr[669]: record M
Sep 26 10:08:08 mx postfix/qmgr[669]: record X
Sep 26 10:08:08 mx postfix/qmgr[669]: record E
Sep 26 10:08:08 mx postfix/qmgr[669]: dir_forest: 1906C718411 -> 1/
Sep 26 10:08:08 mx postfix/qmgr[669]: start sorted recipient list
Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_message_sort:
[hidden email]
Sep 26 10:08:08 mx postfix/qmgr[669]: end sorted recipient list
Sep 26 10:08:08 mx postfix/qmgr[669]: start sorted recipient list
Sep 26 10:08:08 mx postfix/qmgr[669]: qmgr_message_sort:
[hidden email]
Sep 26 10:08:08 mx postfix/qmgr[669]: end sorted recipient list
Sep 26 10:08:08 mx postfix/qmgr[669]: watchdog_start: 0x9594160

Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_active_feed: queue incoming
Sep 26 10:11:38 mx postfix/qmgr[669]: transport_event: kas3scan
Sep 26 10:11:38 mx postfix/qmgr[669]: private/kas3scan socket: wanted
attribute: status
Sep 26 10:11:38 mx postfix/qmgr[669]: input attribute name: status
Sep 26 10:11:38 mx postfix/qmgr[669]: input attribute value: 0
Sep 26 10:11:38 mx postfix/qmgr[669]: private/kas3scan socket: wanted
attribute: (list terminator)
Sep 26 10:11:38 mx postfix/qmgr[669]: input attribute name: (end)
Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_peer_select: 1906C718411
kas3scan 127.0.0.1:9026 (80 of 8
0)
Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_job_retire: 1906C718411
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr flags = 2051
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr queue_name = active
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr queue_id = 1906C718411
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr offset = 565
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr size = 529
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr nexthop = 127.0.0.1:9026
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr encoding =
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr sender = [hidden email]
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr envelope_id =
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr ret_flags = 0
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr time = [data 44 bytes]
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr log_client_name =
dts.dts.mg
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr log_client_address =
193.251.140.178
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr log_protocol_name = ESMTP
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr log_helo_name =
[127.0.0.1]
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr sasl_method =
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr sasl_username =
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr sasl_sender =
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr rewrite_context = remote
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr recipient_count = 1
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr original_recipient =
[hidden email]
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr recipient =
[hidden email]
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr offset = 540
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr dsn_orig_rcpt =
rfc822;[hidden email]
Sep 26 10:11:38 mx postfix/qmgr[669]: send attr notify_flags = 0
Sep 26 10:11:38 mx postfix/qmgr[669]: qmgr_deliver: site `127.0.0.1:9026'
Sep 26 10:11:38 mx postfix/qmgr[669]: watchdog_start: 0x9594160

Sep 26 10:11:57 mx postfix/qmgr[669]: qmgr_active_done: 1906C718411
Sep 26 10:11:57 mx postfix/qmgr[669]: 1906C718411: removed
Sep 26 10:11:57 mx postfix/qmgr[669]: qmgr_job_free: 1906C718411 kas3scan
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Charles Marcus
In reply to this post by Henrik K
On 9/26/2008, Henrik K ([hidden email]) wrote:
> Ok that's true. But it still doesn't make it right to have a non-working
> envelope sender.

What is 'right' and what is reality are often very different things.

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: Mail server in loopback network (fairly common?)

Juan Miscaro-2
In reply to this post by Brian Evans - Postfix List
2008/9/25 Brian Evans - Postfix List <[hidden email]>:

> mouss wrote:
>> Henrik K wrote:
>>> On Thu, Sep 25, 2008 at 03:30:18PM +0200, mouss wrote:
>>>>> However, since there will be many more domains hosted on this server
>>>>> is there not a better way?
>>>> yes, there is: remove your check_sender_mx_access. did it ever
>>>> catch  spam on your server? it never caught anything here.
>>>
>>> I don't use it purely for spam prevention. Checking that that sender and
>>> recipient MX's arent pointing to places such as localhost prevents
>>> all sorts
>>> of funny things. What's the point of receiving mail if you can't
>>> reply to it
>>> anyway?
>>
>> I agree on the principle of "reachable senders", but I have used it
>> for so long and it never caught any spam. so why query dns for every
>> email when it catches nothing. and given that the sender may be
>> forged, you'll be hitting an innocent dns server. not a serious issue,
>> but if the benefit is 0 hit, ...
>>
>> note also that a wrong envelope sender doesn't mean you can't reply.
>> The From: header may still be ok.
>>
>> The only times I've seen an "unreachable" sender (not blocked by zen
>> and other checks) was with legitimate mail. the most noticeable was
>> very important mail (financial!) caused by an upgrade of the remote
>> application server.
>>
>>>
>>> The REAL solution is not to check mx access for local mail. If sender
>>> and
>>> recipient are on same domain, then mostly likely you should use
>>> permit_mynetworks or such before the check.
>>>
>>
>> He already has permit_mynetworks and so on. so his problem is
>> different (and probably rare). He needs to exclude his domains from
>> check_mx_access. If he puts check_mx_access at the end of his
>> restrictions, he can use permit_auth_destination. but again, is all
>> this worth the pain?
>
> The Problem the OP appears to fall into is that mail coming from outside
> the mynetworks is being trapped to do a "local" DNS MX/A record.
> It is probably pointing mail to the "example.com" as 127.0.0.1 (not
> uncommon).

It points mail for the domain to the local server's FQDN.  And that
translates to localhost because of entries in /etc/hosts.  I thought
all this was clear.  My apologies.

~juan
Reply | Threaded
Open this post in threaded view
|

Re: Delivery delay problems

Wietse Venema
In reply to this post by Marco TCHI HONG
Marco TCHI HONG:
> Our problem is that mail stay a long time in the active queue before the
> content filter, but when it's sent to the server where mailboxes are
> stored there's no problem:
>
> Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411:
> to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5,
> delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok
> (2.0.0 Ok: queued as 5A0B6718ACF ))

The mail spends 19 seconds in the content filter.  This means that
your content filter performance sucks.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: Delivery delay problems

Marco TCHI HONG
Ok, so the problem is definitely a content filter problem ?
This has nothing to do with our Postfix configuration if I understand.

-----Message d'origine-----
De : [hidden email]
[mailto:[hidden email]] De la part de Wietse Venema
Envoyé : vendredi 26 septembre 2008 15:00
À : Marco TCHI HONG
Cc : [hidden email]
Objet : Re: Delivery delay problems

Marco TCHI HONG:
> Our problem is that mail stay a long time in the active queue before the
> content filter, but when it's sent to the server where mailboxes are
> stored there's no problem:
>
> Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411:
> to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5,
> delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok
> (2.0.0 Ok: queued as 5A0B6718ACF ))

The mail spends 19 seconds in the content filter.  This means that
your content filter performance sucks.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Delivery delay problems

Wietse Venema
Marco TCHI HONG:
> Our problem is that mail stay a long time in the active queue before the
> content filter, but when it's sent to the server where mailboxes are
> stored there's no problem:
>
> Sep 26 10:11:57 mx postfix/smtp[1387]: 1906C718411:
> to=<[hidden email]>, relay=127.0.0.1[127.0.0.1]:9026, conn_use=5,
> delay=230, delays=0.93/210/0/19, dsn=2.0.0, status=sent (250 2.0.0 Ok
> (2.0.0 Ok: queued as 5A0B6718ACF ))

Wietse:
> The mail spends 19 seconds in the content filter.  This means that
> your content filter performance sucks.

Marco TCHI HONG:
> Ok, so the problem is definitely a content filter problem ?
> This has nothing to do with our Postfix configuration if I understand.

You need to find out why the mail spends 19 seconds in the content
filter.  One possible explanation is that the filter queries a
broken DNS (blocklist) server. Another possibility is that the
Postfix SMTP server behind the content filter has problems when it
tries to resolve the 127.0.0.1 client IP address to a hostname.
And then there are a billion other possibilities.

        Wietse
12