Re: permit_mynetworks in smtpd_helo_restrictions

[pf]

p...@alt-ctrl-del.org wrote:

Hello postfix admins,
I have always placed all restrictions in smtpd_recipient_restrictions. 
Over the last few days, I have been experimenting with breaking the 
restrictions up into client, helo, sender, etc. I ran into something odd 
(to me), when permit_mynetworks is in smtpd_helo_restrictions.

.
I would think that having permit_mynetworks in smtpd_helo_restrictions, 
would be applied as "accept any helo, from hosts in mynetworks".
But it appears that permit_mynetworks is testing the helo string, 
against the list of IP's in $mynetworks (as strings), then allowing it 
to pass.

...
Is this the way it's supposed to behave? It seems wrong to me.




p...@alt-ctrl-del.org wrote:
Hold on...
That machine is running an experimental build of 2.6, from 2008. A quick 
test of my config on 2.7.1, appears to be working. I'll try some more 
testing.




I've moved my entire postfix-mysql config over to postfix 2.7.1. Using 
permit_mynetworks in smtpd_helo_restrictions appears to be working as I 
expect it to, in this version.


one more thing.
In my reading of SMTPD_ACCESS_README, it sounds like 
smtpd_client_restrictions are checked before smtpd_helo_restrictions. If I 
really wanted to be anal, should I put my check_helo_access in 
smtpd_client_restrictions rather than smtpd_helo_restrictions, to prevent 
unnecessary rbl lookups and such?

Re: permit_mynetworks in smtpd_helo_restrictions

[Wietse Venema]

