Re: Problem with relaying denied error
Mikael Bak put forth on 10/25/2010 1:18 AM: > Stan Hoeppner wrote: > [snip] >> Yes. I would suggest configuring a new smtpd listener for this. Most >> people use the master.cf default TCP 587 listener daemon to accept >> submitted mail. MUA clients will need to be configured accordingly. >> Apparently your current configuration relays all mail to the Domino >> server after it is piped through various anti spam processes, which I >> believe is why you're getting the error. >> >> I believe what you need is to enable 587 in master.cf, and eliminate all >> of the A/S junk for submitted mail, something like: >> >> 587 inet n - n - - smtpd >> -o smtpd_enforce_tls=yes >> -o smtpd_sasl_auth_enable=yes >> -o content_filter= >> -o header_checks= >> -o smtpd_recipient_restrictions=permit_mynetworks,reject >> > [snip] > > Hi, > > Instead of "permit_mynetworks" I'd suggest "permit_sasl_authenticated" > on the above line. The submission service is not very often used without > authentication. > > Mikael Good catch Mikael. I had intended to add it after the copy/paste operation but apparently forgot to... -- Stan
Re: Fwd: Problem with relaying denied error
Rich put forth on 10/25/2010 1:23 AM: >> 587 inet n - n - - smtpd >>-o smtpd_enforce_tls=yes >>-o smtpd_sasl_auth_enable=yes >>-o content_filter= >>-o header_checks= >>-o smtpd_recipient_restrictions=permit_sasl_authenticaed,reject >> >> And it would probably be very helpful if we could see the contents of: >> >> transport_maps = hash:/etc/postfix/keytrans >> > I have this line in the keytrans > domain.com smtp:[10.0.0.100] > I take this as saying transfer any mail for the domain domain.com to the > smtp port on the server 10.0.0.100 I think that transport map should be ok. Implement the 587 smtpd in master.cf as shown above (I corrected the recipient restrictions per Mikael's reminder) and have your client MUA submit to TCP 587, and you should be good to go. If not, let us know. It appears your content filters are what are tripping you up here. Using a separate submission smtpd which bypasses the content filters should fix the problem. -- Stan
Re: Fwd: Problem with relaying denied error
Rich wrote: > > Hi, > > Instead of "permit_mynetworks" I'd suggest "permit_sasl_authenticated" > on the above line. The submission service is not very often used without > authentication. > > Mike are you saying remove "permit_mynetworks"? > Yes, I do not see any reason to have it on the submission service. Local services on localhost (and mynetworks) can still use 25/tcp. Submission is best used dedicated for authenticated users. HTH, Mikael
qty hold: logged does.not.equal qty hold queue ?
I'm testing a new filter, so I HOLD matching messages, then inspect them to either release or delete them. egrep -ic "hold: " /var/log/maillog 298 but in mailq: mailq | mailq-oneline.pl | egrep -ic "! " 35 cross checking: find /var/spool/postfix/hold -type f | wc -l 35 In case I forgot I cleaned the queue: egrep -ic "postsuper.*removed" /var/log/maillog 3 Why the 250+ diff between HOLD: log lines and hold queue files? Len
Re: NOQUEUE Relay Access denied
On 10/25/2010 07:14 AM, t...@diogunix.com wrote: Noel, thanks a lot for your help. Just to precise my need for information: > 554 5.7.1 > : Relay access denied; This is the response postfix sent to the remote client. The SMTP response is 554 (a permanent error) with an extended code of 5.7.1, and a text description of what was rejected (the recipient address) and why (relay access denied). Is the Email address at exactly that place always (by definition of the logline format) the recipients Email address ? No, it is the recipient address that was the reason for the relay denied, because of the part you snipped before it, as Noel said: > reject: RCPT Request was rejected during the RCPT stage of the SMTP conversation. Hence, it's the recipient address. Relaying may be denied for any reason. -- J.
Re: qty hold: logged does.not.equal qty hold queue ?
On 10/25/2010 4:28 AM, Len Conrad wrote: I'm testing a new filter, so I HOLD matching messages, then inspect them to either release or delete them. egrep -ic "hold: " /var/log/maillog 298 but in mailq: mailq | mailq-oneline.pl | egrep -ic "! " 35 cross checking: find /var/spool/postfix/hold -type f | wc -l 35 In case I forgot I cleaned the queue: egrep -ic "postsuper.*removed" /var/log/maillog 3 Why the 250+ diff between HOLD: log lines and hold queue files? Len Several reasons come to mind... Mail can trigger a HOLD rule but be rejected by a later rule. If you have multiple HOLD rules they may each create their own log entry. A recipient rule that triggers HOLD will log for each recipient of a multi-recipient message, but will only result in one message in the hold queue. -- Noel Jones
Re: qty hold: logged does.not.equal qty hold queue ?
Len Conrad:
>
> I'm testing a new filter, so I HOLD matching messages, then inspect them to
> either release or delete them.
>
> egrep -ic "hold: " /var/log/maillog
> 298
You have multiple logfile records per queue file?
grep ' hold:' /var/log/maillog | awk '{print $6}' | sort -u | wc -l
(this would count all the NOQUEUE: records as one, BTW).
Wietse
postfix in an IPv6 network
Hi listers [r...@mailhost ~]# rpm -q postfix postfix-2.5.6-3.fc11.i586 [r...@mailhost ~]# [r...@mailhost ~]# postconf -n alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases anvil_rate_time_unit = 60s command_directory = /usr/sbin config_directory = /etc/postfix content_filter = daemon_directory = /usr/libexec/postfix data_directory = /data/postfix/cache debug_peer_level = 2 defer_transports = disable_dns_lookups = no html_directory = no inet_interfaces = all inet_protocols = all local_recipient_maps = proxy:ldap:/etc/postfix/ldap-alias.cf mail_owner = postfix mailbox_command = mailbox_transport = mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root mydestination = localhost.$mydomain mydomain = $myhostname myhostname = mailhost.mydomain.com mynetworks = 192.168.97.0/24, aaa.bbb.206.128/27, [2002::::]/64 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /data/postfix/queues readme_directory = /usr/share/doc/postfix-2.5.6/README_FILES relay_domains = permit_sasl_authenticated, permit_mynetworks relayhost = sample_directory = /usr/share/doc/postfix-2.5.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_client_connection_count_limit = 5 smtpd_client_connection_rate_limit = 22 smtpd_client_event_limit_exceptions = $mynetworks smtpd_client_recipient_rate_limit = 100 smtpd_client_restrictions = permit_sasl_authenticated, hash:/etc/postfix/whitelist, hash:/etc/postfix/access smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_checks, reject_invalid_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,reject_unauth_destination, check_recipient_access hash:/etc/postfix/check_recipients, check_recipient_access hash:/etc/postfix/access, reject_rbl_client mail-abuse.org,reject_rbl_client sbl-xbl.spamhaus.org,reject_rbl_client blackholes.easynet.nl, reject_rbl_client cbl.abuseat.org,reject_rhsbl_client mail-abuse.org,reject_rhsbl_client sbl-xbl.spamhaus.org, reject_rhsbl_client blackholes.easynet.nl,reject_rhsbl_client cbl.abuseat.org check_recipient_access ldap:/etc/postfix/ldap-spamfilter.cf,permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = postfix smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated,reject_unknown_sender_domain, hash:/etc/postfix/whitelist,check_sender_access hash:/etc/postfix/access,reject_rhsbl_sender dsn.rfc-ignorant.org strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-alias.cf virtual_gid_maps = static:89 virtual_mailbox_base = /data/postfix/maildrop/ virtual_mailbox_domains = proxy:ldap:/etc/postfix/ldap-domain.cf virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-mailbox.cf virtual_minimum_uid = 51 virtual_transport = virtual virtual_uid_maps = static:89 [r...@mailhost ~]# 1. Problem: format of IPv6 address in mynetworks After many trials, I have found out that the ipv6 Address in the mynetworks attribute must have a double semicolon at the end, otherwise the smtpd server throttles: Oct 25 12:40:10 mailhost postfix/smtpd[5019]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:40:10 mailhost postfix/smtpd[5019]: fatal: bad net/mask pattern: "2002:::/64" Oct 25 12:40:11 mailhost postfix/master[5013]: warning: process /usr/libexec/postfix/smtpd pid 5019 exit status 1 Oct 25 12:40:11 mailhost postfix/master[5013]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling 2. Problem: permit_mynetworks with IPv6 addresses does not work But after having found out and changed that, postfix all the same did not accept an unauthorized connection via IPv6, even if I had specified for relay_domains permit_mynetworks Oct 25 12:53:07 mailhost postfix/smtpd[5298]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:53:08 mailhost postfix/smtpd[5298]: NOQUEUE: reject: RCPT from myclient.mydomain.com[2002:::1::21]: 554 5.7.1 : Relay access denied; from= to= proto=ESMTP helo= Oct 25 12:53:37 mailhost postfix/smtpd[5298]: disconnect from myclient.mydomain.com[2002:::1::21] Can anybody comment on that? Thanks for your attention myuser
Re: NOQUEUE Relay Access denied
On 10/25/2010 12:14 AM, t...@diogunix.com wrote: Noel, thanks a lot for your help. Just to precise my need for information: > 554 5.7.1 > : Relay access denied; This is the response postfix sent to the remote client. The SMTP response is 554 (a permanent error) with an extended code of 5.7.1, and a text description of what was rejected (the recipient address) and why (relay access denied). Is the Email address at exactly that place always (by definition of the logline format) the recipients Email address ? Or may there be placed any text information (i.e. in some cases the senders address ) ? The question is just, how and as what to interpret the information at that part of the logline. In the specific case of "Relay access denied" it will always be the recipient address, but there are other reasons for mail to be rejected. That section of the log line shows "what" was rejected along with a brief text description/reason. The "what" can be any part of the SMTP envelope; client, HELO, sender, recipient, or in the case of header/body checks, the text that matched the rule. -- Noel Jones We are just struggling to find out if there's a certain problem with Thunderbird (but almost probably, just the mail user messed up his SMTP configuration ffor his mail account). This is most certainly a user configuration error.
Re: postfix in an IPv6 network
Zitat von postfix : Hi listers [r...@mailhost ~]# rpm -q postfix postfix-2.5.6-3.fc11.i586 [r...@mailhost ~]# [r...@mailhost ~]# postconf -n alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases anvil_rate_time_unit = 60s command_directory = /usr/sbin config_directory = /etc/postfix content_filter = daemon_directory = /usr/libexec/postfix data_directory = /data/postfix/cache debug_peer_level = 2 defer_transports = disable_dns_lookups = no html_directory = no inet_interfaces = all inet_protocols = all local_recipient_maps = proxy:ldap:/etc/postfix/ldap-alias.cf mail_owner = postfix mailbox_command = mailbox_transport = mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root mydestination = localhost.$mydomain mydomain = $myhostname myhostname = mailhost.mydomain.com mynetworks = 192.168.97.0/24, aaa.bbb.206.128/27, [2002::::]/64 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /data/postfix/queues readme_directory = /usr/share/doc/postfix-2.5.6/README_FILES relay_domains = permit_sasl_authenticated, permit_mynetworks relayhost = sample_directory = /usr/share/doc/postfix-2.5.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_client_connection_count_limit = 5 smtpd_client_connection_rate_limit = 22 smtpd_client_event_limit_exceptions = $mynetworks smtpd_client_recipient_rate_limit = 100 smtpd_client_restrictions = permit_sasl_authenticated, hash:/etc/postfix/whitelist, hash:/etc/postfix/access smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_checks, reject_invalid_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated,reject_unauth_destination, check_recipient_access hash:/etc/postfix/check_recipients, check_recipient_access hash:/etc/postfix/access, reject_rbl_client mail-abuse.org,reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client cbl.abuseat.org,reject_rhsbl_client mail-abuse.org, reject_rhsbl_client sbl-xbl.spamhaus.org, reject_rhsbl_client blackholes.easynet.nl,reject_rhsbl_client cbl.abuseat.org check_recipient_access ldap:/etc/postfix/ldap-spamfilter.cf, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = postfix smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated,reject_unknown_sender_domain, hash:/etc/postfix/whitelist,check_sender_access hash:/etc/postfix/access,reject_rhsbl_sender dsn.rfc-ignorant.org strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-alias.cf virtual_gid_maps = static:89 virtual_mailbox_base = /data/postfix/maildrop/ virtual_mailbox_domains = proxy:ldap:/etc/postfix/ldap-domain.cf virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-mailbox.cf virtual_minimum_uid = 51 virtual_transport = virtual virtual_uid_maps = static:89 [r...@mailhost ~]# 1. Problem: format of IPv6 address in mynetworks After many trials, I have found out that the ipv6 Address in the mynetworks attribute must have a double semicolon at the end, otherwise the smtpd server throttles: Oct 25 12:40:10 mailhost postfix/smtpd[5019]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:40:10 mailhost postfix/smtpd[5019]: fatal: bad net/mask pattern: "2002:::/64" As far as i remember you must specify the whole network address + präfix so the net/mask is indeed wrong. 2. Problem: permit_mynetworks with IPv6 addresses does not work But after having found out and changed that, postfix all the same did not accept an unauthorized connection via IPv6, even if I had specified for relay_domains permit_mynetworks Oct 25 12:53:07 mailhost postfix/smtpd[5298]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:53:08 mailhost postfix/smtpd[5298]: NOQUEUE: reject: RCPT from myclient.mydomain.com[2002:::1::21]: 554 5.7.1 The address 2002:::1::21 is not within 2002::::/64 as far as i can tell. You should use 2002:::1::/64 instead in mynetworks. The :: means all zero if memory serves me right. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: NOQUEUE Relay Access denied
On 10/25/2010 5:22 AM, Jeroen Geilman wrote: On 10/25/2010 07:14 AM, t...@diogunix.com wrote: Noel, thanks a lot for your help. Just to precise my need for information: > 554 5.7.1 > : Relay access denied; This is the response postfix sent to the remote client. The SMTP response is 554 (a permanent error) with an extended code of 5.7.1, and a text description of what was rejected (the recipient address) and why (relay access denied). Is the Email address at exactly that place always (by definition of the logline format) the recipients Email address ? No, it is the recipient address that was the reason for the relay denied, because of the part you snipped before it, as Noel said: > reject: RCPT Request was rejected during the RCPT stage of the SMTP conversation. Hence, it's the recipient address. No, RCPT is just the stage of the conversation. With the default "smtpd_delay_reject = yes" all envelope-based rejects will be during RCPT. The log will indicate what was rejected and why. Relaying may be denied for any reason. In the case of "Relay access denied" it will always be the recipient address. -- Noel Jones
Re: postfix in an IPv6 network
Hi Andreas I have tried 2002:::1::/48, but then, I got the following error message from the server: Oct 25 12:51:17 mailhost postfix/smtpd[5229]: fatal: non-null host address bits in "2002:::1::/48", perhaps you should use "2002::::/48" instead And again, smtpd went throttling. myuser On 2010-10-25 13:40, lst_ho...@kwsoft.de wrote: Zitat von postfix : Hi listers [r...@mailhost ~]# rpm -q postfix postfix-2.5.6-3.fc11.i586 [r...@mailhost ~]# [r...@mailhost ~]# postconf -n alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases anvil_rate_time_unit = 60s command_directory = /usr/sbin config_directory = /etc/postfix content_filter = daemon_directory = /usr/libexec/postfix data_directory = /data/postfix/cache debug_peer_level = 2 defer_transports = disable_dns_lookups = no html_directory = no inet_interfaces = all inet_protocols = all local_recipient_maps = proxy:ldap:/etc/postfix/ldap-alias.cf mail_owner = postfix mailbox_command = mailbox_transport = mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = masquerade_exceptions = root mydestination = localhost.$mydomain mydomain = $myhostname myhostname = mailhost.mydomain.com mynetworks = 192.168.97.0/24, aaa.bbb.206.128/27, [2002::::]/64 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /data/postfix/queues readme_directory = /usr/share/doc/postfix-2.5.6/README_FILES relay_domains = permit_sasl_authenticated, permit_mynetworks relayhost = sample_directory = /usr/share/doc/postfix-2.5.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtpd_client_connection_count_limit = 5 smtpd_client_connection_rate_limit = 22 smtpd_client_event_limit_exceptions = $mynetworks smtpd_client_recipient_rate_limit = 100 smtpd_client_restrictions = permit_sasl_authenticated, hash:/etc/postfix/whitelist, hash:/etc/postfix/access smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, check_helo_access hash:/etc/postfix/helo_checks, reject_invalid_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access hash:/etc/postfix/check_recipients, check_recipient_access hash:/etc/postfix/access, reject_rbl_client mail-abuse.org, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client blackholes.easynet.nl, reject_rbl_client cbl.abuseat.org, reject_rhsbl_client mail-abuse.org, reject_rhsbl_client sbl-xbl.spamhaus.org, reject_rhsbl_client blackholes.easynet.nl, reject_rhsbl_client cbl.abuseat.org check_recipient_access ldap:/etc/postfix/ldap-spamfilter.cf, permit smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = postfix smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_sender_domain, hash:/etc/postfix/whitelist, check_sender_access hash:/etc/postfix/access, reject_rhsbl_sender dsn.rfc-ignorant.org strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 virtual_alias_maps = proxy:ldap:/etc/postfix/ldap-alias.cf virtual_gid_maps = static:89 virtual_mailbox_base = /data/postfix/maildrop/ virtual_mailbox_domains = proxy:ldap:/etc/postfix/ldap-domain.cf virtual_mailbox_maps = proxy:ldap:/etc/postfix/ldap-mailbox.cf virtual_minimum_uid = 51 virtual_transport = virtual virtual_uid_maps = static:89 [r...@mailhost ~]# 1. Problem: format of IPv6 address in mynetworks After many trials, I have found out that the ipv6 Address in the mynetworks attribute must have a double semicolon at the end, otherwise the smtpd server throttles: Oct 25 12:40:10 mailhost postfix/smtpd[5019]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:40:10 mailhost postfix/smtpd[5019]: fatal: bad net/mask pattern: "2002:::/64" As far as i remember you must specify the whole network address + präfix so the net/mask is indeed wrong. 2. Problem: permit_mynetworks with IPv6 addresses does not work But after having found out and changed that, postfix all the same did not accept an unauthorized connection via IPv6, even if I had specified for relay_domains permit_mynetworks Oct 25 12:53:07 mailhost postfix/smtpd[5298]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:53:08 mailhost postfix/smtpd[5298]: NOQUEUE: reject: RCPT from myclient.mydomain.com[2002:::1::21]: 554 5.7.1 The address 2002:::1::21 is not within 2002::::/64 as far as i can tell. You should use 2002:::1::/64 instead in mynetworks. The :: means all zero if memory serves me right. Regards Andreas
Re: postfix in an IPv6 network
Zitat von postfix : Hi Andreas I have tried 2002:::1::/48, but then, I got the following error message from the server: Oct 25 12:51:17 mailhost postfix/smtpd[5229]: fatal: non-null host address bits in "2002:::1::/48", perhaps you should use "2002::::/48" instead The mynetwork should be 2002:::1::/64 i suspect because /64 is half of the eight IPv6 blocks so the first four should be the network, no?? Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: postfix in an IPv6 network
>>> 1. Problem: format of IPv6 address in mynetworks >>> >>> After many trials, I have found out that the ipv6 Address in the >>> mynetworks attribute must have a double semicolon at the end, >>> otherwise the smtpd server throttles: >>> >>> Oct 25 12:40:10 mailhost postfix/smtpd[5019]: connect from >>> myclient.mydomain.com[2002:::1::21] >>> Oct 25 12:40:10 mailhost postfix/smtpd[5019]: fatal: bad net/mask >>> pattern: "2002:::/64" >> I can not say much about it, but maybe you want to lool lat my settings and compare them: inet_protocols = ipv4, ipv6 inet_interfaces = 78.46.253.227, 2A01:4F8:61:8222:0:0:0:50 smtp_bind_address6 = 2A01:4F8:61:8222:0:0:0:50 mynetworks = 127.0.0.0/8, 10.1.0.0/16, [::1]/128, [2a01:4f8:61:8222::]/64 These settings work for me. So maybe it gives you an idea. Regards Christian --- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com PGP.sig Description: Signierter Teil der Nachricht
Re: NOQUEUE Relay Access denied
On 10/25/2010 01:46 PM, Noel Jones wrote: On 10/25/2010 5:22 AM, Jeroen Geilman wrote: On 10/25/2010 07:14 AM, t...@diogunix.com wrote: Noel, thanks a lot for your help. Just to precise my need for information: > 554 5.7.1 > : Relay access denied; This is the response postfix sent to the remote client. The SMTP response is 554 (a permanent error) with an extended code of 5.7.1, and a text description of what was rejected (the recipient address) and why (relay access denied). Is the Email address at exactly that place always (by definition of the logline format) the recipients Email address ? No, it is the recipient address that was the reason for the relay denied, because of the part you snipped before it, as Noel said: > reject: RCPT Request was rejected during the RCPT stage of the SMTP conversation. Hence, it's the recipient address. No, RCPT is just the stage of the conversation. With the default "smtpd_delay_reject = yes" all envelope-based rejects will be during RCPT. The log will indicate what was rejected and why. Drat, of course. In his case, as you said above, it's actually the presence of a recipient address that indicates why it was rejected. -- J.
Re: postfix in an IPv6 network
Hi Andreas and Christian that has helped, now relaying without authenticatin works: mynetworks = 192.168.97.0/24, aaa.bbb.206.128/27, [2002:::1::]/64 is the clue. thank you both very much. myuser On 2010-10-25 14:03, Christian Roessner wrote: 1. Problem: format of IPv6 address in mynetworks After many trials, I have found out that the ipv6 Address in the mynetworks attribute must have a double semicolon at the end, otherwise the smtpd server throttles: Oct 25 12:40:10 mailhost postfix/smtpd[5019]: connect from myclient.mydomain.com[2002:::1::21] Oct 25 12:40:10 mailhost postfix/smtpd[5019]: fatal: bad net/mask pattern: "2002:::/64" I can not say much about it, but maybe you want to lool lat my settings and compare them: inet_protocols = ipv4, ipv6 inet_interfaces = 78.46.253.227, 2A01:4F8:61:8222:0:0:0:50 smtp_bind_address6 = 2A01:4F8:61:8222:0:0:0:50 mynetworks = 127.0.0.0/8, 10.1.0.0/16, [::1]/128, [2a01:4f8:61:8222::]/64 These settings work for me. So maybe it gives you an idea. Regards Christian --- Roessner-Network-Solutions Bachelor of Science Informatik Nahrungsberg 81, 35390 Gießen F: +49 641 5879091, M: +49 176 93118939 USt-IdNr.: DE225643613 http://www.roessner-network-solutions.com
Re: postfix in an IPv6 network
On Mon, Oct 25, 2010 at 01:40:46PM CEST, lst_ho...@kwsoft.de said: > > The address 2002:::1::21 is not within 2002::::/64 as > far as i can tell. You should use 2002:::1::/64 instead in > mynetworks. The :: means all zero if memory serves me right. I use [2a01:240:fe0f::0]/64 and it works...
Re: postfix in an IPv6 network
Zitat von Erwan David : On Mon, Oct 25, 2010 at 01:40:46PM CEST, lst_ho...@kwsoft.de said: The address 2002:::1::21 is not within 2002::::/64 as far as i can tell. You should use 2002:::1::/64 instead in mynetworks. The :: means all zero if memory serves me right. I use [2a01:240:fe0f::0]/64 and it works... Yes, but not for something like 2a01:240:fe0f:1::1. This is one of the main problems with IPv6, the addresses are simply too long to get handled by humans without a high error percentage. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: qty hold: logged does.not.equal qty hold queue ?
-- Original Message -- From: Noel Jones Reply-To: postfix users Date: Mon, 25 Oct 2010 06:16:07 -0500 >On 10/25/2010 4:28 AM, Len Conrad wrote: >> >> I'm testing a new filter, so I HOLD matching messages, then inspect them to >> either release or delete them. >> >> egrep -ic "hold: " /var/log/maillog >> 298 >> >> but in mailq: >> >> mailq | mailq-oneline.pl | egrep -ic "! " >> 35 >> >> cross checking: >> >> find /var/spool/postfix/hold -type f | wc -l >>35 >> >> In case I forgot I cleaned the queue: >> >> egrep -ic "postsuper.*removed" /var/log/maillog >> 3 >> >> Why the 250+ diff between HOLD: log lines and hold queue files? >> >> Len > >Several reasons come to mind... >Mail can trigger a HOLD rule but be rejected by a later rule. Why would a HOLD: continue to be processed by other rules? Isn't HOLD a first-match-wins case? > If you have multiple HOLD rules they may each create their >own log entry. I have a HOLD for per-sender rate limit, and a HOLD for per-IP rate limit. Again, if a msg is HOLD by a rule/filter, why would other rules/filters see it? > A recipient rule that triggers HOLD will log >for each recipient of a multi-recipient message, but will only >result in one message in the hold queue. ok Len
Re: qty hold: logged does.not.equal qty hold queue ?
Len Conrad: > >Several reasons come to mind... > >Mail can trigger a HOLD rule but be rejected by a later rule. > > Why would a HOLD: continue to be processed by other rules? > > Isn't HOLD a first-match-wins case? HOLD is a non-final action, like FILTER, WARN and IGNORE. REJECT is an example of a final action; no other actions will be triggered after REJECT. Wietse
Re: qty hold: logged does.not.equal qty hold queue ?
On 10/25/2010 8:24 AM, Len Conrad wrote: -- Original Message -- From: Noel Jones Reply-To: postfix users Date: Mon, 25 Oct 2010 06:16:07 -0500 On 10/25/2010 4:28 AM, Len Conrad wrote: I'm testing a new filter, so I HOLD matching messages, then inspect them to either release or delete them. egrep -ic "hold: " /var/log/maillog 298 but in mailq: mailq | mailq-oneline.pl | egrep -ic "! " 35 cross checking: find /var/spool/postfix/hold -type f | wc -l 35 In case I forgot I cleaned the queue: egrep -ic "postsuper.*removed" /var/log/maillog 3 Why the 250+ diff between HOLD: log lines and hold queue files? Len Several reasons come to mind... Mail can trigger a HOLD rule but be rejected by a later rule. Why would a HOLD: continue to be processed by other rules? Isn't HOLD a first-match-wins case? HOLD doesn't terminate processing like an OK or REJECT; it's more like DUNNO, continue. Internally, it just sets a flag and continues with the next rule. If you have multiple HOLD rules they may each create their own log entry. I have a HOLD for per-sender rate limit, and a HOLD for per-IP rate limit. Again, if a msg is HOLD by a rule/filter, why would other rules/filters see it? HOLD doesn't terminate processing like an OK or REJECT; it's more like DUNNO, continue. -- Noel Jones A recipient rule that triggers HOLD will log for each recipient of a multi-recipient message, but will only result in one message in the hold queue. ok Len
is this DNS setup RFC-correct ?
Hi, This question is not postfix-related so its somehow off-topic. But it's related to mail systems, so i cant imagine any other place to get some help on this subject. I have a domain (domain.com.br) with lots of subdomains in the format nnn.domain.com.br. nnn.domain.com.br (about 40 different subdomains) have only 2 (two) DNS entries: nnnINMX10 server.nnn.domain.com.br. nnnINTXT"v=spf1 include:domain.com.br -all" there's absolutely no A entries for the subdomains. i'm having an isolated problem with a customer that cannot send mails to one of my subdomains (everything else is working fine, several thousand of messages flowing daily, this really seems to be an isolated problem). Altough, their sysadmin (from the domain which cannot send us mail) is telling what i'm doing (having an MX entry but no A entries) is RFC-illegal, altough he cannot point me which RFC i'm not complaining with. i really dont know if this setup (MX record but no A record) is RFC-OK. The only think i know is that it's been working for years and i receive thousand of emails daily on my several subdomains with no problem at all. question is do a domain (or in my case, a subdomain) *MUST* have an A record ? Is the config i'm doing (DNS speaking) correct or incorrect (RFC-speaking) ?? Thanks for any hints on that -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it
Re: is this DNS setup RFC-correct ?
Leonardo Rodrigues: > i really dont know if this setup (MX record but no A record) is > RFC-OK. The only think i know is that it's been working for years and i > receive thousand of emails daily on my several subdomains with no > problem at all. The EMAIL RFC requirement is that a domain name has an MX record or an A record (see RFC 5321 Section 5). There is no EMAIL RFC requirement to have an MX record AND an A record. Wietse
Re: Encrypt messages between 2 servers
On Sun, Oct 24, 2010 at 11:22:24AM +0200, martijn.list wrote: > > Just use opportunistic TLS on both ends and go. > > It depends on the requirements whether TLS is good enough. It's not > always possible to be 100% certain that the complete route is TLS > protected. All intermediate servers should protect the message with TLS > and this is something the sending server cannot enforce. For example if > you are using fallback SMTP servers hosted by some external company in > case of problems how can you be 100% certain that the email is TLS > protected? The "secure" and "fingerprint" TLS security levels address this issue. > If your requirements are such that you must be 100% certain that your > email is protected all the way, you should protect the message, not just > the channel. No, protecting the channel is quite sufficient, and by the far the simplest approach, if the goal (as stated) is secure delivery between two sites. -- Viktor.
Re: is this DNS setup RFC-correct ?
I know SPF is disliked here ;) On Mon, 2010-10-25 at 14:20 -0200, Leonardo Rodrigues wrote: > nnnINTXT"v=spf1 include:domain.com.br -all" But using TXT for it is (IIRC) discouraged by the RFC and "SPF" RR shoudl be used. Cheers, Chris.
one Postfix instance serving messages in two different directions
Hi there, How can I have one single Postfix instance routing messages differently, depends on which IP address they are arriving at SMTP. If an outside connection arrives, Postfix will deliver message to my customized transport, which calls a script and passes the message. If an internal connection arrives, Postfix will deliver message to a local user's maildir directory. I know we can configure Postfix to use different content filters based on different IP, but this is a little different in that I wish to route message differently. I noticed the following two "smtp" entry in master.cf. What do they mean? smtp inet n - n - - smtpd smtp unix - - n - - smtp If I want to accomplish what I wanted, would my master.cf look like the following, i.e., I have to create my own smtpd deamon process? 1.2.3.4:smtp inet n - n - - smtpd (which deliver messages in local maildir) 1.3.5.7:smtp inet n - n - - smtpcustomized (which uses my customized transport) Thanks, Yan Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system.
Re: one Postfix instance serving messages in two different directions
On 10/25/2010 07:43 PM, Zhou, Yan wrote: Hi there, How can I have one single Postfix instance routing messages differently, depends on which IP address they are arriving at SMTP. By making postfix listen with separate smtpd listeners on those IPs. Those instances can then have different transport settings. following, i.e., I have to create my own smtpd deamon process? 1.2.3.4:smtp inet n - n - - smtpd (which deliver messages in local maildir) 1.3.5.7:smtp inet n - n - - smtpcustomized (which uses my customized transport) For instance, yes. Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system. Ridiculous. Don't send mail to a mailing list with such laughable disclaimers :) -- J.
Re: one Postfix instance serving messages in two different directions
Zhou, Yan: > Hi there, > > How can I have one single Postfix instance routing messages differently, > depends on which IP address they are arriving at SMTP. > > If an outside connection arrives, Postfix will deliver message to my > customized transport, which calls a script and passes the message. > If an internal connection arrives, Postfix will deliver message to a > local user's maildir directory. > > I know we can configure Postfix to use different content filters based > on different IP, but this is a little different in that I wish to route > message differently. This is simple when you use Postfix 2.6 or later, and configure two Postfix instances, each listening on their own IP address, and each having their own myhostname setting. http://www.postfix.org/MULTI_INSTANCE_README.html Wietse
Re: is this DNS setup RFC-correct ?
On 10/25/2010 07:41 PM, Christoph Anton Mitterer wrote: I know SPF is disliked here ;) Like doesn't enter into it. Discussion of SPF is verboten. simple. -- J.
Re: is this DNS setup RFC-correct ?
On Mon, 2010-10-25 at 19:49 +0200, Jeroen Geilman wrote: > Like doesn't enter into it. > > Discussion of SPF is verboten. simple. Yeah I know,... but I thought Wietse might excuse me because I hoped one could judge this as only answering a DNS question ;-D Cheers, Chris.
RE: one Postfix instance serving messages in two different directions
Can you elaborate how different smtpd can have different transport settings? I won't want to create my own SMTPD process. The following won't work, because the "transport" cannot distinguish IP address. I tried this but does not work. I wonder if only smtp process can vary based on different IP. Seen in master.cf: 1.2.3.4:smtp inet n - n - - smtpd 1.3.5.7:smtp inet n - n - - smtpd .. # # I want to route messages to different endpoints based on which IP it is from. # 1.2.3.4:connector unix - n n - - pipe flags=D user=yan argv=python /usr/local/bin/test2.py 1.3.5.7:connector unix - n n - - pipe flags=D user=yan argv=python /usr/local/bin/test1.py Confidentiality Notice: The information contained in this electronic transmission is confidential and may be legally privileged. It is intended only for the addressee(s) named above. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by telephone (513) 229-5500 or by email (postmas...@medplus.com). After replying, please erase it from your computer system.
Re: one Postfix instance serving messages in two different directions
On Mon, Oct 25, 2010 at 02:25:32PM -0400, Zhou, Yan wrote: > Can you elaborate how different smtpd can have different transport > settings? I won't want to create my own SMTPD process. > > The following won't work, because the "transport" cannot distinguish IP > address. I tried this but does not work. I wonder if only smtp process > can vary based on different IP. > > Seen in master.cf: > > > 1.2.3.4:smtp inet n - n - - smtpd > > 1.3.5.7:smtp inet n - n - - smtpd Within a single Postfix instance, it is NOT possible to use difference transport tables for different smtpd(8) entries in master.cf. The transport lookup service and queue manager are global within a Postfix instance. -- Viktor.
Set relay_domains LDAP.
I'm using Postfix 2.7.0 and Dovecot 1.2.9.
I don't understand why this machine (imap) is trying to send warning
emails as if the recipient was local.
If I set relay_domains to "target.example.org", it works ok, I can
send email to *...@gmail.com (or any other domain), from imap.
If I set relay_domains to ldap:/etc/postfix/ldap-mapa-dominios.cf,
it does not work, and the output from postmap -q some...@gmail.com
ldap:/etc/postfix/ldap-mapa-dominios.cf is the *same* value I before
set, which is "target.example.org". Because of that, if the imap
machine tries to send an error msg (such as mailbox full), it treats
the sender as local, so it tries to send locally the mailbox full
message.
-> target.example.org is handled by this mail system (and LDAP has
information about it).
-> origin.example.org is NOT handled by this email system, on my
tests, origin.example.org is GMail, Yahoo, and also subdomains within
my network, NOT handled by this mail system or LDAP.
On the log attached, what I tried to do was: send mail from
la...@origin.example.org to m...@target.example.org, and m...@target
is overquota, so it should send email to la...@origin.example.org, but
Dovecot thinks it's a local mail, I think (line 11).
# 01 imap dovecot: deliver(m...@target.domain.org):
msgid=<722690f049ba7369963071195e38ae7a.squir...@webmail.origin.domain.org>:
save failed to INBOX: Quota exceeded (mailbox for user is full)
# 02 imap dovecot: deliver(m...@target.domain.org):
msgid=<722690f049ba7369963071195e38ae7a.squir...@webmail.origin.domain.org>:
rejected: Quota exceeded (mailbox for user is full)
# 03 imap dovecot: deliver(m...@target.domain.org): Sending a
rejection to m...@target.domain.org: Quota exceeded (mailbox for user
is full)
# 04 imap postfix/pickup[12141]: EFA2340A70: uid=666 from=<>
# 05 imap postfix/cleanup[12201]: dict_ldap_debug:
ldap_build_search_req ATTRS: associatedDomain
# 06 imap postfix/cleanup[12201]: EFA2340A70:
message-id=
# 07 imap postfix/qmgr[12142]: EFA2340A70: from=<>, size=3150, nrcpt=1
(queue active)
# 08 imap postfix/trivial-rewrite[12200]: dict_ldap_debug:
ldap_build_search_req ATTRS: associatedDomain
# 09 imap postfix/pipe[12203]: 67CBC40A6E:
to=, relay=dovecot, delay=0.59,
delays=0.47/0.02/0/0.1, dsn=2.0.0, status=sent (delivered via dovecot
service)
# 10 imap postfix/qmgr[12142]: 67CBC40A6E: removed
# 11 imap dovecot: deliver(la...@origin.domain.org): Loading modules
from directory: /usr/lib/dovecot/modules/lda
# 12 imap dovecot: deliver(la...@origin.domain.org): Module loaded:
/usr/lib/dovecot/modules/lda/lib10_quota_plugin.so
# 13 imap dovecot: deliver(la...@origin.domain.org): Module loaded:
/usr/lib/dovecot/modules/lda/lib90_sieve_plugin.so
# 14 imap dovecot: auth(default): master in:
user#0111#011la...@origin.domain.org#011service=deliver
# 15 imap dovecot: auth(default): prefetch(la...@origin.domain.org):
passdb didn't return userdb entries, trying the next userdb
# 16 imap dovecot: auth(default): ldap(la...@origin.domain.org): user
search:
base=ou=origin.domain.org,ou=mail,ou=services,dc=example,dc=org
scope=subtree filter=(&
(cn=lauro)(objectclass=nisMailAlias)(ContaAtiva=TRUE) )
fields=rfc822MailMember,EmailQuota,EmailQuotaSpecial,eduPersonPrincipalName
# 01 imap dovecot: auth(default): ldap(la...@origin.domain.org):
ldap_search((& (cn=lauro)(objectclass=nisMailAlias)(ContaAtiva=TRUE)
)) failed: No such object
--
main.cf
--
smtpd_banner = $myhostname
biff = no
append_dot_mydomain = no
readme_directory = no
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
myhostname = imap
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-mapa-usuarios.cf
local_recipient_maps = hash:/etc/aliases,
ldap:/etc/postfix/ldap-mapa-usuarios.cf
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_alias_domains = hash:/etc/postfix/virtual
virtual_maps = ldap:/etc/postfix/ldap-mapa-usuarios.cf
relay_recipient_maps = ldap:/etc/postfix/ldap-mapa-usuarios.cf
mydestination = $myhostname, localhost.$mydomain,
ldap:/etc/postfix/ldap-mapa-dominios.cf
relay_domains = ldap:/etc/postfix/ldap-mapa-dominios.cf
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
relay_host =
dovecot_destination_recipient_limit = 1
mailbox_transport = dovecot
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 123.123.12.71/32
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox =
smtpd_sasl_auth_enable = no
smtpd_sasl_type = cyrus
smtpd_sasl_path = smtpd
smtpd_sasl_authenticated_header = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain =
broken_sasl_auth_clients = no
smtpd_recipient_restrictions = permit_mynetworks,
Re: is this DNS setup RFC-correct ?
On Mon, Oct 25, 2010 at 07:49:14PM +0200, Jeroen Geilman wrote: > On 10/25/2010 07:41 PM, Christoph Anton Mitterer wrote: >> I know SPF is disliked here ;) > > Like doesn't enter into it. > > Discussion of SPF is verboten. simple. The politics and wisdom of SPF are off topic. Simple configuration questions relevant to Postfix, that touch on SPF, are not taboo. DNS pedantry is also off topic. The vast majority of SPF deployments use TXT records to publish SPF policy. This is not the forum for quixotic campaigns to change the status quo. -- Viktor.
Re: Set relay_domains LDAP.
On Mon, Oct 25, 2010 at 04:43:15PM -0200, Lauro Costa G. Borges wrote: > > > I'm using Postfix 2.7.0 and Dovecot 1.2.9. > > I don't understand why this machine (imap) is trying to send warning > emails as if the recipient was local. > > If I set relay_domains to "target.example.org", it works ok, I can send > email to *...@gmail.com (or any other domain), from imap. > If I set relay_domains to ldap:/etc/postfix/ldap-mapa-dominios.cf, it does > not work, ... Classic user error #1. http://www.postfix.org/DATABASE_README.html#lists DO NOT ignore the lookup key and return the list of relay domains. DO lookup the requested domain, and return a non-empty result IF AND ONLY IF the domain is a relay domain. -- Viktor.
Re: one Postfix instance serving messages in two different directions
To send mail to a script depending on the arriving SMTP port:
/etc/postfix/master.cf:
1.2.3.4:smtp inet n - n - - smtpd
-o content_filter=script_for_1_2_3_4:
script_for_1_2_3_4 unix - n n - - pipe
flags=RX user=yan argv=python /usr/local/bin/test2.py ${recipient}
1.3.5.7:smtp inet n - n - - smtpd
-o content_filter=script_for_1_3_5_7:
script_for_1_3_5_7 unix - n n - - pipe
flags=RX user=yan argv=python /usr/local/bin/test1.py ${recipient}
This will override transport map settings.
Wietse
Re: one Postfix instance serving messages in two different directions
On 10/25/2010 08:30 PM, Victor Duchovni wrote: On Mon, Oct 25, 2010 at 02:25:32PM -0400, Zhou, Yan wrote: Can you elaborate how different smtpd can have different transport settings? I won't want to create my own SMTPD process. The following won't work, because the "transport" cannot distinguish IP address. I tried this but does not work. I wonder if only smtp process can vary based on different IP. Seen in master.cf: 1.2.3.4:smtp inet n - n - - smtpd 1.3.5.7:smtp inet n - n - - smtpd Within a single Postfix instance, it is NOT possible to use difference transport tables for different smtpd(8) entries in master.cf. The transport lookup service and queue manager are global within a Postfix instance. Yeh, I guess I added to the confusion with my mention of transport. You could add a check_client_access and act on the result. -- J.
Re: postfix not delivering all by itself
heh. the subject of my question seems to be wrong. there's something else i don't understand. here's my postconf -n output: - command_directory = /usr/sbin config_directory = /etc/postfix content_filter = pmx:127.0.0.1:10025 daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = /opt/depot/postfix-2.7.1/html inet_interfaces = all local_transport = error:local mail delivery is disabled mail_owner = postfix mailbox_size_limit = 0 mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/local/man masquerade_domains = $mydomain message_size_limit = 0 mydestination = mydomain = arlut.utexas.edu myhostname = j6.arlut.utexas.edu mynetworks = 127.0.0.0/8, 10.0.0.0/8 myorigin = $mydomain newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /opt/depot/postfix-2.7.1/README recipient_delimiter = + relay_domains = ws.arlut.utexas.edu sisl-list.arlut.utexas.edu spd.arlut.utexas.edulists.arlut.utexas.edu seaturtle.arlut.utexas.edu arlex.arlut.utexas.edu arlmail.arlut.utexas.edutools.arlut.utexas.edu vme.arlut.utexas.edu relay_recipient_maps = hash:/etc/postfix/pfknown_users relayhost = [ns6.arlut.utexas.edu] sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop transport_maps = hash:/etc/postfix/pftransport unknown_local_recipient_reject_code = 550 - this test box is a mail gateway. i don't deliver mail locally. it's inside the firewall. relay_recipient_maps = hash:/etc/postfix/pfknown_users more /etc/postfix/pfknown_users g...@arlut.utexas.edu OK transport_maps = hash:/etc/postfix/pftransport more /etc/postfix/pftransport ws.arlut.utexas.edu smtp:[ws.arlut.utexas.edu] sisl-list.arlut.utexas.edu smtp:[sisl-list.arlut.utexas.edu] spd.arlut.utexas.edusmtp:[spd.arlut.utexas.edu] lists.arlut.utexas.edu smtp:[lists.arlut.utexas.edu] seaturtle.arlut.utexas.edu smtp:[seaturtle.arlut.utexas.edu] arlex.arlut.utexas.edu smtp:[arlex.arlut.utexas.edu] arlmail.arlut.utexas.edusmtp:[arlmail.arlut.utexas.edu] tools.arlut.utexas.edu smtp:[tools.arlut.utexas.edu] vme.arlut.utexas.edusmtp:[vme.arlut.utexas.edu] alias_maps = hash:/etc/postfix/pfmalias more /etc/postfix/pfmalias gl: g...@vme.arlut.utexas.edu i __thought__ that mail sent this way: mailx -s "test" gl < /etc/motd or this way: mailx -s "test" g...@arlut.utexas.edu < /etc/motd would be sent by this test machine directly to vme.arlut.utexas.edu. now it's beginning to dawn on me that if alias_maps is for local delivery only, it contributes nothing to my goal since i don't do local delivery. - http://www.postfix.org/postconf.5.html alias_maps (default: see "postconf -d" output) The alias databases that are used for local(8) delivery - http://www.postfix.org/local.8.html The local(8) daemon processes delivery requests from the Postfix queue manager to deliver mail to local recipients. - that is, the relay_recipient_maps entry is okay, it says i can send mail to gl; and the transport_maps entry is okay. but alias_maps isn't consulted since i don't do local delivery. so there's nothing in the above that says gl's mail goes to the machine vme.arlut.utexas.edu -- alias_maps won't enter in to it. is that correct? if so, what should i do to have this gateway find out about the connection between the user gl and the mail delivery machine vme? is that supposed to go in transport_maps? because it seems like that should be at the domain level only. what's the syntax in that case? g...@arlut.utexas.edu relay:[...@vme.arlut.utexas.edu] or g...@arlut.utexas.edu relay:[vme.arlut.utexas.edu] or g...@arlut.utexas.edu relay:g...@[vme.arlut.utexas.edu] that is, what do i do about the user name on the right hand side? i tried the middle one of those, and the mail still goes through the relayhost. j. -- Jay Scott 512-835-3553g...@arlut.utexas.edu Head of Sun Support, Sr. System Administrator Applied Research Labs, Computer Science Div. S224 University of Texas at Austin
Re: postfix not delivering all by itself
Jay G. Scott: > alias_maps: The alias databases that are used for local(8) delivery You can change the path for mail that is not delivered locally with virtual_alias_maps and with transport_maps. virtual_alias_maps changes the recipient address. Example: search key lookup result -- - u...@example.comu...@host.example.com transport_maps changes the delivery agent. Example: search key lookup result -- - u...@example.comsmtp:host.example.com Each of these mechanisms has its uses. More in http://www.postfix.org/ADDRESS_REWRITING_README.html Wietse
Re: is this DNS setup RFC-correct ?
On Mon, Oct 25, 2010 at 02:20:51PM -0200, Leonardo Rodrigues wrote: > > I have a domain (domain.com.br) with lots of subdomains in the > format nnn.domain.com.br. > > nnn.domain.com.br (about 40 different subdomains) have only 2 > (two) DNS entries: > > nnnINMX10 server.nnn.domain.com.br. > nnnINTXT"v=spf1 include:domain.com.br -all" Does an A record exist for server.nnn.domain.com.br? If not, how are we supposed to figure out where to actually direct mail for postmas...@nnn.domain.com.br? If you don't have an A record for server.nnn.domain.com.br, I believe you have a dangling MX record. Is the MX record supposed to be ?: nnn IN MX 10 server.domain.com.br. Maybe I've missed something in your problem description. Some very smart people have responded before me without mentioning this. I probably missed something. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org
Re: NOQUEUE Relay Access denied
Noel and others, > In the specific case of "Relay access denied" it will always > be the recipient address, but there are other reasons for mail > to be rejected. > > That section of the log line shows "what" was rejected along > with a brief text description/reason. > > The "what" can be any part of the SMTP envelope; client, HELO, > sender, recipient, or in the case of header/body checks, the > text that matched the rule. thanks a lot. THAT was the information I was looking for. Problem solved. Despite of various checks, the client/user still had a typo in his SMTP auth configuration (*snarf*). Thanks Tom
SMTP relay and greylisting
Hello all, This question has probably been asked on this list before, but maybe not quite with these circumstances. I'm hoping one of you can give me some direction. I've got a fairly typical Postfix setup... Postfix, Cyrus IMAP, ClamAV, SpamAssassin... all on Linux. Anyway, I've set up greylisting with Postgrey to help cut down on the junk mail that I get. I've set it up with default values (deferral of 300 seconds, etc). Well all seems good and fair except some of my regular senders can't seem to get their email through. I've checked my server logs and I don't even see their email address mentioned (it doesn't appear to even reach my machine). Several of the emails in question are Yahoo or Gmail. What's odd is that I have both a Yahoo account and a Gmail account, and I can send myself mail with no problems. I disabled Postgrey temporarily and had these senders re-send test messages from their addresses, and it worked (I got their messages). So something was certainly hanging things up. I just wish I knew what that was. This got me thinking... my ISP requires that I forward all outbound email through their SMTP server. Because their mail server (the SMTP relay I'm required to relay mail to) has suddenly been added to various RBLs for repeated "deferrals", is it possible that my greylisting is what is getting them on those RBLs? The Postgrey does cut down on the spam significantly, particularly when used in conjunction with SpamAssassin and RBLs like SpamCop and SpamHaus. I'd like to keep Postgrey if I can, assuming that my delivery problems are not directly associated with Postgrey... but if my circumstances with my ISP won't allow me to greylist, then disabling Postgrey might save me a headache. I guess I'm looking for some advice as to whether Postgrey could cause problems with my ISP (they run Exim on FreeBSD and firewall outgoing tcp port 25 everywhere but on their one mail server) but I don't know much more than that), or if there are some settings I should change to improve my greylisting setup. And just to clarify, port 25 is only blocked on the outbound. Inbound email comes straight to my mail system, which is only composed of one machine. Advice is very appreciated!
Re: SMTP relay and greylisting
On 10/25/2010 10:38 PM, utahnix wrote: > Hello all, > > This question has probably been asked on this list before, but maybe not > quite with these circumstances. I'm hoping one of you can give me some > direction. > > I've got a fairly typical Postfix setup... Postfix, Cyrus IMAP, ClamAV, > SpamAssassin... all on Linux. > > Anyway, I've set up greylisting with Postgrey to help cut down on the > junk mail that I get. I've set it up with default values (deferral of > 300 seconds, etc). Well all seems good and fair except some of my > regular senders can't seem to get their email through. I've checked my > server logs and I don't even see their email address mentioned (it > doesn't appear to even reach my machine). Several of the emails in > question are Yahoo or Gmail. What's odd is that I have both a Yahoo > account and a Gmail account, and I can send myself mail with no problems. > > I disabled Postgrey temporarily and had these senders re-send test > messages from their addresses, and it worked (I got their messages). So > something was certainly hanging things up. I just wish I knew what that was. Do you have "smtpd_delay_reject = yes" set? If so, you should be able to see the senders' addresses in your logs even if they were greylisted. > This got me thinking... my ISP requires that I forward all outbound > email through their SMTP server. Because their mail server (the SMTP > relay I'm required to relay mail to) has suddenly been added to various > RBLs for repeated "deferrals", is it possible that my greylisting is > what is getting them on those RBLs? Added to RBLs for deferrals? Doesn't make sense, or I'm missing something. > The Postgrey does cut down on the spam significantly, particularly when > used in conjunction with SpamAssassin and RBLs like SpamCop and > SpamHaus. I'd like to keep Postgrey if I can, assuming that my delivery > problems are not directly associated with Postgrey... but if my > circumstances with my ISP won't allow me to greylist, then disabling > Postgrey might save me a headache. > > I guess I'm looking for some advice as to whether Postgrey could cause > problems with my ISP (they run Exim on FreeBSD and firewall outgoing tcp > port 25 everywhere but on their one mail server) but I don't know much > more than that), or if there are some settings I should change to > improve my greylisting setup. It's highly unlikely, but concentrate on one problem at a time. When these people send to you and the messages don't make it through, do they get a rejection or anything that might suggest that delivery failed? If not -- while you should still be seeing their email address in the logs -- I would guess that SpamAssassin or ClamAV snatched the message. Now might be a good time to post your `postconf -n`.
Re: SMTP relay and greylisting
On 10/25/2010 9:05 PM, Michael Orlitzky wrote: On 10/25/2010 10:38 PM, utahnix wrote: Hello all, This question has probably been asked on this list before, but maybe not quite with these circumstances. I'm hoping one of you can give me some direction. I've got a fairly typical Postfix setup... Postfix, Cyrus IMAP, ClamAV, SpamAssassin... all on Linux. Anyway, I've set up greylisting with Postgrey to help cut down on the junk mail that I get. I've set it up with default values (deferral of 300 seconds, etc). Well all seems good and fair except some of my regular senders can't seem to get their email through. I've checked my server logs and I don't even see their email address mentioned (it doesn't appear to even reach my machine). Several of the emails in question are Yahoo or Gmail. What's odd is that I have both a Yahoo account and a Gmail account, and I can send myself mail with no problems. I disabled Postgrey temporarily and had these senders re-send test messages from their addresses, and it worked (I got their messages). So something was certainly hanging things up. I just wish I knew what that was. Do you have "smtpd_delay_reject = yes" set? If so, you should be able to see the senders' addresses in your logs even if they were greylisted. Yes I do, actually. This got me thinking... my ISP requires that I forward all outbound email through their SMTP server. Because their mail server (the SMTP relay I'm required to relay mail to) has suddenly been added to various RBLs for repeated "deferrals", is it possible that my greylisting is what is getting them on those RBLs? Added to RBLs for deferrals? Doesn't make sense, or I'm missing something. I don't know that deferrals would get a system blacklisted, per se. My thought was no, but I often worry that I'm missing something in my technical understanding. I just found it disturbing that suddenly (the same time I implemented Postgrey) outbound messages leaving my ISP's SMTP relay started to bounce because *their* SMTP relay server is on an RBL (in this case, commtouch.com), and... I suddenly am not getting all of my inbound messages. In other words, I implement greylisting and suddenly people are having trouble with message delivery, one way or another, and that had me worrying. I realize that this could very well be two issues, and I also realize that the issues might not have anything to do with my machine. But I also realize it would be very arrogant of me to assume there couldn't be problems with my machine. While I'm no email newbie, I'm also no master. The Postgrey does cut down on the spam significantly, particularly when used in conjunction with SpamAssassin and RBLs like SpamCop and SpamHaus. I'd like to keep Postgrey if I can, assuming that my delivery problems are not directly associated with Postgrey... but if my circumstances with my ISP won't allow me to greylist, then disabling Postgrey might save me a headache. I guess I'm looking for some advice as to whether Postgrey could cause problems with my ISP (they run Exim on FreeBSD and firewall outgoing tcp port 25 everywhere but on their one mail server) but I don't know much more than that), or if there are some settings I should change to improve my greylisting setup. It's highly unlikely, but concentrate on one problem at a time. When these people send to you and the messages don't make it through, do they get a rejection or anything that might suggest that delivery failed? Let me clarify here. On incoming messages that clients insist they've sent and we've never received, no, nobody is getting any sort of rejection message or delivery failure (boy those make troubleshooting easier!). There's no mention of their email address in the logs (and I know Postfix is pretty verbose by default, which is another reason I like it). On outbound messages we have had a few bounce backs. This is where my concern about the RBLs come into the picture. The rejection messages indicate that the SMTP relay maintained by my ISP is what is on the RBL, not my IP. But because they've firewalled port 25, if their relay can't send mail, my system, by default, cannot either. If not -- while you should still be seeing their email address in the logs -- I would guess that SpamAssassin or ClamAV snatched the message. That was my thinking as well (that it would be in the logs), but I found myself questioning my own logic. I guess I just want to be sure I haven't missed something. Now might be a good time to post your `postconf -n`. Here it is: alias_maps = hash:/etc/aliases always_bcc = archi...@domain1.com broken_sasl_auth_clients = yes canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 daemon_directory = /usr/lib/postfix debug_peer_level = 2 defer_transports = disable_dns_lookups = no disable_vrfy_command = yes header_checks = pcre:/etc/postfix/he
