Re: mysql local_recipient_map

2016-06-13 Thread Paul R. Ganci
I changed the line hosts = server-1.example.com to use an IP address 
instead hosts = 192.168.1.200 and everything started working. Does 
anyone know what I am missing in that it seems postfix did resolve the 
IP address when communicating with the mysql database?



On 06/13/2016 07:52 PM, Paul R. Ganci wrote:
I have setup a mysql data baseto provide a list of of local email 
recipients for a gateway email server. The configuration file looks 
like this:


> cat /etc/postfix/local_recipient_map.cf
user = postfix
password = Secret
hosts = server-1.example.com
dbname = postfix
query = SELECT destination FROM postfix_virtual WHERE email = '%s'

If I do a test query ala:

> postmap -q sa...@example.com mysql:/etc/postfix/local_recipient_map.cf
sallysemail

This last command seems to indicate that the query completes 
successfully. So I then configured the main.cf per this extracted stanza:


# REJECTING MAIL FOR UNKNOWN LOCAL USERS
#
# The local_recipient_maps parameter specifies optional lookup tables
# with all names or addresses of users that are local with respect
# to $mydestination, $inet_interfaces or $proxy_interfaces.
#
# If this parameter is defined, then the SMTP server will reject
# mail for unknown local users. This parameter is defined by default.
#
# To turn off local recipient checking in the SMTP server, specify
# local_recipient_maps = (i.e. empty).
#
# The default setting assumes that you use the default Postfix local
# delivery agent for local delivery. You need to update the
# local_recipient_maps setting if:
#
# - You define $mydestination domain recipients in files other than
#   /etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
#   For example, you define $mydestination domain recipients in
#   the $virtual_mailbox_maps files.
#
# - You redefine the local delivery agent in master.cf.
#
# - You redefine the "local_transport" setting in main.cf.
#
# - You use the "luser_relay", "mailbox_transport", or 
"fallback_transport"

#   feature of the Postfix local delivery agent (see local(8)).
#
# Details are described in the LOCAL_RECIPIENT_README file.
#
# Beware: if the Postfix SMTP server runs chrooted, you probably have
# to access the passwd file via the proxymap service, in order to
# overcome chroot restrictions. The alternative, having a copy of
# the system passwd file in the chroot jail is just not practical.
#
# The right-hand side of the lookup tables is conveniently ignored.
# In the left-hand side, specify a bare username, an @domain.tld
# wild-card, or specify a u...@domain.tld address.
#
#local_recipient_maps = unix:passwd.byname $alias_maps
#local_recipient_maps = proxy:unix:passwd.byname $alias_maps
#local_recipient_maps =
#local_recipient_maps =
local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf

However after I issue

>postfix reload

I get the following warning in the /var/log/maillog file:

Jun 13 17:02:33 mx02 postfix/smtpd[24400]: warning: 
mysql:/etc/postfix/local_recipient_map.cf lookup error for 
"sa...@example.com"
Jun 13 17:02:33 mx02 postfix/smtpd[24400]: NOQUEUE: reject: RCPT from 
unknown[50.31.61.193]: 451 4.3.0 : Temporary lookup 
failure; 
from= 
to= proto=ESMTP helo=


Can somebody tell me what I am doing wrong? Why does the postmap -q 
command line query successfully return a result but fail from postfix?


Thank you for your help.



--
Paul (ga...@nurdog.com)
Cell: (303)257-5208


mysql local_recipient_map

2016-06-13 Thread Paul R. Ganci
I have setup a mysql data baseto provide a list of of local email 
recipients for a gateway email server. The configuration file looks like 
this:


> cat /etc/postfix/local_recipient_map.cf
user = postfix
password = Secret
hosts = server-1.example.com
dbname = postfix
query = SELECT destination FROM postfix_virtual WHERE email = '%s'

If I do a test query ala:

> postmap -q sa...@example.com mysql:/etc/postfix/local_recipient_map.cf
sallysemail