p...@alt-ctrl-del.org:
> I take it that I am expected to bottom post here. But is it ok, if I crop 
> out parts of the original message (if it's long)?

Yes.

Wietse

Temporary rerouting to another postfix

[Robert Fitzpatrick]

The firewall at one of our locations is down and we are using a cheaper 
solution until it is replaced, which does not handle content filtering 
as well with calls to our db at another network like the old router did 
very well. So, I am trying to reroute all the mail destined for that 
Postfix gateway to another gateway on that other network. I commented 
out the transport_maps we use with ldap to determine destination for 
domains and content filtering, then setup relayhost. We do address 
verification for our own domains and would like to do that on the 1st 
gateway before it goes to the second. I found that if I do this, the 
second always gives deliverable status to unknown users because the 1st 
gateway is on a trusted network. If I don't trust the network, then I 
get verification in both places and the 1st gateway queue starts to back up.


Can address_verify_relayhost be setup to use ldap in some way? I get 
errors when trying to do just that. Because we use ldap to determine 
which domains are to be address verified. I tried to re-enable 
transport_maps, but that appears to be done before relayhost and the 
mail is then routed without content filtering. Can someone offer a 
solution to my temp issue?


Thanks, Robert

Re: Temporary rerouting to another postfix

[Noel Jones]

On 8/19/2010 9:16 AM, Robert Fitzpatrick wrote:

The firewall at one of our locations is down and we are using
a cheaper solution until it is replaced, which does not handle
content filtering as well with calls to our db at another
network like the old router did very well. So, I am trying to
reroute all the mail destined for that Postfix gateway to
another gateway on that other network. I commented out the
transport_maps we use with ldap to determine destination for
domains and content filtering, then setup relayhost. We do
address verification for our own domains and would like to do
that on the 1st gateway before it goes to the second. I found
that if I do this, the second always gives deliverable status
to unknown users because the 1st gateway is on a trusted
network. If I don't trust the network, then I get verification
in both places and the 1st gateway queue starts to back up.

Can address_verify_relayhost be setup to use ldap in some way?
I get errors when trying to do just that. Because we use ldap
to determine which domains are to be address verified. I tried
to re-enable transport_maps, but that appears to be done
before relayhost and the mail is then routed without content
filtering. Can someone offer a solution to my temp issue?

Thanks, Robert



http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing

http://www.postfix.org/postconf.5.html#address_verify_transport_maps


  -- Noel Jones

Re: Temporary rerouting to another postfix

[Simone Caruso]

 On 19/08/2010 16:16, Robert Fitzpatrick wrote:
The firewall at one of our locations is down and we are using a cheaper solution until it is replaced, which does not 
handle content filtering as well with calls to our db at another network like the old router did very well. So, I am 
trying to reroute all the mail destined for that Postfix gateway to another gateway on that other network. I commented 
out the transport_maps we use with ldap to determine destination for domains and content filtering, then setup 
relayhost. We do address verification for our own domains and would like to do that on the 1st gateway before it goes 
to the second. I found that if I do this, the second always gives deliverable status to unknown users because the 1st 
gateway is on a trusted network. 


Address verification is always done (i think), even when the client is trusted.
I solved a similar issue setting up a backend server with address verification 
disabled for smtpd:
-o receive_override_options=no_unknown_recipient_checks
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o my_networks=192.168.22.254


--
Simone Caruso
IT Consultant
+39 349 65 90 805
p.iva: 03045250838

Re: Temporary rerouting to another postfix

[Robert Fitzpatrick]

On 8/19/2010 11:03 AM, Noel Jones wrote:


http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing

http://www.postfix.org/postconf.5.html#address_verify_transport_maps


Yes, I read both of these, I guess I just can't figure out how to 
utilize these configuration options for a solution. Not sure where 
address_verify_transport_maps comes into play if I'm not using 
transport_maps :-/


Thanks, Robert

Re: Temporary rerouting to another postfix

[Noel Jones]

On 8/19/2010 10:10 AM, Robert Fitzpatrick wrote:

On 8/19/2010 11:03 AM, Noel Jones wrote:


http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing


http://www.postfix.org/postconf.5.html#address_verify_transport_maps



Yes, I read both of these, I guess I just can't figure out how
to utilize these configuration options for a solution. Not
sure where address_verify_transport_maps comes into play if
I'm not using transport_maps :-/

Thanks, Robert



From your vague description, I assumed you were using 
reject_unverified_recipient and wanted to control where the 
verification probes were sent, because the relayhost you're 
using now just answers OK to everyone.


If that's not a correct assumption, you'll probably need to 
provide a much clearer explanation to get any useful answers.


It might help to include "postconf -n" and log entries 
demonstrating the issue.




  -- Noel Jones

Re: Temporary rerouting to another postfix

[Robert Fitzpatrick]

On 8/19/2010 11:26 AM, Noel Jones wrote:

On 8/19/2010 10:10 AM, Robert Fitzpatrick wrote:

On 8/19/2010 11:03 AM, Noel Jones wrote:


http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing


http://www.postfix.org/postconf.5.html#address_verify_transport_maps



Yes, I read both of these, I guess I just can't figure out how
to utilize these configuration options for a solution. Not
sure where address_verify_transport_maps comes into play if
I'm not using transport_maps :-/

Thanks, Robert



 From your vague description, I assumed you were using
reject_unverified_recipient and wanted to control where the verification
probes were sent, because the relayhost you're using now just answers OK
to everyone.

If that's not a correct assumption, you'll probably need to provide a
much clearer explanation to get any useful answers.

It might help to include "postconf -n" and log entries demonstrating the
issue.



Thanks, no I am not using reject_unverified_recipient, I was using...

check_recipient_access ldap:/usr/local/etc/postfix/ldap/verification.cf

I now have it setup as shown below, but like you said, the relayhost is 
answering OK to everything, I assume because the 1st gateway is part of 
the cidr file...


check_client_access cidr:/usr/local/etc/postfix/relay_clients

I was hoping to do AV at the 1st gateway only and it use transports to 
determine where to send the probe, but if I use transport_maps (like the 
2nd gateway), then I must do content filtering and the cheap router 
can't handle the calls to the other network db like the old one did fine.


1st gateway:
mx2# postconf -n
address_verify_map = btree:/var/mta/verify
address_verify_negative_cache = no
address_verify_poll_count = 1
bounce_queue_lifetime = 1d
canonical_maps = ldap:/usr/local/etc/postfix/ldap/canonical.cf
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
html_directory = no
mail_name = WebTent ESMTP Postfix Internet Mail Exchange
mailbox_size_limit = 10240
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 1000s
message_size_limit = 5120
mynetworks = 127.0.0.0/8, 10.0.0.0/8
newaliases_path = /usr/local/bin/newaliases
readme_directory = no
relay_domains = ldap:/usr/local/etc/postfix/ldap/transport.cf
relayhost = mx1.webtent.net
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name USE OF THIS SERVER INDICATES 
THAT YOU HAVE READ AND AGREED TO OUR AUP.  UCE IS NOT ALLOWED.

smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_helo_restrictions = permit_mynetworks
smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, check_client_access 
cidr:/usr/local/etc/postfix/relay_clients, check_client_access 
ldap:/usr/local/etc/postfix/ldap/relay_clients.cf, check_client_access 
hash:/usr/local/etc/postfix/client_checks, reject_unauth_destination, 
reject_non_fqdn_sender, reject_non_fqdn_recipient, check_helo_access 
hash:/usr/local/etc/postfix/helo_checks, check_recipient_access 
pcre:/usr/local/etc/postfix/recipient_checks.pcre, reject_rbl_client 
zen.spamhaus.org, permit
smtpd_sender_restrictions = permit_mynetworks 
reject_unknown_sender_domain hash:/usr/local/etc/postfix/sender_access

unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550

2nd gateway, relayhost of 1st:
mx1# postconf -n
address_verify_map = btree:/var/mta/verify
address_verify_negative_cache = no
address_verify_poll_count = 1
alias_maps = hash:/usr/local/etc/postfix/aliases
bounce_queue_lifetime = 1d
broken_sasl_auth_clients = yes
canonical_maps = ldap:/usr/local/etc/postfix/ldap/canonical.cf
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/local/libexec/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
html_directory = no
mail_name = WebTent ESMTP Postfix Internet Mail Exchange
mail_owner = postfix
mailbox_size_limit = 10240
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 1000s
message_size_limit = 5120
mynetworks = 127.0.0.0/8, 10.0.0.0/8
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = ldap:/usr/local/etc/postfix/ldap/transport.cf
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP ${stress?(condition RED)}
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_error_sleep_time = ${stress?0}${stress:5}
smtpd_hard_error_limit = ${stress?1}${stress:20}
smtpd_helo_restrictions = permit_mynetworks
smtpd_recipient_restrictions = check_client_access 
cidr:/usr/local/etc/pos

Re: Temporary rerouting to another postfix

[Noel Jones]

On 8/19/2010 11:08 AM, Robert Fitzpatrick wrote:

On 8/19/2010 11:26 AM, Noel Jones wrote:

On 8/19/2010 10:10 AM, Robert Fitzpatrick wrote:

On 8/19/2010 11:03 AM, Noel Jones wrote:


http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing



http://www.postfix.org/postconf.5.html#address_verify_transport_maps




Yes, I read both of these, I guess I just can't figure out how
to utilize these configuration options for a solution. Not
sure where address_verify_transport_maps comes into play if
I'm not using transport_maps :-/

Thanks, Robert



From your vague description, I assumed you were using
reject_unverified_recipient and wanted to control where the
verification
probes were sent, because the relayhost you're using now
just answers OK
to everyone.

If that's not a correct assumption, you'll probably need to
provide a
much clearer explanation to get any useful answers.

It might help to include "postconf -n" and log entries
demonstrating the
issue.



Thanks, no I am not using reject_unverified_recipient, I was
using...

check_recipient_access
ldap:/usr/local/etc/postfix/ldap/verification.cf

I now have it setup as shown below, but like you said, the
relayhost is answering OK to everything, I assume because the
1st gateway is part of the cidr file...

check_client_access cidr:/usr/local/etc/postfix/relay_clients

I was hoping to do AV at the 1st gateway only and it use
transports to determine where to send the probe, but if I use
transport_maps (like the 2nd gateway), then I must do content
filtering and the cheap router can't handle the calls to the
other network db like the old one did fine.


Use address_verify_transport_maps in place of your 
transport_maps to control the routing of the probe.



  -- Noel Jones

Re: Temporary rerouting to another postfix

[Robert Fitzpatrick]

On 8/19/2010 12:52 PM, Noel Jones wrote:

Use address_verify_transport_maps in place of your transport_maps to
control the routing of the probe.



Ah, I'm just stupid then, I thought that didn't work unless you were 
using transport_maps in the first place, sorry. Thanks for clearing that up.

Re: Temporary rerouting to another postfix

[Robert Fitzpatrick]

On 8/19/2010 12:52 PM, Noel Jones wrote:

Use address_verify_transport_maps in place of your transport_maps to
control the routing of the probe.



Uhmm, I added address_verify_transport_maps, but it still is sending 
verifications to the relayhost:


mx2# postconf -n
address_verify_map = btree:/var/mta/verify
address_verify_negative_cache = no
address_verify_poll_count = 1
address_verify_transport_maps = 
ldap:/usr/local/etc/postfix/ldap/transport.cf

bounce_queue_lifetime = 1d
canonical_maps = ldap:/usr/local/etc/postfix/ldap/canonical.cf
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
html_directory = no
mail_name = WebTent ESMTP Postfix Internet Mail Exchange
mailbox_size_limit = 10240
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 1000s
message_size_limit = 5120
mynetworks = 127.0.0.0/8, 10.0.0.0/8
newaliases_path = /usr/local/bin/newaliases
readme_directory = no
relay_domains = ldap:/usr/local/etc/postfix/ldap/transport.cf
relayhost = mx1.webtent.net
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name USE OF THIS SERVER INDICATES 
THAT YOU HAVE READ AND AGREED TO OUR AUP.  UCE IS NOT ALLOWED.

smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_helo_restrictions = permit_mynetworks
smtpd_recipient_restrictions = permit_sasl_authenticated, 
permit_mynetworks, check_client_access 
cidr:/usr/local/etc/postfix/relay_clients, check_client_access 
ldap:/usr/local/etc/postfix/ldap/relay_clients.cf, check_client_access 
hash:/usr/local/etc/postfix/client_checks, reject_unauth_destination, 
reject_non_fqdn_sender, reject_non_fqdn_recipient, check_helo_access 
hash:/usr/local/etc/postfix/helo_checks, check_recipient_access 
pcre:/usr/local/etc/postfix/recipient_checks.pcre, reject_rbl_client 
zen.spamhaus.org, permit
smtpd_sender_restrictions = permit_mynetworks 
reject_unknown_sender_domain hash:/usr/local/etc/postfix/sender_access

unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550

postmap -q mrtampanorth.com 
ldap:/usr/local/etc/postfix/ldap/transport.cf  smtp:[64.90.10.204]


Aug 19 13:27:10 mx2 postfix/smtp[88103]: 9BD9A11417F: 
to=, relay=mx1.webtent.net[208.38.145.6]:25, 
delay=1.3, delays=0.88/0.07/0.2/0.11, dsn=4.1.1, status=deferred (host 
mx1.webtent.net[208.38.145.6] said: 450 4.1.1 
: Recipient address rejected: unverified 
address: Address verification in progress (in reply to RCPT TO command))


Thanks for any help, Robert

Re: None Unix accounts and NIS aliases

[Daniel Prieto]

On 8/18/2010 4:16 PM, Brian Evans - Postfix List wrote:

 On 8/18/2010 3:50 PM, Daniel Prieto wrote:

Brian,


On 8/18/2010 2:17 PM, Brian Evans - Postfix List wrote:

 On 8/18/2010 2:05 PM, Daniel Prieto wrote:

Hello,

I have moved from Sendmail to Postfix and eliminated Student email
accounts and kept staff accounts.
 I'm using 'virtual_alias_maps" to forward old student email address
to their other new email address that was given to me. When I send an
email to old stude... 
@mydomain.com 
email address it gets to his new
email address d... 
@gmail.com. 
However, if I use an alias,
"aliastest"  (from my NIS) where the stude... 
@mydomain.com 
is part of,

then his email is rejected as "unknown user". I can see from my logs
below that the using "postfix/smtp" gets forwarded and the other one
using "postfix/local" gets rejected.

 Could someone tell me why it's doing that and what I can do to fix
that? Thanks in advance.



Welcome to the list!
Unfortunately, you seem to have missed the important welcome message:
"TO REPORT A PROBLEM, PLEASE SEE 
http://www.postfix.org/DEBUG_README.html#mail";

Sorry, I missed that.


Does the *nix account "student1" exist?

No, it doesn't exist.


Since "mydomain.com" is listed in mydestination and the user does not 
exist, we see the expected behavior.


You are using virtual_alias_maps which does allows you to send to your 
"aliastest" user since it exists as the key.


Brian, thanks for helping me out but "aliastest" in not in my 
virtual_alias_maps "student1" is. "student1" is in the "aliastest" list 
among other users. What I don't understand is why Postfix see "student1" 
as unknown user when using "aliastest" even though it's working when 
sending directly to stude...@mydomain.com?


After the message is received, virtual_alias_maps are used for 
rewriting messages to it's destination by the cleanup(8) daemon.

References:
http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual
http://www.postfix.org/virtual.5.html

If you don't want bounces sent, then don't have bad addresses returned 
from virtual_alias_maps.


Brian
There should be more log data for a transaction.. use the id 
(93CF2BF107F below) to grep through the log

Here are the logs related to 93CF2BF107F:

/var/log/maillog:Aug 16 15:03:56 mail postfix/smtpd[31468]: 
93CF2BF107F: client=localhost.localdomain[127.0.0.1]
/var/log/maillog:Aug 16 15:03:56 mail postfix/cleanup[31195]: 
93CF2BF107F: 
message-id= 

/var/log/maillog:Aug 16 15:03:56 mail postfix/qmgr[26402]: 
93CF2BF107F: from=, size=2799, nrcpt=1 (queue active)
/var/log/maillog:Aug 16 15:03:56 mail postfix/smtp[31783]: 
380BBBF107E: to=, 
relay=127.0.0.1[127.0.0.1]:10025, delay=0.45, delays=0.09/0/0/0.36, 
dsn=2.0.0, status=sent (250 OK, sent 4C698B9C_12641_34064_1 93CF2BF107F)
/var/log/maillog:Aug 16 15:03:56 mail postfix/local[31602]: 
93CF2BF107F: to=, 
orig_to=, relay=local, delay=0.06, 
delays=0.04/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: 
"student1")
/var/log/maillog:Aug 16 15:03:56 mail postfix/bounce[31800]: 
93CF2BF107F: sender non-delivery notification: A2AFBBF1086
/var/log/maillog:Aug 16 15:03:56 mail postfix/qmgr[26402]: 
93CF2BF107F: removed


