Re: Cannot stop spam originated ON server
On Tue, May 17, 2011 at 6:25 PM, Noel Jones njo...@megan.vbhcs.org wrote: The usual suspects are: - these are not really generated from your machine, but rather bounces of undeliverable mail you've previously accepted. Don't accept mail you can't or won't deliver. - an insecure web script is being exploited. See more on both these subjects in the list archive. If you're only seeing a handful per day, my guess is these are bounces. Usually exploits result in tens of thousands or more spams sent. You can show postfix log entries here if you need more information on what they mean. -- Noel Jones OK, I found it. I was misreading logs. I found a compromized account that was being used to send spams. Thanks for your help!
Re: Timed out while sending message body
On 05/18/2011 12:53 AM, Digest of postfix-users list wrote: Date: Tue, 17 May 2011 17:37:22 +0200 From: Mark Martinecmark.martinec+post...@ijs.si Subject: Re: Timed out while sending message body Tomasz K. Jarzynka: Finally, I ran a tcpdump on our origin mail server, our firewall and the destinantion mail server (thanks to the help of its administrator) but the output is inconclusive to me. On our side, It looks like transmission stalls after a couple hundred bytes + subsequent retransmissions eventually leading to a timeout. On the destination side, it looks like the connection is ended immediately after the start of transmission. Google for 1 - IP path MTU discovery. 2 - TCP window scaling. This doesn't look like a PMTU discovery problem, more like a NAT screwup. A duplicate ACK packet #78 in mnisw-fw.dump seems to get translated into a packet #81 in mnisw-mailhub.dump with a wrong sequence number and with no NAT translation. This causes your mailer to RST the seemingly new session, this RST is then seen by the remote side as an original session reset. Thanks, I didn't figure that out. I think I'll try bypassing the firewall entirely to confirm the source of the problem. -- Tomasz Krzysztof Jarzynka / tel. +48 22 597 07 45 / mob. +48 601 706 601 Network Information Systems Administrator / tomee(at)genesilico(d-o-t)pl Laboratory of Bioinformatics and Prot. Engineering | iimcb.genesilico.pl International Institute of Molecular and Cell Biology | www.iimcb.gov.pl
Filtering spam with a partial pattern
Hi all! i'm seeing a huge quantity of spam during this week (~156K messages) all from an smtp addresses that begins with '0-', like: from=0...@cancer.org from=0-1z3ize-...@bxbmail.de from=0...@carnival.com from=0-gentil...@aditi.com from=0-happy-1...@msf.biglobe.ne.jp from=0-downl...@soundviewmortgage.com I tried to reject them by writing a simple rule in my smtpd_sender_checks by simply appending 0- at the beginning of a new line but for some reason it isn't matching the pattern, finally getting rejected by my RBL provider. Anyway I want to avoid doing RBL checks for this case, any ideas why my rule isn't working? any suggetions on how to write a filter for this pattern? TIA! PS: some more info: $ /usr/sbin/postconf -m btree cidr environ hash internal ldap nis proxy regexp static tcp unix $ /usr/sbin/postconf mail_version mail_version = 2.7.3 smtpd_recipient_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # warn_if_reject reject_unknown_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, # reject_unknown_sender_domain, # reject_unknown_recipient_domain, reject_unauth_destination, check_client_access hash:$config_directory/maps/smtpd_client_checks, check_helo_access hash:$config_directory/maps/smtpd_helo_checks, check_sender_access hash:$config_directory/maps/smtpd_sender_checks, check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, check_recipient_access hash:$config_directory/maps/smtpd_recipient_checks, reject_non_fqdn_hostname, reject_unverified_recipient, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rhsbl_client rhsbl.sorbs.net, check_sender_access hash:$config_directory/maps/forged_domain_senders, check_policy_service inet:127.0.0.1:10023, permit smtpd_data_restrictions = warn_if_reject reject_unauth_pipelining, permit
Re: Filtering spam with a partial pattern
On 5/18/2011 8:06 AM, Lima Union wrote: Hi all! i'm seeing a huge quantity of spam during this week (~156K messages) all from an smtp addresses that begins with '0-', like: from=0...@cancer.org from=0-1z3ize-...@bxbmail.de from=0...@carnival.com from=0-gentil...@aditi.com from=0-happy-1...@msf.biglobe.ne.jp from=0-downl...@soundviewmortgage.com I tried to reject them by writing a simple rule in my smtpd_sender_checks by simply appending 0- at the beginning of a new line but for some reason it isn't matching the pattern, finally getting rejected by my RBL provider. Anyway I want to avoid doing RBL checks for this case, any ideas why my rule isn't working? any suggetions on how to write a filter for this pattern? Add to your smtpd_sender_checks.regexp file: /^0-/ REJECT invalid sender address -- Noel Jones TIA! PS: some more info: $ /usr/sbin/postconf -m btree cidr environ hash internal ldap nis proxy regexp static tcp unix $ /usr/sbin/postconf mail_version mail_version = 2.7.3 smtpd_recipient_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # warn_if_reject reject_unknown_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, # reject_unknown_sender_domain, # reject_unknown_recipient_domain, reject_unauth_destination, check_client_access hash:$config_directory/maps/smtpd_client_checks, check_helo_access hash:$config_directory/maps/smtpd_helo_checks, check_sender_access hash:$config_directory/maps/smtpd_sender_checks, check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, check_recipient_access hash:$config_directory/maps/smtpd_recipient_checks, reject_non_fqdn_hostname, reject_unverified_recipient, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rhsbl_client rhsbl.sorbs.net, check_sender_access hash:$config_directory/maps/forged_domain_senders, check_policy_service inet:127.0.0.1:10023, permit smtpd_data_restrictions = warn_if_reject reject_unauth_pipelining, permit
Re: Filtering spam with a partial pattern
Original-Nachricht Datum: Wed, 18 May 2011 08:49:25 -0500 Von: Noel Jones njo...@megan.vbhcs.org An: postfix-users@postfix.org Betreff: Re: Filtering spam with a partial pattern On 5/18/2011 8:06 AM, Lima Union wrote: Hi all! i'm seeing a huge quantity of spam during this week (~156K messages) all from an smtp addresses that begins with '0-', like: from=0...@cancer.org from=0-1z3ize-...@bxbmail.de from=0...@carnival.com from=0-gentil...@aditi.com from=0-happy-1...@msf.biglobe.ne.jp from=0-downl...@soundviewmortgage.com I tried to reject them by writing a simple rule in my smtpd_sender_checks by simply appending 0- at the beginning of a new line but for some reason it isn't matching the pattern, finally getting rejected by my RBL provider. Anyway I want to avoid doing RBL checks for this case, any ideas why my rule isn't working? any suggetions on how to write a filter for this pattern? Add to your smtpd_sender_checks.regexp file: /^0-/ REJECT invalid sender address Should that not be: /^0\-/ REJECT invalid sender address -- Noel Jones TIA! PS: some more info: $ /usr/sbin/postconf -m btree cidr environ hash internal ldap nis proxy regexp static tcp unix $ /usr/sbin/postconf mail_version mail_version = 2.7.3 smtpd_recipient_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # warn_if_reject reject_unknown_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, # reject_unknown_sender_domain, # reject_unknown_recipient_domain, reject_unauth_destination, check_client_access hash:$config_directory/maps/smtpd_client_checks, check_helo_access hash:$config_directory/maps/smtpd_helo_checks, check_sender_access hash:$config_directory/maps/smtpd_sender_checks, check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, check_recipient_access hash:$config_directory/maps/smtpd_recipient_checks, reject_non_fqdn_hostname, reject_unverified_recipient, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rhsbl_client rhsbl.sorbs.net, check_sender_access hash:$config_directory/maps/forged_domain_senders, check_policy_service inet:127.0.0.1:10023, permit smtpd_data_restrictions = warn_if_reject reject_unauth_pipelining, permit -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Filtering spam with a partial pattern
On Wed, May 18, 2011 at 10:54 AM, Steve stev...@gmx.net wrote: Original-Nachricht Datum: Wed, 18 May 2011 08:49:25 -0500 Von: Noel Jones njo...@megan.vbhcs.org An: postfix-users@postfix.org Betreff: Re: Filtering spam with a partial pattern On 5/18/2011 8:06 AM, Lima Union wrote: Hi all! i'm seeing a huge quantity of spam during this week (~156K messages) all from an smtp addresses that begins with '0-', like: from=0...@cancer.org from=0-1z3ize-...@bxbmail.de from=0...@carnival.com from=0-gentil...@aditi.com from=0-happy-1...@msf.biglobe.ne.jp from=0-downl...@soundviewmortgage.com I tried to reject them by writing a simple rule in my smtpd_sender_checks by simply appending 0- at the beginning of a new line but for some reason it isn't matching the pattern, finally getting rejected by my RBL provider. Anyway I want to avoid doing RBL checks for this case, any ideas why my rule isn't working? any suggetions on how to write a filter for this pattern? Add to your smtpd_sender_checks.regexp file: /^0-/ REJECT invalid sender address Should that not be: /^0\-/ REJECT invalid sender address -- Noel Jones TIA! OK, thanks, it worked (second option). LU
Re: Filtering spam with a partial pattern
On 5/18/2011 8:54 AM, Steve wrote: Original-Nachricht Datum: Wed, 18 May 2011 08:49:25 -0500 Von: Noel Jonesnjo...@megan.vbhcs.org An: postfix-users@postfix.org Betreff: Re: Filtering spam with a partial pattern On 5/18/2011 8:06 AM, Lima Union wrote: Hi all! i'm seeing a huge quantity of spam during this week (~156K messages) all from an smtp addresses that begins with '0-', like: from=0...@cancer.org from=0-1z3ize-...@bxbmail.de from=0...@carnival.com from=0-gentil...@aditi.com from=0-happy-1...@msf.biglobe.ne.jp from=0-downl...@soundviewmortgage.com I tried to reject them by writing a simple rule in my smtpd_sender_checks by simply appending 0- at the beginning of a new line but for some reason it isn't matching the pattern, finally getting rejected by my RBL provider. Anyway I want to avoid doing RBL checks for this case, any ideas why my rule isn't working? any suggetions on how to write a filter for this pattern? Add to your smtpd_sender_checks.regexp file: /^0-/ REJECT invalid sender address Should that not be: /^0\-/ REJECT invalid sender address Not necessary. The - is not special outside character classes. -- Noel Jones
IPv4 relayhost only to be used for non-reachable IPv6 destinations?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I may have a somewhat unique situation regarding an IPv4 relayhost on an IPv4 and IPv6 enabled Postfix MTA; it seems that even for an IPv6 capable recipient MTA the IPv4 relayhost is used. Is there a way to bind/enforce the relayhost to be IPv4 only, as in, if the recipient's MX does not publish quad-As then use the IPv4 relayhost? Recipients publishing quad-A's for their MX currently are using the IPv4 relayhost as defined in the Postfix configuration. Ideally I would like native IPv6-IPv6 delivery if possible, ignoring the IPv4 defined relayhost as it only pertains to an IPv4 network. I have RTFM and attempted much self-discovery prior to asking here, if I've overlooked something simple please flame me accordingly. Postfix 2.8 here. - -- - -evilghost -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN0/MnAAoJENgimYXu6xOHPL4P/1/PUuEBRaIRHDJMknYdn9zl jhyHJK64GFkXP/l9cu7azemUIvfTRM3NYHMaP8XzrvcFVEGAnz7PpJdhy0TKrJ+z yc3fmtUJecVC6QjToUfGyJGxdioc8K6QZ9TJBOrmsHYpEoD+baMM4R6lG3BvJF+a wj2C8e1DKttsOpip85QsmxjtmbMKUs93k+3Am8eHnjF0v7tHNqmLkaP5s+HfugZ3 qygXKnkC3Ptwp3m1tr/FyjinSAUKaCA6QalO+E5QsV3HTXBk19glSGYEEfMLwuH+ anCQ25gaTQawbGk5kdu9vDn8EpPAi7JJfbpV4kfZzNni2seiTe83Chu/SF40+imv IwHEd25y6Dxnn8/o3yIdWUuboIHOUKy5vwklMsecbMMPqUjYCG5cQMu2evteSukJ v4JOjBDY/tLVqVm3ndsOOKgONhVIrNsvaAAQ4cPxoLeFSQfouVEfRgHDOTJP4Jpu 18Pzvd61YxBmy8LyZKj+KQe303AusyaS/34j+d8QyiWk/bv0xW2ZtQUk4vuFpu1V r99e0Iut8UQ8TMb/N8LTylOZQiBuFXzP0XgNopi53o+UPCPageoIudUVS+0YunmD ocGuIqG2ureVLFMgzAzHZHB9KzX1yXju6bhOua44hdC1P1KYyu2hkS4wlWECPtzQ oC1gu29pPa57Kw/goLoW =5/L0 -END PGP SIGNATURE-
Re: Custom Controlling Defer Queue!
afshin afzali: Postfix has no support for senders to specify do not deliver this message after X (i.e. no per-message expiration time). Of course, for transports such as SMS or voice I need to use custom scrips to wrap postfix to appropriate managers. In these scripts I will check time-frame parameter to decide if the message should let to go or not. Fine. then you can do the content inspection there, too. Otherwise, see http://www.postfix.org/CONTENT_INSPECTION_README.html. Here are some tips if you use the pipe(8) delivery agent for SMS deliveries: - If the message is spam, report successful delivery (exit status 0) to Postfix, and Postfix will throw the message away. - If the message is too old, report successful delivery (exit status 0) to Postfix, and Postfix will throw the message away. - If the message is delivered, report successful delivery (exit status 0) to Postfix, and Postfix will throw the message away. - Otherwise, if the message can't be delivered, report a temporary error (exit status 75) to Postfix, and Postfix will try again later as configured with minimal/maximal_backoff_time. Wietse
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
evilgh...@packetmail.net: Hello, I may have a somewhat unique situation regarding an IPv4 relayhost on an IPv4 and IPv6 enabled Postfix MTA; it seems that even for an IPv6 capable recipient MTA the IPv4 relayhost is used. Is there a way to bind/enforce the relayhost to be IPv4 only, as in, if the recipient's MX does not publish quad-As then use the IPv4 relayhost? Perhaps surprisingly, the Postfix relayhost feature works as documented: send the mail to $relayhost, instead of the host that is responsible for the recipient's domain. Recipients publishing quad-A's for their MX currently are using the IPv4 relayhost as defined in the Postfix configuration. Ideally I would like native IPv6-IPv6 delivery if possible, ignoring the IPv4 defined relayhost as it only pertains to an IPv4 network. As documented, the Postfix relayhost feature is agnostic of the the mail delivery mechanism for the recipient's domain, whether it is SMTP over TCP over IPV4 or something over RFC 1149. The Postfix documentation only describes the features that are implemented. Therefore if you can't find something then you can safely assume that it is not supported. Wietse I have RTFM and attempted much self-discovery prior to asking here, if I've overlooked something simple please flame me accordingly. Postfix 2.8 here. -- -evilghost -- End of PGP signed section.
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/11 13:02, Wietse Venema wrote: The Postfix documentation only describes the features that are implemented. Therefore if you can't find something then you can safely assume that it is not supported. Dr. Venema, thank you for your reply. As IPv6 adoption is increased I can certainly see a need to segregate an IPv6 relayhost and an IPv4 relayhost, especially in configurations of internal cascaded MTAs acting as egress content inspectors (which may not be IPv6 enabled due to technical or implementation reasons). Perhaps if it is deemed valuable to other Postfix users this feature could be considered for inclusion in future branches. It would be valuable to not have an IPv4 defined relayhost being enforced/utilized for IPv6 capable traffic. - -- - -evilghost -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN1Ay4AAoJENgimYXu6xOHTaQP/3GF4Y137qVp6kpFxtDFLYWC CzENzY0Cizj4ORZfSQmDXhdBmhpleX2b1jiI+PQ8U6mDKrJGqGp/Y2WrTM6djVhu RllcHX4siLOhOJeF8l+Rk2c+F/CGEtWApsRQ/++iLPRZqBQ5ipxZCR30t530IFWQ OY4VxgOZcLg1GgERiRTZz3uqsBdQEHW1piFhAJOMM1neHfyKHjQYhIOrakbhPMlQ VMSakmfO5ihauG3pU+bCN02YY+aGQDliLXjYHgtZ5DTHsh5B20kpljLGKxEtcvrc 4ha+si1qjulexzVIuz1iogS7sorSLMD5WHGQeDZcWnBgacVpk+/59Xw1URZnNS6L MzlGLmTa9cDLmWM7k0nfwhGqMz9DF4fha0uBagEhxd3R/D/+MxUYV7DQhNA6G4D8 yYe6QfkjXJ0FEKflL7Rf1Lm2pDvqXmHfelJF2UCnerceVfOFaBoA9MpF+XQQjVZC N29lvgzWkHIhrBnoTp/j18bIUDNRYTB4vdDRMquCmWjZUMA8vo8ddxCZikSpv/L4 ZC7MZMQo766MQp0IhJkJQ6UJgEsmfE1gAJaSUBGsJq9QAe+V8dz3IXElKOie/2do gUFd/GGlInivtCuEvehmKWGVFz8iyQr/LqsH48hG/eWcp+e6TuQfuQw7mEPulMN0 7mDeKgiPYohpJaQcszhI =tsKp -END PGP SIGNATURE-
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
On 05/18/2011 08:15 PM, evilgh...@packetmail.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/11 13:02, Wietse Venema wrote: The Postfix documentation only describes the features that are implemented. Therefore if you can't find something then you can safely assume that it is not supported. Dr. Venema, thank you for your reply. As IPv6 adoption is increased I can certainly see a need to segregate an IPv6 relayhost and an IPv4 relayhost, especially in configurations of internal cascaded MTAs acting as egress content inspectors (which may not be IPv6 enabled due to technical or implementation reasons). Perhaps if it is deemed valuable to other Postfix users this feature could be considered for inclusion in future branches. It would be valuable to not have an IPv4 defined relayhost being enforced/utilized for IPv6 capable traffic. Consider why you have set a global relayhost; apparently, you want ALL mail delivered via this one host. I also want mail that CAN be delivered over ipv6, to be delivered over ipv6 sounds like a conflicting requirement. If this relayhost has both A and records, the useful one would be chosen when delivering ipv[46]. -- J.
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/11 13:19, Jeroen Geilman wrote: Consider why you have set a global relayhost; apparently, you want ALL mail delivered via this one host. Negative, I want all IPv4-only, non-IPv6 transit capable, mail delivered via this host. - -- - -evilghost -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN1A6+AAoJENgimYXu6xOHH2YP/02n35uuel50Fu4lNMWGKMcO +Hly53qB3Zj94PW70sc7cm2M1rzzz9YNoCaTOS1ZpLaDzUDj5eYYVq7eiVj1lWFF 7U/5LA3KtJXVyMFXLLdrZlprZhrMYf6Gej5eXFezpg6QAcq80Yx1UiKaJmV+9eZO R2acCZ+JWrbW9v/w2UvRy2Pgo6Lj7M28qHg4EMrjG8abodDBwS5CnSXoaIgwbdZy qICdZfcpkQ1sfZ+f93INHapLIPh9urqAlFISZLrNV+awMtGvYdB9xBkTvAoofnC/ bZwit3C+Fa2uL67dSoNu24iNtWl82jp8ucWZYilY421VdAywDrte7usnQITanKOY mx3c8OSkxAtptzRNUJHtkZNfEQ5Ni4CXUSfzg22eXHH/d8Fw2X6Q4qGfQXW6pOcu qynQllaDmgGGcoPfVyXuIT9EBveveptQrboNdqPiOwp28jUlVWuaSz0YrOe6hqvI HrOiFeFxNJysDulsZkoHO5X23yTZ4vxFq6MPjPGZoNgQJLtc3r2lITniw0fQWdq5 7GmkqdXDN9r8pL9SSFgoJ/vSrIH3xGMEX2E+FlQO+sYqDP/z8r0wVZj4IKVOsR5I Imiqj7m42/HUKfu5fzmveyo11HfhTwbpg+BhWT2S1zGGbStkqUWG3k9SX3+t9RgW yJGuxhVD91xp09vIuJqD =A1tm -END PGP SIGNATURE-
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
On 05/18/2011 08:23 PM, evilgh...@packetmail.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/11 13:19, Jeroen Geilman wrote: Consider why you have set a global relayhost; apparently, you want ALL mail delivered via this one host. Negative, I want all IPv4-only, non-IPv6 transit capable, mail delivered via this host. But that is not what you have DONE. - -- - -evilghost -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN1A6+AAoJENgimYXu6xOHH2YP/02n35uuel50Fu4lNMWGKMcO +Hly53qB3Zj94PW70sc7cm2M1rzzz9YNoCaTOS1ZpLaDzUDj5eYYVq7eiVj1lWFF 7U/5LA3KtJXVyMFXLLdrZlprZhrMYf6Gej5eXFezpg6QAcq80Yx1UiKaJmV+9eZO R2acCZ+JWrbW9v/w2UvRy2Pgo6Lj7M28qHg4EMrjG8abodDBwS5CnSXoaIgwbdZy qICdZfcpkQ1sfZ+f93INHapLIPh9urqAlFISZLrNV+awMtGvYdB9xBkTvAoofnC/ bZwit3C+Fa2uL67dSoNu24iNtWl82jp8ucWZYilY421VdAywDrte7usnQITanKOY mx3c8OSkxAtptzRNUJHtkZNfEQ5Ni4CXUSfzg22eXHH/d8Fw2X6Q4qGfQXW6pOcu qynQllaDmgGGcoPfVyXuIT9EBveveptQrboNdqPiOwp28jUlVWuaSz0YrOe6hqvI HrOiFeFxNJysDulsZkoHO5X23yTZ4vxFq6MPjPGZoNgQJLtc3r2lITniw0fQWdq5 7GmkqdXDN9r8pL9SSFgoJ/vSrIH3xGMEX2E+FlQO+sYqDP/z8r0wVZj4IKVOsR5I Imiqj7m42/HUKfu5fzmveyo11HfhTwbpg+BhWT2S1zGGbStkqUWG3k9SX3+t9RgW yJGuxhVD91xp09vIuJqD =A1tm -END PGP SIGNATURE- -- J.
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/11 13:24, Jeroen Geilman wrote: But that is not what you have DONE. Yes, because evidently the two are mutually exclusive. A relayhost cannot be defined for only IPv4 traffic nor can it be configured to not effect IPv6 capable traffic. Essentially, as I understand Dr. Venema, the relayhost global configuration directive applies both to IPv4/IPv6 traffic with no mechanism to segregate them. This circles back to my acknowledgement from Dr. Venema and suggestion for inclusion of such a feature, if deemed community valuable, for future branches. I'm certainly open for any suggestions for accommodating my goal of applying an IPv4 relayhost to non-IPv6 capable traffic if there is such a way to accomplish this goal with the existing configuration directives. - -- - -evilghost -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN1BAtAAoJENgimYXu6xOHh9oQAIPr6jWz0TpQZcQWDVOk0pJ5 9nlVEHQ/0QiGTdBwXVYHAwiS0u7XB+xzra5XB5A5dTlVOUDPmtyeZYg1XjTvEb+i gSiTwtQ1Lv3pmsuUaNg4Ri8X+YwlobEfBi65UbZEmiZWibkIemo2EkZETpch1/8S qQnGnw1uvwCezJN8kVbuT8H75Cq/lfqa4jHAb3paeB8C9c+XuazK4d3CBV4SIPJf AlgJBTLyLE2GBvRNdOtF7ibXyUvgqKcLINvrT29IPmMRExicuSDsbncRzYTWBbQM OUTU2dt5erbVs2egLAN7gwj00+QYUVeNrzHjZss+p0y4HREXT9h6xdmGRVMiNNZO aFe1oqYG4xpudlBmOjPiFrr0zZiIaCgNO3qnFQ0lEH8t4Wppz5PIvc7W1B39ApPp 3n+jovkBaEfmX2BShXHL4tud6KLxHM7hQ8O7spC6UZdQGTufSHEYOLIl60tVZkDT Sc/u53FPPgYELlf8DuvPprDH8XXDEEv+AEziwPaQHYQSI5AvrMtsJspie/a50LuB OlbPVUgQ0ha7sYEf5gpJiarX3ExkMW+YCzIPNyjAoYd5ycVtVb3phCaHtVk8m33E xK0QzBYeejwgR1sOsVS09X2shnOpHzc8GFc+bCTRxJA6E2mcyewEH1/c+WEQRrdJ Zk2s47RafxRNd2auRxMW =quqc -END PGP SIGNATURE-
Re: Filtering spam with a partial pattern
On Wed, May 18, 2011 at 11:07 AM, Noel Jones njo...@megan.vbhcs.org wrote: On 5/18/2011 8:54 AM, Steve wrote: Original-Nachricht Datum: Wed, 18 May 2011 08:49:25 -0500 Von: Noel Jonesnjo...@megan.vbhcs.org An: postfix-users@postfix.org Betreff: Re: Filtering spam with a partial pattern On 5/18/2011 8:06 AM, Lima Union wrote: Hi all! i'm seeing a huge quantity of spam during this week (~156K messages) all from an smtp addresses that begins with '0-', like: from=0...@cancer.org from=0-1z3ize-...@bxbmail.de from=0...@carnival.com from=0-gentil...@aditi.com from=0-happy-1...@msf.biglobe.ne.jp from=0-downl...@soundviewmortgage.com I tried to reject them by writing a simple rule in my smtpd_sender_checks by simply appending 0- at the beginning of a new line but for some reason it isn't matching the pattern, finally getting rejected by my RBL provider. Anyway I want to avoid doing RBL checks for this case, any ideas why my rule isn't working? any suggetions on how to write a filter for this pattern? Add to your smtpd_sender_checks.regexp file: /^0-/ REJECT invalid sender address Should that not be: /^0\-/ REJECT invalid sender address Not necessary. The - is not special outside character classes. -- Noel Jones One last question regarding this, due that the amount of spam is huge I'd like to catch some of these messages, how should I configure Postfix in order to let this kind of messages (beginning with /^0-/ ) bypass all my checks (RBL,etc) and redirect them to my account to review them? is this possible? Thanks once again.
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
On Wed, May 18, 2011 at 2:30 PM, evilgh...@packetmail.net evilgh...@packetmail.net wrote: I'm certainly open for any suggestions for accommodating my goal of applying an IPv4 relayhost to non-IPv6 capable traffic if there is such a way to accomplish this goal with the existing configuration directives. What if you do this: eliminate the ability of your mail server to send SMTP over IPv4, possibly by removing any IPv4 address from it, or firewalling that ability away. Set up fallback_relay on this host so that all mail that did not make it on the first try goes to your relay host. There will be *some* IPv6 capable traffic sent that way as the result of transient failures, but it will be mostly messages that require IPv4.
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/18/11 13:52, Vick Khera wrote: What if you do this: eliminate the ability of your mail server to send SMTP over IPv4, possibly by removing any IPv4 address from it, or firewalling that ability away. Set up fallback_relay on this host so that all mail that did not make it on the first try goes to your relay host. There will be *some* IPv6 capable traffic sent that way as the result of transient failures, but it will be mostly messages that require IPv4. Highly creative and appreciated, I will certainly look into this. Thank you for your response as this may just yield an acceptable solution. It seems relay over IPv4 in the event of IPv6 failure would be necessary/acceptable as well and fall in-line with the Try IPv6 first then IPv4 seen with other daemons such as DNS. - -- - -evilghost -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJN1BamAAoJENgimYXu6xOHSlsP/RdymfP7ORXVgm2lE7kb0B9M jjj4LDX9L0T8meyhAT7138OJ86IGpuhw2QbMwHUrBXIKhwM7h3BvHoHkPN85ApaC 91kV4IcqKW6V1fKJ6hjunCFjKkj07X2aUQAYQ7RAfmZ26VDRBHMg/tHT13jFovRE sfU6l9iH0YiBBeTXiNMczg5rcnhZb3Dv6zdfhDFioWaJZDNsioFRIsvJjgHHkUoC yXwMwB059lIaC6+P5mHAYQH4EUuTj4SrgRYOu/hU7PK2jDgdl7DBicK8fbl5ddUp obEtSHhAiNS+umlIL5Dx6L9wnSip0uQCpXKXpNjKd610Zi0VNA/us53BekhtcGnB GK7hxxWy43hbDJocCKVcOXyQaHUt15EGprlpLWSG5i01qBpStBu65tRpeAh4ave5 J9Ypg0i7M4Q/Wjf4NEX1UMtOoDFZ8eSt1fkhjxmUmJ83oQFlp30zFqhbJ011nYsi Z519tXtAHxdD8IdIWi4QC3IoxmjQ/I7bUmKjhTdSTYsCHjk83GcIpLY+h8IVGTep vS9ddNI3KfG4IUU2E9mV3afOBfPTZMAcEReCNRkzQIigStotvUsDsPX91/W6WjbR qvLWk5LAZiJHaWwhmkUvIWufvbp1o/IpoOOTAN2/Aw5a3hDKjt7rkIcd9xnwCgHe hpHU5WuoCLeGCeV41LoS =f2d9 -END PGP SIGNATURE-
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
On 05/18/2011 08:52 PM, Vick Khera wrote: On Wed, May 18, 2011 at 2:30 PM, evilgh...@packetmail.net evilgh...@packetmail.net wrote: I'm certainly open for any suggestions for accommodating my goal of applying an IPv4 relayhost to non-IPv6 capable traffic if there is such a way to accomplish this goal with the existing configuration directives. What if you do this: eliminate the ability of your mail server to send SMTP over IPv4, possibly by removing any IPv4 address from it, or firewalling that ability away. Set up fallback_relay on this host so that all mail that did not make it on the first try goes to your relay host. There will be *some* IPv6 capable traffic sent that way as the result of transient failures, but it will be mostly messages that require IPv4. Limit THIS postfix to ipv6 exclusively. Set up a second instance with both ipv4 and ipv6. Set the fallback-relay to the second instance. inet_protocols = ipv6 fallback-relay = [::1]:25025 And on the second instance: inet_protocols = all relayhost = [your.ipv4.relay.host] And in master.cf: ::1:25025 inet - - - - - smtpd -- J.
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
Jeroen Geilman: On 05/18/2011 08:52 PM, Vick Khera wrote: On Wed, May 18, 2011 at 2:30 PM, evilgh...@packetmail.net evilgh...@packetmail.net wrote: I'm certainly open for any suggestions for accommodating my goal of applying an IPv4 relayhost to non-IPv6 capable traffic if there is such a way to accomplish this goal with the existing configuration directives. What if you do this: eliminate the ability of your mail server to send SMTP over IPv4, possibly by removing any IPv4 address from it, or firewalling that ability away. Set up fallback_relay on this host so that all mail that did not make it on the first try goes to your relay host. There will be *some* IPv6 capable traffic sent that way as the result of transient failures, but it will be mostly messages that require IPv4. Limit THIS postfix to ipv6 exclusively. Set up a second instance with both ipv4 and ipv6. Set the fallback-relay to the second instance. inet_protocols = ipv6 fallback-relay = [::1]:25025 And on the second instance: inet_protocols = all relayhost = [your.ipv4.relay.host] And in master.cf: ::1:25025 inet - - - - - smtpd This should be possible with one Postfix instance: /etc/postfix/main.cf: relayhost = /etc/postfix/master.cf: smtp unix - - n - - smtp -o inet_protocols=ipv6 -o smtp_fallback_relay=your.ipv4.relay.host Assuming that your.ipv4.relay.host is reachable via IPv6. No firewalling needed. Wietse
Re: Filtering spam with a partial pattern
On 5/18/2011 1:30 PM, Lima Union wrote: One last question regarding this, due that the amount of spam is huge I'd like to catch some of these messages, how should I configure Postfix in order to let this kind of messages (beginning with /^0-/ ) bypass all my checks (RBL,etc) and redirect them to my account to review them? is this possible? Thanks once again. You can do that, but you'll need to adjust your rules some. The general idea is you need to REDIRECT the mail and then whitelist it before subsequent rules reject it. We'll use a restriction class because postfix can't normally do two actions on one match. Something like: !Caution! http://www.postfix.org/SMTPD_ACCESS_README.html#danger # main.cf smtpd_restriction_classes = REDIRECT_OK REDIRECT_OK = check_sender_access regexp:$config_directory/maps/redirect.regexp permit # redirect.regexp /./ REDIRECT u...@example.com And in your sender.regexp, change the REJECT line to REDIRECT_OK # sender.regexp /^0-/ REDIRECT_OK And then you'll need to change your smtpd_recipient_restrictions to catch these before any other rules reject them. Something like: smtpd_recipient_restrictions = permit_mynetworks, # reject_unauth_destination should be your first reject reject_unauth_destination, # move your sender.regexp here, before any other reject* check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, # other stuff... reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_client_access hash:$config_directory/maps/smtpd_client_checks, check_helo_access hash:$config_directory/maps/smtpd_helo_checks, check_sender_access hash:$config_directory/maps/smtpd_sender_checks, check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, ... other exiting stuff...
Re: IPv4 relayhost only to be used for non-reachable IPv6 destinations?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/18/11 14:43, Wietse Venema wrote:
This should be possible with one Postfix
{SNIP}
No firewalling needed.
To bring closure to this thread and perhaps benefit others in the future:
As part of a defense-in-depth security strategy a strict IPv4 egress policy was
already in place at the firewall. This firewall policy only permitted egress
IPv4 TCP destined to port 25 from the relayhost.
The solution for enabling native IPv6 delivery without using the IPv4 relayhost
was simply s/relayhost/fallback_relay/ in combination with the existing IPv4
egress firewall policy.
IPv4 egress from Postfix will receive a TCP RST by the firewall and send mail to
the IPv4 address defined fallback_relay, which is permitted by the firewall.
IPv6 traffic destined to TCP port 25 is permitted so this will egress the
firewall without issue.
- From an additional overhead perspective there seems to be none for delivery to
IPv6 enabled MXes; IPv4 only will incur TCP RST from the firewall and behavior
relating to fallback_relay. In practice this seems to be almost instant with no
noticeable delays.
Vick, I owe you an overwhelming thank you for pointing me in the right
direction. I have now achieved the desired behavior/effect. Thank you to the
others who have participated in this thread as well.
- --
- -evilghost
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJN1CY8AAoJENgimYXu6xOHEqkP/3PGJKhz7RRz/iV6IR2M42qJ
LDXIENkC3CJ/kNi6wNxBhJ1Sn4OlGi0ioioeTkezNmsxhcNQucMOuraiFNVP/11B
ZiuuzLqb+g/xdSQXL69k+gm2x7fDIuI+bQkHrKcMCTat+v0Iz1StUpItrPdmW2ZW
6A9nQy/lUY9eUrpylhImS1HzelzU3viA/An4b7fQpt+XesWl7dcdl1t52iN0odOI
BZVOrPl5uZ7lFlIQX8tAQUpbbXqagiqrs9L3KMIR7iRrVOTAw/m/rt91ZjR8rqP5
LRqh0lFycpA4GJ0EPENuRgym8cM9ATqN41yTriQKQLIPuyiM8jmGgom+4XAgTGAv
JjiPFGHIuz2WM9yw7nON6eVy13Gh7Xr9A6XWxvk9OPyHlG3/HkHOOn+2JoQ+ENrJ
ndHE0EkMtRXhrOzQPaVG+9O++njMfDqvLEMOZoBlpSX9saFP9rty8Hm1WQzHvcP4
8Tq190iVoIYZ0/jap2UruhpfxRe4Qe7dmQySoqDuDT97XFULPvBYgPiLf0pCCgz6
Vq+4PNEpLtoCbS48ACg759uSMoqEGz8Ef4LzFfEBTU62esBSNnRI27qzWk8WdPHj
RNg7aTJdtvOqP/3OkMf13XxgYGD59pM//t4YMeXuWOO3kgEX0oVFRjQSFcs2p2CQ
ymqss285LiwjLxwAAN0h
=sXjM
-END PGP SIGNATURE-
Re: Filtering spam with a partial pattern
On Wed, May 18, 2011 at 5:01 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 5/18/2011 1:30 PM, Lima Union wrote: One last question regarding this, due that the amount of spam is huge I'd like to catch some of these messages, how should I configure Postfix in order to let this kind of messages (beginning with /^0-/ ) bypass all my checks (RBL,etc) and redirect them to my account to review them? is this possible? Thanks once again. You can do that, but you'll need to adjust your rules some. The general idea is you need to REDIRECT the mail and then whitelist it before subsequent rules reject it. We'll use a restriction class because postfix can't normally do two actions on one match. Something like: !Caution! http://www.postfix.org/SMTPD_ACCESS_README.html#danger # main.cf smtpd_restriction_classes = REDIRECT_OK REDIRECT_OK = check_sender_access regexp:$config_directory/maps/redirect.regexp permit # redirect.regexp /./ REDIRECT u...@example.com And in your sender.regexp, change the REJECT line to REDIRECT_OK # sender.regexp /^0-/ REDIRECT_OK And then you'll need to change your smtpd_recipient_restrictions to catch these before any other rules reject them. Something like: smtpd_recipient_restrictions = permit_mynetworks, # reject_unauth_destination should be your first reject reject_unauth_destination, # move your sender.regexp here, before any other reject* check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, # other stuff... reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_client_access hash:$config_directory/maps/smtpd_client_checks, check_helo_access hash:$config_directory/maps/smtpd_helo_checks, check_sender_access hash:$config_directory/maps/smtpd_sender_checks, check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, ... other exiting stuff... Noel, thank you very much for your explanation, I'll review and try it tomorrow. LU.
connect to smtp.host.com[1.2.3.4]:25: Permission denied
May 18 16:22:49 m postfix-in/smtp[7806]: connect to spam1.ihostexchange.net[66.46.182.95]:25: Permission denied May 18 16:22:49 m postfix-in/smtp[7806]: connect to spam2.ihostexchange.net[66.46.182.95]:25: Permission denied May 18 16:22:49 m postfix-in/smtp[7806]: 7081A1088FA: to=some...@somewhere.com, relay=none, delay=176728, delays=176727/0.03/1.2/0, dsn=4.4.1, status=deferred (connect to spam2.ihostexchange.net[66.46.182.95]:25: Permission denied) My google skills only showed this error relating to local filter scripts, etc. If the remote end were down, or blocking me, I believe all I should see is Connection Refused or similar. A Permission denied would usually point to a local firewall, I was able to connect to port 25 of the above address with telnet, so that should eliminate the firewall, and the system is working fine otherwise. What does this error mean? I get it for 3 domains, one of them being ASPMX3.GOOGLEMAIL.com, which I could also reach with telnet. -- Darek
Re: connect to smtp.host.com[1.2.3.4]:25: Permission denied
Darek M: May 18 16:22:49 m postfix-in/smtp[7806]: connect to spam1.ihostexchange.net[66.46.182.95]:25: Permission denied May 18 16:22:49 m postfix-in/smtp[7806]: connect to spam2.ihostexchange.net[66.46.182.95]:25: Permission denied May 18 16:22:49 m postfix-in/smtp[7806]: 7081A1088FA: to=some...@somewhere.com, relay=none, delay=176728, delays=176727/0.03/1.2/0, dsn=4.4.1, status=deferred (connect to spam2.ihostexchange.net[66.46.182.95]:25: Permission denied) My google skills only showed this error relating to local filter scripts, etc. If the remote end were down, or blocking me, I believe all I should see is Connection Refused or similar. A Permission denied would usually point to a local firewall, I was able to connect to port 25 of the above address with telnet, so that should eliminate the firewall, and the system is working fine otherwise. Check your SELINUX, APPARMOR, etc. security settings. Wietse
permit_mynetworks doesn't supersede reject_unauth_pipelining
I am having a problem that IMHO should be solved by the following in main.cf. I am using version 2.7.1 in Debian squeeze: smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_multi_recipient_bounce This says to me that if the host is listed in mynetworks, it should stop looking at the rest of the restrictions. This doesn't happen. The log complains about improper command pipelining, and the SMTP conversation sends a 503. I have done some testing, and have learned that reject_multi_recipient_bounce *IS* ignored if the source matches mynetworks, and takes effect if the source is not listed there. The client that's doing this is xymon, a monitoring application. It sends mail followed by quit and looks for a 220 response. The code is not flexible enough to do it properly, which means sending helo, waiting for a response, then sending some useful test command and waiting for another response. The test does pass, because the first thing the server sends is a 220. Am I running into expected behavior? I agree with the notion that unauthorized pipelining is bad, but what if I have a broken system that I am forced to use? Shouldn't I be able, through either permit_mynetworks or another mechanism, to allow that client to do it while denying everyone else? I am not hampered by what I've discovered, but I consider it to be a bug that should be fixed, because it might affect someone else. I filed a bug on this problem with the Debian project some time ago, but aside from one person who privately sent me a link to a general postfix howto for Ubuntu, I've gotten no response. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604707 Thanks, Shawn
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
On 5/18/2011 3:39 PM, Shawn Heisey wrote: I am having a problem that IMHO should be solved by the following in main.cf. I am using version 2.7.1 in Debian squeeze: smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_multi_recipient_bounce This says to me that if the host is listed in mynetworks, it should stop looking at the rest of the restrictions. This doesn't happen. The log complains about improper command pipelining, and the SMTP conversation sends a 503. I have done some testing, and have learned that reject_multi_recipient_bounce *IS* ignored if the source matches mynetworks, and takes effect if the source is not listed there. The client that's doing this is xymon, a monitoring application. It sends mail followed by quit and looks for a 220 response. The code is not flexible enough to do it properly, which means sending helo, waiting for a response, then sending some useful test command and waiting for another response. The test does pass, because the first thing the server sends is a 220. Am I running into expected behavior? I agree with the notion that unauthorized pipelining is bad, but what if I have a broken system that I am forced to use? Shouldn't I be able, through either permit_mynetworks or another mechanism, to allow that client to do it while denying everyone else? I am not hampered by what I've discovered, but I consider it to be a bug that should be fixed, because it might affect someone else. I filed a bug on this problem with the Debian project some time ago, but aside from one person who privately sent me a link to a general postfix howto for Ubuntu, I've gotten no response. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604707 Thanks, Shawn Show postconf -n (all of it, not just snips) and logging demonstrating the problem. -- Noel Jones
Posftix/Dovecot deliver
Hi all,
I have a problem with my dovecot/postfix configuration:
here is my dovecot -n
# 1.2.16: /etc/dovecot.conf
Warning: fd limit 128 is lower than what Dovecot can use under full
load (more than 768). Either grow the limit or change
login_max_processes_count and max_mail_processes settings
# OS: OpenBSD 4.9 i386 nfs
base_dir: /var/dovecot/
log_path: /var/log/dovecot
protocols: imaps pop3s
login_dir: /var/dovecot/login
login_executable(default): /usr/local/libexec/dovecot/imap-login
login_executable(imap): /usr/local/libexec/dovecot/imap-login
login_executable(pop3): /usr/local/libexec/dovecot/pop3-login
login_user: _dovecot
mail_location: maildir:/var/www/datos/correo/foobar.com.ar/%n:LAYOUT=fs
mail_debug: yes
mail_nfs_storage: yes
mail_nfs_index: yes
mbox_write_locks: fcntl
mail_executable(default): /usr/local/libexec/dovecot/imap
mail_executable(imap): /usr/local/libexec/dovecot/imap
mail_executable(pop3): /usr/local/libexec/dovecot/pop3
mail_plugin_dir(default): /usr/local/lib/dovecot/imap
mail_plugin_dir(imap): /usr/local/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3
imap_client_workarounds(default): delay-newmail outlook-idle
netscape-eoh tb-extra-mailbox-sep
imap_client_workarounds(imap): delay-newmail outlook-idle netscape-eoh
tb-extra-mailbox-sep
imap_client_workarounds(pop3):
pop3_client_workarounds(default):
pop3_client_workarounds(imap):
pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh
lda:
mail_plugins: sieve
postmaster_address: postmas...@foobar.com.ar
log_path: /var/log/dovecot-deliver-errors.log
info_log_path: /var/log/dovecot-deliver.log
auth default:
mechanisms: login plain
verbose: yes
debug: yes
debug_passwords: yes
passdb:
driver: bsdauth
userdb: driver: static
args: uid=vmail gid=vmail
home=/var/www/datos/correo/foobar.com.ar/%n, allow_all_users=yes
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: _postfix
group: _postfix
master:
path: /var/dovecot/auth-master
mode: 384
user: vmail
group: vmail
plugin:
sieve_global_dir: /var/sieve
sieve_global_path: /var/sieve/global-default.sieve
sieve: /var/sieve/%n.sieve
I use bsdauth to system users auth againts Active-Directory, and I use
dovecot to deliver the mails, my postfix is attach provide by postfinger tool.
The problem is I don't see any process like this:
pipe -n dovecot -t unix flags=DRhu user=vmail
/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}
And in the dovecot log I don't see anything, but in maillog I have:
May 18 09:49:35 FOOBAR-0010 postfix/local[16584]: 8808D26125:
to=gonza...@foobar.com.ar, relay=local, delay=0.92,
delays=0.91/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
Is like postfix don't use dovecot to deliver anyway.
The mail it's not in the mailbox, what is wrong? any hint? the
storage is a NFS with centos.
Regards
postfix
Description: Binary data
Re: Posftix/Dovecot deliver
* Gonzalo Rodriguez gonz...@sepp0.com.ar: Hi all, I have a problem with my dovecot/postfix configuration: ... May 18 09:49:35 FOOBAR-0010 postfix/local[16584]: 8808D26125: to=gonza...@foobar.com.ar, relay=local, delay=0.92, delays=0.91/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) foobar.com.ar is considered local (in mydestination), thus local_transport is being used. Probably virtual_mailbox_domains and mydestination (check what it is set to!) are overlapping. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
On 5/18/2011 2:57 PM, Noel Jones wrote:
On 5/18/2011 3:39 PM, Shawn Heisey wrote:
I am having a problem that IMHO should be solved by the
following in main.cf. I am using version 2.7.1 in Debian squeeze:
smtpd_data_restrictions =
permit_mynetworks,
reject_unauth_pipelining,
reject_multi_recipient_bounce
This says to me that if the host is listed in mynetworks, it
should stop looking at the rest of the restrictions. This
doesn't happen. The log complains about improper command
pipelining, and the SMTP conversation sends a 503. I have done
some testing, and have learned that
reject_multi_recipient_bounce *IS* ignored if the source
matches mynetworks, and takes effect if the source is not
listed there.
Show postconf -n (all of it, not just snips) and logging
demonstrating the problem.
Here it is. I sanitized the actual hostname and public IP addresses.
This serves as a mail relay for our internal mail system, no mail is
handled locally.
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
body_checks = pcre:/etc/postfix/body_checks
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
disable_vrfy_command = yes
header_checks = pcre:/etc/postfix/header_checks
inet_interfaces = all
mailbox_command = procmail -a $EXTENSION
mailbox_size_limit = 524288000
message_size_limit = 52428800
myhostname = server.example.com
mynetworks = 127.0.0.0/8, [:::127.0.0.0]/104, [::1]/128, 10.0.0.0/8,
172.16.0.0/12, 192.168.0.0/16, 1.2.3.4/24
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relay_domains = hash:/etc/postfix/local_domains
relay_recipient_maps = hash:/etc/postfix/relay_recipients
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_connection_count_limit = 20
smtpd_client_connection_rate_limit = 60
smtpd_client_restrictions = permit_mynetworks, check_client_access
regexp:/etc/postfix/client_regexp, check_client_access
cidr:/etc/postfix/client_access, reject_unknown_client_hostname
smtpd_data_restrictions = permit_mynetworks,
reject_unauth_pipelining, reject_multi_recipient_bounce
smtpd_delay_reject = yes
smtpd_error_sleep_time = 15
smtpd_hard_error_limit = 5
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = permit_mynetworks, sleep 2,
check_recipient_access hash:/etc/postfix/recipient_access,
reject_non_fqdn_recipient, reject_unauth_destination,
reject_unknown_recipient_domain, reject_unlisted_recipient,
check_client_access cidr:/etc/postfix/policyd_access,
check_policy_service inet:127.0.0.1:12525
smtpd_sender_restrictions = permit_mynetworks, check_sender_access
hash:/etc/postfix/sender_access, reject_non_fqdn_sender,
reject_unknown_sender_domain
smtpd_soft_error_limit = 2
smtpd_tls_cert_file = /etc/ssl/certs/local/wildcard.combined.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
May 18 16:19:29 nexus2 postfix/smtpd[18002]: connect from
monitor.example.com[10.2.1.39]
May 18 16:19:29 nexus2 postfix/smtpd[18002]: improper command pipelining
after MAIL from monitor.example.com[10.2.1.39]
May 18 16:19:29 nexus2 postfix/smtpd[18002]: disconnect from
monitor.example.com[10.2.1.39]
Xymon's status page for smtp on this server has the following on it:
220 nexus2.mainstreamdata.com ESMTP Postfix (Debian/GNU)
503 5.5.1 Error: send HELO/EHLO first
221 2.0.0 Bye
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
Shawn Heisey: smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_multi_recipient_bounce permit_mynetworks has NO EFFECT in smtpd_data_restrictions, because SMTP is a multi-recipient protocol. Wietse
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
Wietse Venema: Shawn Heisey: smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_multi_recipient_bounce permit_mynetworks has NO EFFECT in smtpd_data_restrictions, because SMTP is a multi-recipient protocol. Sorry, that is bogus. Wietse
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
Shawn Heisey: smtpd_delay_reject = yes This will apply the client, helo, and sender restrictions AFTER Postfix receives the RCPT TO command. In other words, Postfix never applies restrictions when the client connects, when the client send EHLO, or when the client sends the MAIL FROM command. May 18 16:19:29 nexus2 postfix/smtpd[18002]: connect from monitor.example.com[10.2.1.39] May 18 16:19:29 nexus2 postfix/smtpd[18002]: improper command pipelining after MAIL from monitor.example.com[10.2.1.39] This applies restrictions before RCPT TO, so you reported the wrong Postfix configuration, or you have parameter settings in master.cf that you should also report about. Wietse
Re: Posftix/Dovecot deliver
On Wed, 2011-05-18 at 19:05:11 -0300, Gonzalo Rodriguez wrote: May 18 09:49:35 FOOBAR-0010 postfix/local[16584]: 8808D26125: to=gonza...@foobar.com.ar, relay=local, delay=0.92, delays=0.91/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Where is 'foobar.com.ar' listed in your configuration? If you must obscure hostnames/IPs, please do so consistently. -- Sahil Tandon sa...@freebsd.org
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
On 5/18/2011 5:09 PM, Wietse Venema wrote: This applies restrictions before RCPT TO, so you reported the wrong Postfix configuration, or you have parameter settings in master.cf that you should also report about. It's the right configuration. Just in case, I made sure I was on the right server and got it again: http://pastebin.com/6vGTnVcC I actually do hope that this is a mistake on my part, so I can get it corrected quickly and not trouble you any further. Here's the master.cf file: http://pastebin.com/UZPVfzB5 It is pretty much Debian default except for three additional sections which should not take effect on initial port 25 connection -- unless my understanding is wrong, which is very possible. I got these additional sections from spamfilter howtos on the Internet. Of the various check_ files mentioned in main.cf, some of them are empty, except for the following, with a sample of what they contain. All of the ones using the hash method have a current .db created with postmap. sender_access: some.good.address\@virgin.net OK transport: example.com smtp:[10.2.1.133] client_regexp: /everythingchannelnetseminars\.com$/REJECT Go away or I shall taunt you a second time. virtual: ali...@example.net us...@example.com,us...@example.com local_domains: example.com 1 relay_recipients (this file is quite large): us...@example.com ok us...@example.com ok
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
Shawn Heisey: On 5/18/2011 5:09 PM, Wietse Venema wrote: This applies restrictions before RCPT TO, so you reported the wrong Postfix configuration, or you have parameter settings in master.cf that you should also report about. ... I actually do hope that this is a mistake on my part, so I can get it corrected quickly and not trouble you any further. Here's the master.cf file: http://pastebin.com/UZPVfzB5 In master.cf you have smtpd_delay_reject = no. With this, Postfix will apply smtpd_sender_restrictions when it receives the MAIL FROM command, instead of waiting until the RCPT TO command. In your log, Postfix rejects the MAIL FROM command. This means you have some pipelining check in some smtpd_sender_restrictions setting, perhaps via some access table lookup. Finally, with all the anonymization you haven't proven that the client IP address actually matches mynetworks. For that, you'd have to turn on verbose logging (debug_peer_list = 127.0.0.1, or whatever the IP). That will show all the restrictions that Postfix evaluates. With my own system, permit_mynetworks does override reject_unauth_pipelining, so I guess you either aren't matching mynetworks, or you have given incorrect confguration info, or the Debian maintainer introduced an error. Below are examples for Postfix versions 2.9 (the latest) and 2.5 (the oldest supported release). Wietse % postconf mail_version mail_version = 2.9-20110501 % postconf smtpd_delay_reject smtpd_sender_restrictions smtpd_delay_reject = no smtpd_sender_restrictions = permit_mynetworks reject_unauth_pipelining % od -cb /tmp/pipelined 000h e l o l o c a l h o s t \r \n 150 145 154 157 040 154 157 143 141 154 150 157 163 164 015 012 020m a i l f r o m : w i e t s 155 141 151 154 040 146 162 157 155 072 074 167 151 145 164 163 040e @ l o c a l h o s t \r \n r c 145 100 154 157 143 141 154 150 157 163 164 076 015 012 162 143 060p t t o : w i e t s e @ l o 160 164 040 164 157 072 074 167 151 145 164 163 145 100 154 157 100c a l h o s t \r \n d a t a \r \n 143 141 154 150 157 163 164 076 015 012 144 141 164 141 015 012 120b l a h \r \n . \r \n q u i t \r \n 142 154 141 150 015 012 056 015 012 161 165 151 164 015 012 137 % nc -w 5 127.0.0.1 25 /tmp/pipelined 220 tail.porcupine.org ESMTP Postfix 250 tail.porcupine.org 250 2.1.0 Ok 250 2.1.5 Ok 354 End data with CRLF.CRLF 250 2.0.0 Ok: queued as 3QZXv46m0vznjlT 221 2.0.0 Bye % tail /var/log/maillog May 18 20:14:08 tail postfix/smtpd[7496]: connect from localhost[127.0.0.1] May 18 20:14:08 tail postfix/smtpd[7496]: improper command pipelining after HELO from localhost[127.0.0.1]: mail from:wietse@localhost\r\nrcpt to:wietse@localhost\r\ndata\r\nblah\r\n.\r\nquit\r\n May 18 20:14:08 tail postfix/smtpd[7496]: 3QZXv46m0vznjlT: client=localhost[127.0.0.1] May 18 20:14:08 tail postfix/cleanup[7499]: 3QZXv46m0vznjlT: message-id=3qzxv46m0vzn...@tail.porcupine.org May 18 20:14:08 tail postfix/smtpd[7496]: disconnect from localhost[127.0.0.1] May 18 20:14:08 tail postfix/qmgr[1819]: 3QZXv46m0vznjlT: from=wie...@localhost.porcupine.org, size=318, nrcpt=1 (queue active) May 18 20:14:09 tail postfix/local[7500]: 3QZXv46m0vznjlT: to=wie...@localhost.porcupine.org, orig_to=wietse@localhost, relay=local, delay=0.1, delays=0.02/0.04/0/0.03, dsn=2.0.0, status=sent (delivered to mailbox) May 18 20:14:09 tail postfix/qmgr[1819]: 3QZXv46m0vznjlT: removed % postconf mail_version mail_version = 2.5.13 % postconf smtpd_delay_reject smtpd_sender_restrictions smtpd_delay_reject = no smtpd_sender_restrictions = permit_mynetworks reject_unauth_pipelining % od -cb /tmp/pipelined 000h e l o l o c a l h o s t \r \n 150 145 154 157 040 154 157 143 141 154 150 157 163 164 015 012 020m a i l f r o m : w i e t s 155 141 151 154 040 146 162 157 155 072 074 167 151 145 164 163 040e @ l o c a l h o s t \r \n r c 145 100 154 157 143 141 154 150 157 163 164 076 015 012 162 143 060p t t o : w i e t s e @ l o 160 164 040 164 157 072 074 167 151 145 164 163 145 100 154 157 100c a l h o s t \r \n d a t a \r \n 143 141 154 150 157 163 164 076 015 012 144 141 164 141 015 012 120b l a h \r \n . \r \n q u i t \r \n 142 154 141 150 015 012 056 015 012 161 165 151 164 015 012 137 % nc -w 5 127.0.0.1 25 /tmp/pipelined 220 tail.porcupine.org ESMTP Postfix 250 tail.porcupine.org 250 2.1.0 Ok 250 2.1.5 Ok 354 End data with CRLF.CRLF 250 2.0.0 Ok: queued as
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
Wietse Venema: With my own system, permit_mynetworks does override reject_unauth_pipelining, so I guess you either aren't matching mynetworks, or you have given incorrect confguration info, or the Debian maintainer introduced an error. Below are examples for Postfix versions 2.9 (the latest) and 2.5 (the oldest supported release). I should add that when I remove permit_mynetworks from smtpd_sender_restrictions, Postfix 2.9 rejects the same mail thusly: % postconf mail_version mail_version = 2.9-20110501 % postconf smtpd_delay_reject smtpd_sender_restrictions smtpd_delay_reject = no smtpd_sender_restrictions = reject_unauth_pipelining % nc -w 5 127.0.0.1 25 /tmp/pipelined 220 tail.porcupine.org ESMTP Postfix 250 tail.porcupine.org 503 5.5.0 wietse@localhost: Sender address rejected: Improper use of SMTP command pipelining 503 5.5.1 Error: need MAIL command 503 5.5.1 Error: need RCPT command 502 5.5.2 Error: command not recognized 502 5.5.2 Error: command not recognized 221 2.0.0 Bye % tail /var/log/maillog May 18 20:28:11 tail postfix/smtpd[15880]: connect from localhost[127.0.0.1] May 18 20:28:11 tail postfix/smtpd[15880]: improper command pipelining after HELO from localhost[127.0.0.1]: mail from:wietse@localhost\r\nrcpt to:wietse@localhost\r\ndata\r\nblah\r\n.\r\nquit\r\n May 18 20:28:11 tail postfix/smtpd[15880]: NOQUEUE: reject: MAIL from localhost[127.0.0.1]: 503 5.5.0 wietse@localhost: Sender address rejected: Improper use of SMTP command pipelining; from=wietse@localhost proto=SMTP helo=localhost May 18 20:28:11 tail postfix/smtpd[15880]: disconnect from localhost[127.0.0.1] Postfix 2.5 also rejects the mail: % postconf mail_version mail_version = 2.5.13 % postconf smtpd_delay_reject smtpd_sender_restrictions smtpd_delay_reject = no smtpd_sender_restrictions = reject_unauth_pipelining % nc -w 5 127.0.0.1 25 /tmp/pipelined 220 tail.porcupine.org ESMTP Postfix 250 tail.porcupine.org 503 5.5.0 wietse@localhost: Sender address rejected: Improper use of SMTP command pipelining 503 5.5.1 Error: need MAIL command 503 5.5.1 Error: need RCPT command 502 5.5.2 Error: command not recognized 502 5.5.2 Error: command not recognized 221 2.0.0 Bye % tail /var/log/maillog May 18 20:31:41 tail postfix/smtpd[21193]: connect from localhost[127.0.0.1] May 18 20:31:41 tail postfix/smtpd[21193]: NOQUEUE: reject: MAIL from localhost[127.0.0.1]: 503 5.5.0 wietse@localhost: Sender address rejected: Improper use of SMTP command pipelining; from=wietse@localhost proto=SMTP helo=localhost May 18 20:31:41 tail postfix/smtpd[21193]: disconnect from localhost[127.0.0.1] Wietse
Re: permit_mynetworks doesn't supersede reject_unauth_pipelining
On 5/18/2011 6:27 PM, Wietse Venema wrote: In master.cf you have smtpd_delay_reject = no. With this, Postfix will apply smtpd_sender_restrictions when it receives the MAIL FROM command, instead of waiting until the RCPT TO command. In your log, Postfix rejects the MAIL FROM command. This means you have some pipelining check in some smtpd_sender_restrictions setting, perhaps via some access table lookup. Finally, with all the anonymization you haven't proven that the client IP address actually matches mynetworks. For that, you'd have to turn on verbose logging (debug_peer_list = 127.0.0.1, or whatever the IP). That will show all the restrictions that Postfix evaluates. I commented out the extra delay options in master.cf. I don't think that's affecting it anyway, as those only listen on localhost, and on ports other than 25. The only things I anonymized were my hostnames and the *public* IPs on mynetworks, everything else was left alone. The 10.2.1.39 address in the previous log was the actual address, and should match 10.0.0.0/8 from mynetworks. Below is a peer debug log at level 9 with those delay options commented. The only thing I anonymized was the the hostnames, IP addresses are actual. It did the same thing when I added 10.2.1.39 to mynetworks. To create this, I telnetted from the monitor server to postfix on port 25, typed in mail, then disconnected the telnet. If I send a properly formatted mail command instead of the single word, it still sends the 503. In this log, I left the postfix hostname alone, but I changed the hostname of the monitor server. May 18 18:49:19 nexus2 postfix/smtpd[24852]: connect from monitor.example.com[10.2.1.39] May 18 18:49:19 nexus2 postfix/smtpd[24852]: match_hostname: monitor.example.com ~? 127.0.0.0/8 May 18 18:49:19 nexus2 postfix/smtpd[24852]: match_hostaddr: 10.2.1.39 ~? 127.0.0.0/8 May 18 18:49:19 nexus2 postfix/smtpd[24852]: match_hostname: monitor.example.com ~? 10.0.0.0/8 May 18 18:49:19 nexus2 postfix/smtpd[24852]: match_hostaddr: 10.2.1.39 ~? 10.0.0.0/8 May 18 18:49:19 nexus2 postfix/smtpd[24852]: monitor.example.com[10.2.1.39]: 220 nexus2.example.com ESMTP Postfix (Debian/GNU) May 18 18:49:19 nexus2 postfix/smtpd[24852]: watchdog_pat: 0x7fe596441400 May 18 18:49:19 nexus2 postfix/smtpd[24852]: vstream_fflush_some: fd 24 flush 58 May 18 18:49:21 nexus2 postfix/smtpd[24852]: vstream_buf_get_ready: fd 24 got 6 May 18 18:49:21 nexus2 postfix/smtpd[24852]: monitor.example.com[10.2.1.39]: mail May 18 18:49:21 nexus2 postfix/smtpd[24852]: monitor.example.com[10.2.1.39]: 503 5.5.1 Error: send HELO/EHLO first May 18 18:49:21 nexus2 postfix/smtpd[24852]: watchdog_pat: 0x7fe596441400 May 18 18:49:21 nexus2 postfix/smtpd[24852]: vstream_fflush_some: fd 24 flush 39 May 18 18:49:23 nexus2 postfix/smtpd[24852]: smtp_get: EOF May 18 18:49:23 nexus2 postfix/smtpd[24852]: match_hostname: monitor.example.com ~? 127.0.0.0/8 May 18 18:49:23 nexus2 postfix/smtpd[24852]: match_hostaddr: 10.2.1.39 ~? 127.0.0.0/8 May 18 18:49:23 nexus2 postfix/smtpd[24852]: match_hostname: monitor.example.com ~? 10.0.0.0/8 May 18 18:49:23 nexus2 postfix/smtpd[24852]: match_hostaddr: 10.2.1.39 ~? 10.0.0.0/8 May 18 18:49:23 nexus2 postfix/smtpd[24852]: lost connection after MAIL from monitor.example.com[10.2.1.39] May 18 18:49:23 nexus2 postfix/smtpd[24852]: disconnect from monitor.example.com[10.2.1.39] I'm glad to hear that you aren't having this problem, which gives me some hope that it's isolated to my specific config, the debian package, or 2.7.1. Thanks, Shawn
Re: Custom Controlling Defer Queue!
On Wed, May 18, 2011 at 9:02 PM, Wietse Venema wie...@porcupine.org wrote: afshin afzali: Postfix has no support for senders to specify do not deliver this message after X (i.e. no per-message expiration time). Of course, for transports such as SMS or voice I need to use custom scrips to wrap postfix to appropriate managers. In these scripts I will check time-frame parameter to decide if the message should let to go or not. Wietse: Fine. then you can do the content inspection there, too. Otherwise, see http://www.postfix.org/CONTENT_INSPECTION_README.html. Here are some tips if you use the pipe(8) delivery agent for SMS deliveries: - If the message is spam, report successful delivery (exit status 0) to Postfix, and Postfix will throw the message away. - If the message is too old, report successful delivery (exit status 0) to Postfix, and Postfix will throw the message away. - If the message is delivered, report successful delivery (exit status 0) to Postfix, and Postfix will throw the message away. - Otherwise, if the message can't be delivered, report a temporary error (exit status 75) to Postfix, and Postfix will try again later as configured with minimal/maximal_backoff_time. Wietse Thanks for your help afshin