This last command seems to indicate that the query completes 
successfully. So I then configured the main.cf per this extracted stanza:


# REJECTING MAIL FOR UNKNOWN LOCAL USERS
#
# The local_recipient_maps parameter specifies optional lookup tables
# with all names or addresses of users that are local with respect
# to $mydestination, $inet_interfaces or $proxy_interfaces.
#
# If this parameter is defined, then the SMTP server will reject
# mail for unknown local users. This parameter is defined by default.
#
# To turn off local recipient checking in the SMTP server, specify
# local_recipient_maps = (i.e. empty).
#
# The default setting assumes that you use the default Postfix local
# delivery agent for local delivery. You need to update the
# local_recipient_maps setting if:
#
# - You define $mydestination domain recipients in files other than
#   /etc/passwd, /etc/aliases, or the $virtual_alias_maps files.
#   For example, you define $mydestination domain recipients in
#   the $virtual_mailbox_maps files.
#
# - You redefine the local delivery agent in master.cf.
#
# - You redefine the "local_transport" setting in main.cf.
#
# - You use the "luser_relay", "mailbox_transport", or "fallback_transport"
#   feature of the Postfix local delivery agent (see local(8)).
#
# Details are described in the LOCAL_RECIPIENT_README file.
#
# Beware: if the Postfix SMTP server runs chrooted, you probably have
# to access the passwd file via the proxymap service, in order to
# overcome chroot restrictions. The alternative, having a copy of
# the system passwd file in the chroot jail is just not practical.
#
# The right-hand side of the lookup tables is conveniently ignored.
# In the left-hand side, specify a bare username, an @domain.tld
# wild-card, or specify a u...@domain.tld address.
#
#local_recipient_maps = unix:passwd.byname $alias_maps
#local_recipient_maps = proxy:unix:passwd.byname $alias_maps
#local_recipient_maps =
#local_recipient_maps =
local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf

However after I issue

>postfix reload

I get the following warning in the /var/log/maillog file:

Jun 13 17:02:33 mx02 postfix/smtpd[24400]: warning: 
mysql:/etc/postfix/local_recipient_map.cf lookup error for 
"sa...@example.com"
Jun 13 17:02:33 mx02 postfix/smtpd[24400]: NOQUEUE: reject: RCPT from 
unknown[50.31.61.193]: 451 4.3.0 : Temporary lookup 
failure; from= 
to= proto=ESMTP helo=


Can somebody tell me what I am doing wrong? Why does the postmap -q 
command line query successfully return a result but fail from postfix?


Thank you for your help.



Re: simple greylisting by geoip? milter or policy server?

2016-06-13 Thread Wietse Venema
list...@tutanota.com:
> But then I also read that that 'Policy delegation is now the preferred method 
> for adding policies to Postfix.'

Milter support was added later, because some things can't be done
with policy servers. 

As for greylisting, you could use postscreen's deep protocol tests
instead - those tests require that clients disconnect and come back
before they can send mail.

Wietse


simple greylisting by geoip? milter or policy server?

2016-06-13 Thread lists42
I am considering the installation of Greylisting with Postfix.

I want it only for one condition, to greylist mail originating from certain 
countries.

I use Postfix 3.1 with postscreen.

I am already using milters for dkim and dmarc and a policy server for spf.

So looking through the addons and some posts I came to 'milter-greylist'.

    milter-greylist postfix
     http://hcpnet.free.fr/milter-greylist

It is a milter so I think it can be used in Postfix.  And it has a very 
simple easy ability to greylist only for specific countries

    milter-greylist+GeoIP
     http://milter-greylist.wikidot.com/geoip

But then I also read that that 'Policy delegation is now the preferred method 
for adding policies to Postfix.'

(1) For such only-geoip greylisting is the milter-greylist a recommendation 
?  I do not want any complicated rules, only the "greylist this country" 
ones.

(2) Is the postfix documentation saying there that we should use policy 
servers instead of milters?  I think I am maybe not fully clear with the 
terminology.