At the bottom of this email is the output of 'postfinger'? Thanks for 
you help...




Aug 16 15:06:52 mail postfix/smtp[31783]: C8324BF107F:
to=@gmail.com>, 
orig_to=@mydomain.com>, 


relay=127.0.0.1[127.0.0.1]:10025, delay=0.43, delays=0.09/0/0/0.34,
dsn=2.0.0, status=sent (250 OK, sent 4C698C4B_12641_34075_1
2BAB2BF1082)

Aug 16 15:03:56 mail postfix/local[31602]: 93CF2BF107F:
to=@mydomain.com>, 
orig_to=@mydomain.com>, 


relay=local, delay=0.06, delays=0.04/0/0/0.01, dsn=5.1.1,
status=bounced (unknown user: "student1")

Daniel 

Re: None Unix accounts and NIS aliases

[Brian Evans - Postfix List]

 On 8/19/2010 2:21 PM, Daniel Prieto wrote:



On 8/18/2010 4:16 PM, Brian Evans - Postfix List wrote:

 On 8/18/2010 3:50 PM, Daniel Prieto wrote:

Brian,


On 8/18/2010 2:17 PM, Brian Evans - Postfix List wrote:

 On 8/18/2010 2:05 PM, Daniel Prieto wrote:

Hello,

I have moved from Sendmail to Postfix and eliminated Student email
accounts and kept staff accounts.
 I'm using 'virtual_alias_maps" to forward old student email address
to their other new email address that was given to me. When I send an
email to old stude... 
@mydomain.com 
email address it gets to his new
email address d... 
@gmail.com. 
However, if I use an alias,
"aliastest"  (from my NIS) where the stude... 
@mydomain.com 
is part of,

then his email is rejected as "unknown user". I can see from my logs
below that the using "postfix/smtp" gets forwarded and the other one
using "postfix/local" gets rejected.

 Could someone tell me why it's doing that and what I can do to fix
that? Thanks in advance.



Welcome to the list!
Unfortunately, you seem to have missed the important welcome message:
"TO REPORT A PROBLEM, PLEASE SEE 
http://www.postfix.org/DEBUG_README.html#mail";

Sorry, I missed that.


Does the *nix account "student1" exist?

No, it doesn't exist.


Since "mydomain.com" is listed in mydestination and the user does not 
exist, we see the expected behavior.


You are using virtual_alias_maps which does allows you to send to 
your "aliastest" user since it exists as the key.


Brian, thanks for helping me out but "aliastest" in not in my 
virtual_alias_maps "student1" is. "student1" is in the "aliastest" 
list among other users. What I don't understand is why Postfix see 
"student1" as unknown user when using "aliastest" even though it's 
working when sending directly to stude...@mydomain.com?