Re: postfix virtual domain walking

2016-06-13 Thread James B. Byrne

On Mon, June 13, 2016 16:42, Wietse Venema wrote:
> James B. Byrne:
>> These delivery names are only found in /etc/postfix/virtual.
>
> What about an email "address book" on a user machine?
>
>   Wietse
>

It is certainly a possibility. However, my difficulty with that
explanation is that:

1. Our users employ webmail (squirrelmail) so their address books are
maintained on a sealed server. There are no user accounts on it.  And
we run aide on it.  And we have fail2ban running.  And ssh is blocked
at the firewall.

2. Some of these addresses like .bugzilla and .redhat are only
used for bug reporting.  They would be found on the respective sites
but it seems to me doubtful that they would end up in a user address
book.

3.  If there is nothing that involves Postfix then something like what
you propose must be the case.  Or someone has gone to some lengths to
scan for these addresses using our domain name as a search term.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3



Re: postfix virtual domain walking

2016-06-13 Thread Wietse Venema
James B. Byrne:
> These delivery names are only found in /etc/postfix/virtual.

What about an email "address book" on a user machine?

Wietse


Re: postfix virtual domain walking

2016-06-13 Thread James B. Byrne

On Mon, June 13, 2016 14:25, Wietse Venema wrote:
> James B. Byrne:
>> However, the question arises as to how these local delivery
>> addresses
>> are being harvested?  Some of these are used very infrequently and
>> some of them have not been active for years.  It seems remarkable
>> that
>> addresses that are known to only be used for one purpose, say
>> bugzilla
>> or readhat network, are found in these attacks.
>
> The names may have been harvested from a compromised user machine.
>
>> Is there some way for remote unauthenticated users to query postfix
>> in
>> such a fashion as to effectively walk the virtual domain list for
>> local delivery addresses?  If so then what is it and how can it be
>> prevented.  Or should it?
>
> As far as I know, there is no SMTP command to 'list' a local database.
> That is, unless there is some kind of LDAP or SQL injection bug.
>
>   Wietse
>

These delivery names are only found in /etc/postfix/virtual. There is
no LDAP service or RDBMS involved whatsoever.  As far as I can tell
there would be no reason for any user machine to have them listed as
they exist solely to map incoming mail to specific imap subfolders. 
It may very well be that these people attempting to break in have gone
to the internet hunting for every revealed variant address.  But that
in itself seems even more worrying.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3



Re: postfix virtual domain walking

2016-06-13 Thread Wietse Venema
James B. Byrne:
> However, the question arises as to how these local delivery addresses
> are being harvested?  Some of these are used very infrequently and
> some of them have not been active for years.  It seems remarkable that
> addresses that are known to only be used for one purpose, say bugzilla
> or readhat network, are found in these attacks.

The names may have been harvested from a compromised user machine.

> Is there some way for remote unauthenticated users to query postfix in
> such a fashion as to effectively walk the virtual domain list for
> local delivery addresses?  If so then what is it and how can it be
> prevented.  Or should it?

As far as I know, there is no SMTP command to 'list' a local database.
That is, unless there is some kind of LDAP or SQL injection bug.

Wietse


postfix virtual domain walking

2016-06-13 Thread James B. Byrne

We are currently subjected to a persistent penetration attempt that
apparently is directed against our smtp authentication.  The user
names employed at the present time are all local address portions of a
single user's virtual domain which have no means of authentication. 
So the attack is futile in that sense.

However, the question arises as to how these local delivery addresses
are being harvested?  Some of these are used very infrequently and
some of them have not been active for years.  It seems remarkable that
addresses that are known to only be used for one purpose, say bugzilla
or readhat network, are found in these attacks.

Is there some way for remote unauthenticated users to query postfix in
such a fashion as to effectively walk the virtual domain list for
local delivery addresses?  If so then what is it and how can it be
prevented.  Or should it?

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3