My comments came from your logs: " to=, 
orig_to="
This mail was sent to "aliast...@mydomain" and was rewritten to 
"stude...@mydomain.com".


Maybe you should explain where messages are being stored since you said 
that "student1" doesn't exist and all messages are being  sent to the 
local(8) delivery agent.  local(8) is responsible to deliver to *nix users.





After the message is received, virtual_alias_maps are used for 
rewriting messages to it's destination by the cleanup(8) daemon.

References:
http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual
http://www.postfix.org/virtual.5.html

If you don't want bounces sent, then don't have bad addresses 
returned from virtual_alias_maps.


Brian
There should be more log data for a transaction.. use the id 
(93CF2BF107F below) to grep through the log

Here are the logs related to 93CF2BF107F:

/var/log/maillog:Aug 16 15:03:56 mail postfix/smtpd[31468]: 
93CF2BF107F: client=localhost.localdomain[127.0.0.1]
/var/log/maillog:Aug 16 15:03:56 mail postfix/cleanup[31195]: 
93CF2BF107F: 
message-id= 

/var/log/maillog:Aug 16 15:03:56 mail postfix/qmgr[26402]: 
93CF2BF107F: from=, size=2799, nrcpt=1 (queue active)
/var/log/maillog:Aug 16 15:03:56 mail postfix/smtp[31783]: 
380BBBF107E: to=, 
relay=127.0.0.1[127.0.0.1]:10025, delay=0.45, delays=0.09/0/0/0.36, 
dsn=2.0.0, status=sent (250 OK, sent 4C698B9C_12641_34064_1 
93CF2BF107F)
/var/log/maillog:Aug 16 15:03:56 mail postfix/local[31602]: 
93CF2BF107F: to=, 
orig_to=, relay=local, delay=0.06, 
delays=0.04/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: 
"student1")
/var/log/maillog:Aug 16 15:03:56 mail postfix/bounce[31800]: 
93CF2BF107F: sender non-delivery notification: A2AFBBF1086
/var/log/maillog:Aug 16 15:03:56 mail postfix/qmgr[26402]: 
93CF2BF107F: removed


At the bottom of this email is the output of 'postfinger'? Thanks 
for you help...




Aug 16 15:06:52 mail postfix/smtp[31783]: C8324BF107F:
to=@gmail.com>, 
orig_to=@mydomain.com>, 


relay=127.0.0.1[127.0.0.1]:10025, delay=0.43, delays=0.09/0/0/0.34,
dsn=2.0.0, status=sent (250 OK, sent 4C698C4B_12641_34075_1
2BAB2BF1082)

Aug 16 15:03:56 mail postfix/local[31602]: 93CF2BF107F:
to=@mydomain.com>, 
orig_to=

How common is reverse DNS checking?

[D G Teed]

Out of all of the things we do to restrict spam,
the only one with a steady trickle of false positives is
the host lookup not passing reverse DNS check.

The only place I've seen which publicly talks about
the reverse DNS requirement is AOL.  A huge majority
of senders are correctly configured in DNS, as
attested by our rate of requiring a new whitelisted IP
roughly once per week, and knowing that up
to 800,000 messages per day per server fail the test
without upset to users.

Once in awhile, someone will make a little stink about
it and claim they have never run into the requirement
before "in seven years".  It would be nice to have a list
of organizations which do require reverse DNS check or
some similar fact to back up the sensibility of it all.

Any thoughts or comments out there on this?

--Donald

Re: How common is reverse DNS checking?

[pf]

From: D G Teed 
Subject: How common is reverse DNS checking?



Out of all of the things we do to restrict spam,

the only one with a steady trickle of false positives is
the host lookup not passing reverse DNS check.




reject_unknown_client_hostname = gives problems
reject_unknown_reverse_client_hostname = 0 complaints here

Re: How common is reverse DNS checking?

[Noel Jones]

On 8/19/2010 2:15 PM, p...@alt-ctrl-del.org wrote:

From: D G Teed Subject: How common is reverse DNS checking?



Out of all of the things we do to restrict spam,

the only one with a steady trickle of false positives is
the host lookup not passing reverse DNS check.




reject_unknown_client_hostname = gives problems
reject_unknown_reverse_client_hostname = 0 complaints here




Same here.  reject_unknown_client_hostname is too strict,  but 
reject_unknown_reverse_client_hostname rejects lots of obvious 
spambots without resorting to an RBL lookup.  The 
false-positive rate is close enough to zero that I would not 
consider removing this restriction.


  -- Noel Jones

Domain forwarding

[Ronan Lucio]

Hi All,

I need to re-install a new mail server.
So I have the actual server running on and ordered a new one where I'm
installing and configuring newer softwares.

It's done and I need to move all domains and it's accounts to the newer
server.
Once there are so many gigabytes to move, I'll need to move
domain-by-domain, the will take weeks to move it all.

My problem is the DNS propagation.
Our server are configure with a 2 hours TTL

So after I move a domain and it's accounts, the next 2 hours both servers
(old one and new one) will receive messages (due to DNS time propagation).

What I want to is configure the old server to relay mails sent to that moved
domain, to the new server.
How can I do that?

My server is configured to use Postfix + SMTP_AUTH + MySQL

I have tried:

1) to create redirect rows on the virtual_maps from 'u...@domain.tld' to
'u...@new.server'
didn't work: messages didn't arrive into the users account

2) set 'relayhost=new.server'
didn't work: after deleting domain.tld from the
'virtual_mailbox_domains' it raises 'Relay access denied' and doesn't relay
the message to the newer server.

Any tip/suggestion for that?

Thanks,
Ronan

Re: How common is reverse DNS checking?

[D G Teed]

Thanks for the responses and tip on reject_unknown_reverse_client_hostname

I've made the switch to that and it seems to catch many unmapped IPs.

I half suspected there was something less stringent I could go for,
and had not noticed that variant.  We had only reject_unknown_client
from older Postfix config (we're still on 2.4).

--Donald

Re: Domain forwarding

[Noel Jones]

On 8/19/2010 2:58 PM, Ronan Lucio wrote:

Hi All,

I need to re-install a new mail server.
So I have the actual server running on and ordered a new one
where I'm installing and configuring newer softwares.

It's done and I need to move all domains and it's accounts to
the newer server.
Once there are so many gigabytes to move, I'll need to move
domain-by-domain, the will take weeks to move it all.

My problem is the DNS propagation.
Our server are configure with a 2 hours TTL

So after I move a domain and it's accounts, the next 2 hours
both servers (old one and new one) will receive messages (due
to DNS time propagation).

What I want to is configure the old server to relay mails sent
to that moved domain, to the new server.
How can I do that?



Easy way:
Rather than forwarding mail, defer all mail for the moved 
domain.  When the sender retries, they will eventually get the 
new server.  This may delay some deliveries during the 
migration, but few people will notice.  You can minimize the 
delays by changing your DNS TTL to a shorter value; 10~30 
minutes is probably a good compromise.


This example config assumes the default 
smtpd_delay_reject=yes.  We do this in 
smtpd_sender_restrictions so that a mistake doesn't make you 
an open relay.

# main.cf
smtpd_sender_restrictions =
  check_recipient_access hash:/etc/postfix/moved_domains
  ... any exiting checks go below here ...


# moved domains
example.com   DEFER server maintenance
example.org   DEFER server maintenance



Hard way:
When postfix accepts mail for a domain but final delivery is 
on a different server, it's called a relay domain.
The domain name must be added to the relay_domains parameter, 
and valid recipients must be listed in relay_recipient_maps.
It's important that the domain name is removed from all other 
*_domains parameters so the domain doesn't belong to multiple 
address classes.

http://www.postfix.org/ADDRESS_CLASS_README.html

If postfix can't find the new MX for the domain using a normal 
DNS lookup, add a transport_maps entry pointing to the correct 
server.

# main.cf
transport_maps = hash:/etc/postfix/transport

# transport
example.com  relay:[10.1.10.100]

http://www.postfix.org/postconf.5.html#transport_maps
http://www.postfix.org/transport.5.html



  -- Noel Jones

Re: Temporary rerouting to another postfix

[Noel Jones]

On 8/19/2010 1:01 PM, Robert Fitzpatrick wrote:

On 8/19/2010 12:52 PM, Noel Jones wrote:

Use address_verify_transport_maps in place of your
transport_maps to
control the routing of the probe.



Uhmm, I added address_verify_transport_maps, but it still is
sending verifications to the relayhost:

mx2# postconf -n
address_verify_map = btree:/var/mta/verify
address_verify_negative_cache = no
address_verify_poll_count = 1
address_verify_transport_maps =
ldap:/usr/local/etc/postfix/ldap/transport.cf
bounce_queue_lifetime = 1d
canonical_maps = ldap:/usr/local/etc/postfix/ldap/canonical.cf
command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
delay_warning_time = 4h
disable_vrfy_command = yes
html_directory = no
mail_name = WebTent ESMTP Postfix Internet Mail Exchange
mailbox_size_limit = 10240
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 1000s
message_size_limit = 5120
mynetworks = 127.0.0.0/8, 10.0.0.0/8
newaliases_path = /usr/local/bin/newaliases
readme_directory = no
relay_domains = ldap:/usr/local/etc/postfix/ldap/transport.cf
relayhost = mx1.webtent.net
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
smtpd_banner = $myhostname ESMTP $mail_name USE OF THIS SERVER
INDICATES THAT YOU HAVE READ AND AGREED TO OUR AUP. UCE IS NOT
ALLOWED.
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_helo_restrictions = permit_mynetworks
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, check_client_access
cidr:/usr/local/etc/postfix/relay_clients, check_client_access
ldap:/usr/local/etc/postfix/ldap/relay_clients.cf,
check_client_access hash:/usr/local/etc/postfix/client_checks,
reject_unauth_destination, reject_non_fqdn_sender,
reject_non_fqdn_recipient, check_helo_access
hash:/usr/local/etc/postfix/helo_checks,
check_recipient_access
pcre:/usr/local/etc/postfix/recipient_checks.pcre,
reject_rbl_client zen.spamhaus.org, permit
smtpd_sender_restrictions = permit_mynetworks
reject_unknown_sender_domain
hash:/usr/local/etc/postfix/sender_access
unknown_local_recipient_reject_code = 550
unverified_recipient_reject_code = 550
unverified_sender_reject_code = 550

postmap -q mrtampanorth.com
ldap:/usr/local/etc/postfix/ldap/transport.cf smtp:[64.90.10.204]

Aug 19 13:27:10 mx2 postfix/smtp[88103]: 9BD9A11417F:
to=,
relay=mx1.webtent.net[208.38.145.6]:25, delay=1.3,
delays=0.88/0.07/0.2/0.11, dsn=4.1.1, status=deferred (host
mx1.webtent.net[208.38.145.6] said: 450 4.1.1
: Recipient address rejected:
unverified address: Address verification in progress (in reply
to RCPT TO command))

Thanks for any help, Robert



I don't see an error in your supplied config.  Did you reload 
postfix after the change?  That feature works as expected here.



Anyone else want to add something?


  -- Noel Jones

Re: Temporary rerouting to another postfix

[Noel Jones]

On 8/19/2010 3:40 PM, Noel Jones wrote:

On 8/19/2010 1:01 PM, Robert Fitzpatrick wrote:





Uhmm, I added address_verify_transport_maps, but it still is
sending verifications to the relayhost:




Aug 19 13:27:10 mx2 postfix/smtp[88103]: 9BD9A11417F:
to=,
relay=mx1.webtent.net[208.38.145.6]:25, delay=1.3,
delays=0.88/0.07/0.2/0.11, dsn=4.1.1, status=deferred (host
mx1.webtent.net[208.38.145.6] said: 450 4.1.1
: Recipient address rejected:
unverified address: Address verification in progress (in reply
to RCPT TO command))




No, verification probes will be status=deliverable or 
status=undeliverable.


In this case, the other end states that *it* is trying to 
verify the recipient address.





  -- Noel Jones

Re: None Unix accounts and NIS aliases

[Daniel Prieto]

On 8/19/2010 2:33 PM, Brian Evans - Postfix List wrote:

 On 8/19/2010 2:21 PM, Daniel Prieto wrote:



On 8/18/2010 4:16 PM, Brian Evans - Postfix List wrote:

 On 8/18/2010 3:50 PM, Daniel Prieto wrote:

Brian,


On 8/18/2010 2:17 PM, Brian Evans - Postfix List wrote:

 On 8/18/2010 2:05 PM, Daniel Prieto wrote:

Hello,

I have moved from Sendmail to Postfix and eliminated Student email
accounts and kept staff accounts.
 I'm using 'virtual_alias_maps" to forward old student email address
to their other new email address that was given to me. When I 
send an
email to old stude... 
@mydomain.com 
email address it gets to his new
email address d... 
@gmail.com. 
However, if I use an alias,
"aliastest"  (from my NIS) where the stude... 
@mydomain.com 
is part of,

then his email is rejected as "unknown user". I can see from my logs
below that the using "postfix/smtp" gets forwarded and the other one
using "postfix/local" gets rejected.

 Could someone tell me why it's doing that and what I can do to fix
that? Thanks in advance.



Welcome to the list!
Unfortunately, you seem to have missed the important welcome message:
"TO REPORT A PROBLEM, PLEASE SEE 
http://www.postfix.org/DEBUG_README.html#mail";

Sorry, I missed that.


Does the *nix account "student1" exist?

No, it doesn't exist.


Since "mydomain.com" is listed in mydestination and the user does 
not exist, we see the expected behavior.


You are using virtual_alias_maps which does allows you to send to 
your "aliastest" user since it exists as the key.


Brian, thanks for helping me out but "aliastest" in not in my 
virtual_alias_maps "student1" is. "student1" is in the "aliastest" 
list among other users. What I don't understand is why Postfix see 
"student1" as unknown user when using "aliastest" even though it's 
working when sending directly to stude...@mydomain.com?


My comments came from your logs: " to=, 
orig_to="
This mail was sent to "aliast...@mydomain" and was rewritten to 
"stude...@mydomain.com".


Maybe you should explain where messages are being stored since you 
said that "student1" doesn't exist and all messages are being  sent to 
the local(8) delivery agent.  local(8) is responsible to deliver to 
*nix users.


Sorry for the confusion...  "student1" is not a local unix user so I 
have in my virtual file an entry that redirects emails sent to 
"stude...@mydomain.com" to "stude...@whateverdomain.com". (this works). 
I have "stude...@mydomain.com" in an "aliastest" list (NIS aliases) and 
when an email is sent to "aliast...@mydomain.com"  that gets the error 
returned as unknown user: "stundent1".
After the message is received, virtual_alias_maps are used for rewriting 
messages to it's destination by the cleanup(8) daemon.



References:
http://www.postfix.org/ADDRESS_REWRITING_README.html#virtual
http://www.postfix.org/virtual.5.html

If you don't want bounces sent, then don't have bad addresses 
returned from virtual_alias_maps.


Brian
There should be more log data for a transaction.. use the id 
(93CF2BF107F below) to grep through the log

Here are the logs related to 93CF2BF107F:

/var/log/maillog:Aug 16 15:03:56 mail postfix/smtpd[31468]: 
93CF2BF107F: client=localhost.localdomain[127.0.0.1]
/var/log/maillog:Aug 16 15:03:56 mail postfix/cleanup[31195]: 
93CF2BF107F: 
message-id= 

/var/log/maillog:Aug 16 15:03:56 mail postfix/qmgr[26402]: 
93CF2BF107F: from=, size=2799, nrcpt=1 (queue active)
/var/log/maillog:Aug 16 15:03:56 mail postfix/smtp[31783]: 
380BBBF107E: to=, 
relay=127.0.0.1[127.0.0.1]:10025, delay=0.45, delays=0.09/0/0/0.36, 
dsn=2.0.0, status=sent (250 OK, sent 4C698B9C_12641_34064_1 
93CF2BF107F)
/var/log/maillog:Aug 16 15:03:56 mail postfix/local[31602]: 
93CF2BF107F: to=, 
orig_to=, relay=local, delay=0.06, 
delays=0.04/0/0/0.01, dsn=5.1.1, status=bounced (unknown user: 
"student1")
/var/log/maillog:Aug 16 15:03:56 mail postfix/bounce[31800]: 
93CF2BF107F: sender non-delivery notification: A2AFBBF1086
/var/log/maillog:Aug 16 15:03:56 mail postfix/qmgr[26402]: 
93CF2BF107F: removed


At the bottom of this email is the output of 'postfinger'? Thanks 
for you help...




Aug 16 15:06:52 mail postfix/smtp[31783]: C8324BF107F:
to=@gmail.com>, 
orig_to=@mydomain.com>, 


relay=127.0.0.1[127.

greet_pause feature with postfix?

[Morten P.D. Stevens]

Hi,

is there a greet_pause feature in postfix comparable with the sendmail 
greet_pause feature?

For example: FEATURE(`greet_pause',5000)

Thank you.

Best regards,

Morten

Re: greet_pause feature with postfix?

[Wietse Venema]

Morten P.D. Stevens:
> Hi,
> 
> is there a greet_pause feature in postfix comparable with the sendmail 
> greet_pause feature?
> 
> For example: FEATURE(`greet_pause',5000)

If you have a zombie problem, then delaying every SMTP session
is a terrible idea.

The expirimental Postfix release has a better solution called
postscreen that whitelists well-behaved clients for 24 hours.

Wietse

Re: How common is reverse DNS checking?

[Robert Fournerat]

Quoting Noel Jones :


On 8/19/2010 2:15 PM, p...@alt-ctrl-del.org wrote:

From: D G Teed Subject: How common is reverse DNS checking?



Out of all of the things we do to restrict spam,

the only one with a steady trickle of false positives is
the host lookup not passing reverse DNS check.




reject_unknown_client_hostname = gives problems
reject_unknown_reverse_client_hostname = 0 complaints here




Same here.  reject_unknown_client_hostname is too strict,  but
reject_unknown_reverse_client_hostname rejects lots of obvious spambots
without resorting to an RBL lookup.  The false-positive rate is close
enough to zero that I would not consider removing this restriction.

  -- Noel Jones


Call me a BOFH, but I have no sympathy for mail servers
that do not pass the FCRDNS test.

Robert




This message was sent using IMP, the Internet Messaging Program.

RE: greet_pause feature with postfix?

[Morten P.D. Stevens]

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Wietse Venema
> Sent: Thursday, August 19, 2010 11:30 PM
> To: Morten P.D. Stevens
> Cc: Postfix users
> Subject: Re: greet_pause feature with postfix?
> 
> Morten P.D. Stevens:
> > Hi,
> >
> > is there a greet_pause feature in postfix comparable with the
> sendmail greet_pause feature?
> >
> > For example: FEATURE(`greet_pause',5000)
> 
> If you have a zombie problem, then delaying every SMTP session
> is a terrible idea.
> 
> The expirimental Postfix release has a better solution called
> postscreen that whitelists well-behaved clients for 24 hours.
> 
>   Wietse

Hi Wietse,

That sounds great. (http://www.postfix.org/postscreen.pdf)

Is there a release schedule, when postfix 2.8 with the new postscreen feature 
will be available?

Best regards,

Morten

Re: greet_pause feature with postfix?

[Wietse Venema]

Morten P.D. Stevens:
> is there a greet_pause feature in postfix comparable with the
> sendmail greet_pause feature?
>
> For example: FEATURE(`greet_pause',5000)

Wietse:
> If you have a zombie problem, then delaying every SMTP session
> is a terrible idea.
> 
> The expirimental Postfix release has a better solution called
> postscreen that whitelists well-behaved clients for 24 hours.

Morten P.D. Stevens:
> That sounds great. (http://www.postfix.org/postscreen.pdf)
> 
> Is there a release schedule, when postfix 2.8 with the new postscreen
> feature will be available?

postscreen works in its current state, but it misses some configuration
options, and it does not yet have support to log details about rejected
mail such as sender, recipient, etc.

postscreen will become part of the stable release once I am confident
that there will be no incompatible changes.

Wietse

Can we block some users from the same domain to send mail to particular group in that domain

[somashekar M C]

I am using postfix with amavisd-new and i am new to mail server.
I don't know i am asking a silly question or not... but pls help.
Is there a way to block some users from the same domain to send mails to
particular group with in that domain.
Example: I don't want a...@example.com, b...@example.com send mails to
gro...@example.com, but I want
c...@example.com or d...@example.com..etc can be able to send mails to
gro...@example.com. Is it possible?
If possible let me know how to do that.