correct placement for fqrdns.regexp
Morning List. Sorry for the trivial question. I was just wondering where the best place for the fqrdns.regexp check_client_access. I see on the systems I have inherited, it is in the smtpd_client_restrictions which makes sense however it is placed before the permit_sasl_authenticated line, which does not make sense as this would reject the connection, even if they use smtp authentication. Please advise. Thanks Tom
Re: relocated_maps feature causing backscatter - SOLVED
I found the problem by investigating the address verification traffic between Postfix and Exchange. I noticed Postfix was not verifying recent addresses at all so I figured Postfix must be caching verification results somewhere. Indeed, there is a /var/lib/verify_cache.db and it contained the 7 bouncing addresses as well as the 15 rejecting addresses. But the bouncing ones appear to have been verified as OK in the past. Removing the database and restarting Postfix fixed it. Thanks, Pim
reject email sending to certain MX
Hello, is it possible to configure postfix not to send email with recipient domains to certain MX host? - Joe
Re: reject email sending to certain MX
Am 15.12.2011 12:44, schrieb Joe Wong: Hello, is it possible to configure postfix not to send email with recipient domains to certain MX host? - Joe perhaps you need stuff like this check_recipient_mx_access type:table Search the specified access(5) database for the MX hosts for the RCPT TO domain, and execute the corresponding action. Note: a result of OK is not allowed for safety reasons. Instead, use DUNNO in order to exclude specific hosts from blacklists. This feature is available in Postfix 2.1 and later. you might have to mix it with some recipient policy other *mx_access are exist too -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Gonzo Fernandez: I'm not sure I'm understanding the log file info you would like. I tried doing grep search for 8A2993E3003B on all log files under /var/log/* and only found the following line to show up: Dec 11 05:31:27 batch-ca4-02 postfix/cleanup[31691]: warning: 8A2993E3003B: read timeout on cleanup socket Can you please be more specific? Thanks for your patience and help. PLEASE show ALL logfile records for message 8A2993E3003B. The pickup or smtpd record may be in a different file than the cleanup record. Wietse Gonzo Fernandez Network Engineer On Dec 14, 2011, at 4:12 PM, Wietse Venema wrote: Gonzo Fernandez: Hi Wietse, I apologize for the confusion. Here is the result of the following command. The mail arrived via pickup (local). PLEASE show the logfile records that I asked for. Wietse # grep 8A2993E3003B /var/log/maillog Dec 11 05:31:27 batch-ca4-02 postfix/cleanup[31691]: warning: 8A2993E3003B: read timeout on cleanup socket Gonzo Fernandez Network Engineer On Dec 13, 2011, at 12:35 PM, Wietse Venema wrote: Gonzo Fernandez: Dec 11 05:09:19 batch-ca4-02 postfix/cleanup[31691]: warning: timeout on cleanup socket while reading input attribute name Dec 11 05:31:27 batch-ca4-02 postfix/cleanup[31691]: warning: 8A2993E3003B: read timeout on cleanup socket Did the email arrive via smtpd (network), or via pickup (local)? $ grep 8A2993E3003B /the/log/file Wietse
Re: warning: problem talking to service private/scache: Operation timed out
Sahil Tandon: These warnings appear a few times daily, and are sometimes followed by: warning: disabling connection caching This occurs on a slightly older Postfix (2.7.1). The machine receives mail from the internet and relays everything (that it does not reject) to an internal mail store which is listed as relayhost. I have not How many SMTP client processes? Wietse
smtp status code
Hi all I need to understand why bounced emails sometimes don't have smtp status code and is it available to add code for them? And also about emails that are delivered to mailbox they don't have status code ? Regards
Re: smtp status code
Amira Othman: Hi all I need to understand why bounced emails sometimes don't have smtp status code and is it available to add code for them? And also about emails that are delivered to mailbox they don't have status code ? According to RFC 3461: (i) For DSNs resulting from attempts to relay a message to one or more recipients via SMTP, the Diagnostic-Code MUST be supplied for each of those recipients. The diagnostic-type subfield will be smtp. See section 9.2 of this document for a description of the smtp diagnostic-code. When there is an SMTP session, Postfix will report the SMTP status code that it received from the remote SMTP server. When there is no SMTP session, Postfix will not report a fake SMTP status code. Instead, it will return a different diagnostic-type. Wietse
Re: reject email sending to certain MX
On 12/15/2011 5:44 AM, Joe Wong wrote: Hello, is it possible to configure postfix not to send email with recipient domains to certain MX host? - Joe http://www.postfix.org/postconf.5.html#check_recipient_mx_access
Re: correct placement for fqrdns.regexp
On 12/15/2011 2:30 AM, Tom Kinghorn wrote: Morning List. Sorry for the trivial question. I was just wondering where the best place for the fqrdns.regexp check_client_access. I see on the systems I have inherited, it is in the smtpd_client_restrictions which makes sense however it is placed before the permit_sasl_authenticated line, which does not make sense as this would reject the connection, even if they use smtp authentication. Yes, the check should be after permit_mynetworks and permit_sasl_authenticated. Something like: smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_reverse_client_hostname_access regexp:/etc/postfix/fqrdns.regexp -- Noel Jones
using postscreen on port 25
I'd like to use postcreen as some kind of spam protection. According to documentation * postscreen(8) should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen(8) is used on the port 25 service, while MUA clients submit mail via the submission service (port 587) which normally requires client authentication. But we have clients, that send mails on both port 25 and 587. I really cannot use postscreen? I don't understand why exactly. What will happen if I use it? Tomas
Re: logging whitelisted IPs
On Thursday 15 December 2011 01:34:53 Tomas Macek wrote: I'd like to have an whitelist based on hash:file table, for example this http://www.howtoforge.com/how-to-whitelist-hosts- ip-addresses-in-postfix - it's simple. When I have a line 1.2.3.4 REJECT You were blacklisted it's logged including reason of rejecting (of course). But when I have a line 1.2.3.4 OK You were whitelisted it's not logged at all and I don't know why the IP was able to sent a mail through the mailserver and why. Is there any possibility to achieve that? Set a class in smtpd_restriction_classes and return that as your lookup result: main.cf contains: smtpd_restriction_classes = [ ... ] whitelisted whitelisted = warn whitelisted, permit Your client access lookup contains: 1.2.3.4 whitelisted In general I'd suggest that need for whitelisting indicates that your restrictions might be too aggressive, such as using reject_rbl_client with SORBS or Spamcop. More aggressive DNSBL services should only be used in scoring, such as with postscreen(8), for most sites. A large whitelist is hard to maintain properly, worse than a large blacklist. So, you might need to step back and reevaluate your restrictions. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: using postscreen on port 25
Tomas Macek: I'd like to use postcreen as some kind of spam protection. According to documentation * postscreen(8) should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen(8) is used on the port 25 service, while MUA clients submit mail via the submission service (port 587) which normally requires client authentication. This is the recommended way to separate MTA-to-MTA traffic from MUA-to-MTA traffic. But we have clients, that send mails on both port 25 and 587. Convert them to use port 587, or whitelist them if they have an IP address in a known range. I really cannot use postscreen? I don't understand why exactly. What will happen if I use it? You will be using the software in an unsupported manner. Therefore, no-one including myself will be able to help you fix the problem. Wietse
Re: using postscreen on port 25
On Thursday 15 December 2011 07:53:35 Tomas Macek wrote: I'd like to use postcreen as some kind of spam protection. According to documentation * postscreen(8) should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen(8) is used on the port 25 service, while MUA clients submit mail via the submission service (port 587) which normally requires client authentication. But we have clients, that send mails on both port 25 and 587. I really cannot use postscreen? I don't understand why exactly. What will happen if I use it? You might reject some MUA clients, and if using after-220 tests, you will be getting phone calls from confused users. The old default of most MUAs to use port 25 was wrong, and it is now coming back to haunt you. That said, you have workarounds: - Use a different IP address for port 25 MX and submission mail - Communicate with users, the need to change to 587; postscreen implementation can be a fiendishly effective way to do that. :) However you choose to do it, you must now separate your user submission mailstream from your MX mailstream. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: using postscreen on port 25
On Thu, Dec 15, 2011 at 08:19:18AM -0600, /dev/rob0 wrote: On Thursday 15 December 2011 07:53:35 Tomas Macek wrote: I'd like to use postcreen as some kind of spam protection. According to documentation * postscreen(8) should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen(8) is used on the port 25 service, while MUA clients submit mail via the submission service (port 587) which normally requires client authentication. But we have clients, that send mails on both port 25 and 587. I really cannot use postscreen? I don't understand why exactly. What will happen if I use it? You might reject some MUA clients, and if using after-220 tests, you will be getting phone calls from confused users. Btw: I am thinking to use postscreen with mail submission server as well since its rbl check seems to be better in performance than using smtpd's one. Since I want also block some of the IPs even in case of mail submission (eg: user's account is stolen etc) with an own hosted BL for this purpose, I guess it's not a problem to use postscreen in case of mail submission, if I don't use other features of postscreen too much - at least not for mail submission. Is it a good idea at all?
Re: using postscreen on port 25
G?bor L?n?rt: On Thu, Dec 15, 2011 at 08:19:18AM -0600, /dev/rob0 wrote: On Thursday 15 December 2011 07:53:35 Tomas Macek wrote: I'd like to use postcreen as some kind of spam protection. According to documentation * postscreen(8) should not be used on SMTP ports that receive mail from end-user clients (MUAs). In a typical deployment, postscreen(8) is used on the port 25 service, while MUA clients submit mail via the submission service (port 587) which normally requires client authentication. But we have clients, that send mails on both port 25 and 587. I really cannot use postscreen? I don't understand why exactly. What will happen if I use it? You might reject some MUA clients, and if using after-220 tests, you will be getting phone calls from confused users. Btw: I am thinking to use postscreen with mail submission server as well since its rbl check seems to be better in performance than using smtpd's one. Since I want also block some of the IPs even in case of mail submission (eg: user's account is stolen etc) with an own hosted BL for this purpose, I guess it's not a problem to use postscreen in case of mail submission, if I don't use other features of postscreen too much - at least not for mail submission. Is it a good idea at all? I'll be happy to discuss how to make postscreen better to distinguish MTA-to-MTA traffic from other traffic. I will decline the opportunity to give a blow-by-blow presentation of how postscreen feature X will suck when it is used with MUA traffic, and how it could be made to suck less. To stop spam caused by a botted client or phished password, a postfwd or policyd rate limit seems more appropriate to me. This will catch the bot or spammer before the IP address is blacklisted. Wietse
Possibility to store all incoming mail
Hi Postfix Gurus! Is there a possibility to store all incoming mail in a central folder at postfix level. I am trying to find a nasty bug in one of our backend systems which corrupts mail data before they arrive in the users's inbox. Therefore i would like to store all imcoming mail unaltered before postfix sends it there, for debugging purposes, preferrably incluing the envelope. If possible, a pointer to the right bit of documentation should be enough. tia, Michael
Re: using postscreen on port 25
On Thursday 15 December 2011 08:24:51 Gábor Lénárt wrote: On Thu, Dec 15, 2011 at 08:19:18AM -0600, /dev/rob0 wrote: On Thursday 15 December 2011 07:53:35 Tomas Macek wrote: But we have clients, that send mails on both port 25 and 587. I really cannot use postscreen? I don't understand why exactly. What will happen if I use it? You might reject some MUA clients, and if using after-220 tests, you will be getting phone calls from confused users. Btw: I am thinking to use postscreen with mail submission server as well since its rbl check seems to be better in performance than using smtpd's one. The difference is in how it is done. smtpd checks each DNSBL in sequence, while postscreen hits them all in parallel. The benefit is that a score can be calculated from all results, rather than smtpd's absolute yes-or-no decisions. Since I want also block some of the IPs even in case of mail submission (eg: user's account is stolen etc) with an own hosted BL for this purpose, Not a good example. If a user's credentials are used for spamming, your best option is to revoke those credentials. A local DNSBL isn't going to block those effectively. Even if it did, I think the smtpd's way of doing it would make sense; you don't want anything from addresses in your local DNSBL. I guess it's not a problem to use postscreen in case of mail submission, if I don't use other features of postscreen too much - at least not for mail submission. Is it a good idea at all? I would guess not. There are better ways to deal with the issues mentioned here. There are a lot of MUA implementations, many of them not so good, much like spam zombies. Since postscreen was made to fight zombies, it does not sound like a good thing to put between the server and your own users. I'd echo what Wietse said about policy services, and also suggest content filtering on your submission stream. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: using postscreen on port 25
/dev/rob0: The old default of most MUAs to use port 25 was wrong, and it is now coming back to haunt you. That said, you have workarounds: - Use a different IP address for port 25 MX and submission mail I've added this one to the documentation (a dedicated, non-MX, submission service on port 25). Wietse - Communicate with users, the need to change to 587; postscreen implementation can be a fiendishly effective way to do that. :) However you choose to do it, you must now separate your user submission mailstream from your MX mailstream. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Possibility to store all incoming mail
On Thu, Dec 15, 2011 at 04:30:34PM CET, Michael Weissenbacher m...@dermichi.com said: Hi Postfix Gurus! Is there a possibility to store all incoming mail in a central folder at postfix level. I am trying to find a nasty bug in one of our backend systems which corrupts mail data before they arrive in the users's inbox. Therefore i would like to store all imcoming mail unaltered before postfix sends it there, for debugging purposes, preferrably incluing the envelope. If possible, a pointer to the right bit of documentation should be enough. You can do this with recpients_bcc_maps
Re: using postscreen on port 25
On Thu, Dec 15, 2011 at 09:35:19AM -0600, /dev/rob0 wrote: I am thinking to use postscreen with mail submission server as well since its rbl check seems to be better in performance than using smtpd's one. The difference is in how it is done. smtpd checks each DNSBL in sequence, while postscreen hits them all in parallel. The benefit is that a score can be calculated from all results, rather than smtpd's absolute yes-or-no decisions. Since I want also block some of the IPs even in case of mail submission (eg: user's account is stolen etc) with an own hosted BL for this purpose, Not a good example. If a user's credentials are used for spamming, your best option is to revoke those credentials. A local DNSBL isn't going to block those effectively. Well, my idea based on the fact that it seems IPs abusing one of my mail users (eg: password is stolen) to send spam will likely (in my experience) come back again later with _another_ abused mail user (or trying to ESMTP auth for hours even if error is returned because of the revoked credentials). So what I wanted is blocking the IP as it's part of a botnet network or so: I don't want to block _only_ (but I do that too, of course!) my mail user (and inform her/him to change password, educate about phishing, etc etc) but the IP too to avoid further mail user abusements with another ones, or trying to auth with the same user (without success though) thus wasting my resources. But yes, I understand your (and Wietse's) advices, thanks. I would guess not. There are better ways to deal with the issues mentioned here. There are a lot of MUA implementations, many of them not so good, much like spam zombies. Since postscreen was made to fight zombies, it does not sound like a good thing to put between the server and your own users. Ok, I see your point, however I would only use the BL lookup feature for mail submission, the other features are only used on tcp/25 on MX servers and not at mail submission service (and they are different servers as well). I'd echo what Wietse said about policy services, and also suggest content filtering on your submission stream. Surely, I don't want to replace those with my idea.
Re: sender_dependent_relay_maps: what if sender does not match?
OK, I set notify_classes = resource, software, 2bounce
I tested with various bad email addresses in various scenarios.
The undeliverable notification always is sent to either:
the user's gmail mailbox.
the postmaster.
Here's how it works:
If localhost config is incorrect, then
postmaster gets the notification.
I fix it.
else
localhost is correctly configured.
Wordpress site sends to an invalid address.
/var/log/mail.log shows successful delivery to gmail.
user's gmail gets the notification, but not postmaster.
If I need to fix it, then
billable hours
This is exactly what I want.
Thanks again.
Regards,
Mike Donovan
On 12/14/2011 05:06 PM, Wietse Venema wrote:
Michael Donovan:
Resolved!
That did the trick!
Thanks.
Don't forget to set notify_classes as described in my reply, because
otherwise undeliverable outbound mail may be lost (the notification
has the null sender address, which does not match your per-sender
table).
My original reply was incomplete and talked inbound mail. In reality
all undeliverable mail notification has the null sender address.
By including 2bounce in the notify_classes setting, a copy of
the undeliverable notification will be sent to postmaster.
You will want to test what happens when you send a mail to a bad
address from wordpress. It would be bad if the mail would go down
a blackhole.
Wietse
A little explanation:
This Postfix is for a Debian LAMP server that hosts mainly Wordpress blogs.
All of our customers have their mail set up with Google Apps,
so we don't need Postfix as an MX for their domains.
They all have mail addresses like u...@theirdomain.com rather than
u...@gmail.com
Each blog runs under a different Linux user account, rather than
www-data. (Apache mpm-itk)
I don't want Postfix to ever send mail directly, always go through the
correct gmail account.
Basically, I'm making Postfix act like a multi-user Thunderbird email
client.
I know there are plugins for Wordpress that can do this directly without
involving Postfix,
but I am trying to make life easier for my customers. We also have
non-Wordpress apps that use php_mail(),
and even an ancient perl cgi script that can't talk TLS.
For anyone who wants to do this using gmail as the transport, here's
what I did on Debian Squeeze.
Install Postfix. I chose Satellite system
Generate the cacert.pem:
# cat /usr/lib/ssl/certs/Equifax_Secure_CA.pem /etc/postfix/cacert.pem
# cat /usr/lib/ssl/certs/Thawte_Premium_Server_CA.pem
/etc/postfix/cacert.pem
I don't think you need the Thawte_Premium one anymore, but it doesn't
hurt anything.
/etc/postfix/main.cf:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
default_transport = error:you can't go there from here
html_directory = /usr/share/doc/postfix/html
inet_interfaces = loopback-only
inet_protocols = ipv4
mailbox_command = procmail -a $EXTENSION
mailbox_size_limit = 0
mydestination = $myhostname, localhost.localdomain, localhost
myhostname = myhost.mydomain.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
sender_dependent_default_transport_maps = hash:/etc/postfix/sender_transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
/etc/mailname:
myhost.mydomain.net
/etc/postfix/sender_transport
us...@myhost.mydomain.net??? smtp:[smtp.gmail.com]:587
us...@myhost.mydomain.net??? smtp:[smtp.gmail.com]:587
/etc/postfix/sasl_passwd
us...@myhost.mydomain.net??? gmailus...@somedomain.com:gmailpassword1
us...@myhost.mydomain.net??? gmailus...@anotherdomain.org:gmailpassword2
Hash the files with postmap:
# postmap sender_transport
# postmap sasl_passwd
Restart:
# /etc/init.d/postfix restart
user1 and user2 send mail through their respective gmail accounts.
user3 is a linux user, but not in the transport list, so any mail he sends
gets bounced back to his local mailbox /var/spool/mail/user3
Regards,
Mike Donovan
On 12/14/2011 01:18 PM, Wietse Venema wrote:
Michael Donovan:
What I want is for Postfix to NOT send the mail [when the sender
does not match sender_dependent_relayhost_maps] at all. Instead
immediately bounce it back to user3 as undeliverable.
This is easier with sender_dependent_default_transport_maps:
What follows
Re: Possibility to store all incoming mail
Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug).
Re: reject email sending to certain MX
Hi, I tried, it works but not the way I would like to implement. Say sender sent a email to 3 recipients, one of them hit the rule. What I want is sender will not get any bounce but the offending recipient will simply dropped, while the other 2 will still get the email. Is this possible? - Joe On Thu, Dec 15, 2011 at 9:37 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 12/15/2011 5:44 AM, Joe Wong wrote: Hello, is it possible to configure postfix not to send email with recipient domains to certain MX host? - Joe http://www.postfix.org/postconf.5.html#check_recipient_mx_access
Re: Possibility to store all incoming mail
On 15/12/2011 16:24, Michael Weissenbacher wrote: Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug). Set up a user on the local system, and bcc to that. That way it won't go out through the smarthost. Mark -- Sent from my Babbage Difference Engine 2 http://mark.goodge.co.uk
Re: Possibility to store all incoming mail (pre-content_filter)
schrieb Mark Goodge: On 15/12/2011 16:24, Michael Weissenbacher wrote: Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug). Set up a user on the local system, and bcc to that. That way it won't go out through the smarthost. Hm, but this still won't bypass amavis which i call with content_filter = smtp-amavis:[127.0.0.1]:10024 If i understand http://www.postfix.org/FILTER_README.html correctly. Maybe i can put a custom filter which logs all mail BEFORE the amavis filter? tia, Michael
RE: Possibility to store all incoming mail (pre-content_filter)
It should be delivered via the local transport, just set -o content_filter= under local in master.cf to override. Kind Regards, James Day (IT Engineer) Ontraq Limited Tel: 01245 265100 Fax: 01245 265700 Web: www.ontraq.com -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Michael Weissenbacher Sent: 15 December 2011 16:58 To: postfix-users@postfix.org Subject: Re: Possibility to store all incoming mail (pre-content_filter) schrieb Mark Goodge: On 15/12/2011 16:24, Michael Weissenbacher wrote: Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug). Set up a user on the local system, and bcc to that. That way it won't go out through the smarthost. Hm, but this still won't bypass amavis which i call with content_filter = smtp-amavis:[127.0.0.1]:10024 If i understand http://www.postfix.org/FILTER_README.html correctly. Maybe i can put a custom filter which logs all mail BEFORE the amavis filter? tia, Michael
Re: Possibility to store all incoming mail (pre-content_filter)
On 15/12/2011 16:58, Michael Weissenbacher wrote: schrieb Mark Goodge: On 15/12/2011 16:24, Michael Weissenbacher wrote: Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug). Set up a user on the local system, and bcc to that. That way it won't go out through the smarthost. Hm, but this still won't bypass amavis which i call with content_filter = smtp-amavis:[127.0.0.1]:10024 It's unlikely that amavis is your problem. And if it is, you can diagnose that simply by turning amavis off temporarily to see if that makes the problem go away. Mark -- Sent from my Babbage Difference Engine 2 http://mark.goodge.co.uk
Re: reject email sending to certain MX
On 12/15/2011 10:34 AM, Joe Wong wrote: Hi, I tried, it works but not the way I would like to implement. Say sender sent a email to 3 recipients, one of them hit the rule. What I want is sender will not get any bounce but the offending recipient will simply dropped, while the other 2 will still get the email. Is this possible? - Joe Discarding mail is almost always the wrong choice. Don't use the DISCARD action with check_recipient_mx_access map, as that will discard the mail for ALL recipients, not just the offending recipient. You could add a transport map entry for offending destinations, but that operates on recipient domains, not the MX, so not exactly what you've asked for. # transport blacklisted.example.com discard: Or you could use your firewall to reroute offending IP destinations to a local smtp-sink process. -- Noel Jones
Re: Possibility to store all incoming mail (pre-content_filter)
Original Message Subject: Re: Possibility to store all incoming mail (pre-content_filter) From: Mark Goodge m...@good-stuff.co.uk To: postfix-users@postfix.org Date: Thu Dec 15 2011 18:04:06 GMT+0100 (CET) On 15/12/2011 16:58, Michael Weissenbacher wrote: schrieb Mark Goodge: On 15/12/2011 16:24, Michael Weissenbacher wrote: Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug). Set up a user on the local system, and bcc to that. That way it won't go out through the smarthost. Hm, but this still won't bypass amavis which i call with content_filter = smtp-amavis:[127.0.0.1]:10024 It's unlikely that amavis is your problem. And if it is, you can diagnose that simply by turning amavis off temporarily to see if that makes the problem go away. Yeah, unlikely but possible. In fact the mail passes through 2 filters before being returned to postfix: postfix:25 - amavis:10024 - apache-james:10025 - postfix:10026 - smarthost All i can tell is that some mails (like 1 out of 2) get corrupted in the process and end up being unusable. I cannot disable amavis completely as spam hell would break lose. I cannot disable apache-james because it contains some custom filters. The most likely culprit here is apache-james because it contains some custom code. But if i disable it i cannot tell which mails would have triggered the bug and which ones didn't. That's why i want to store mails at postfix:25 before they get altered. cheers, Michael
Re: Possibility to store all incoming mail (pre-content_filter)
What about tcpdump capture?, then you can reasemble te tcp stream and see whats going on. You can save the capture to a file, then with wireshark you can reasemble the tcpstream looking to those emails like in postfix. You can capture traffic before your mta gets it. Regards. Saludos Ing. Alfonso Alejandro Reyes Jimenez Coordinador de Seguridad - SASI E-mail: aare...@scitum.com.mx Telefono: 91507489 Movil: (044) 55 85 81 04 62 - Mensaje original - De: Michael Weissenbacher [mailto:m...@dermichi.com] Enviado: Thursday, December 15, 2011 11:14 AM Para: Postfix users postfix-users@postfix.org Asunto: Re: Possibility to store all incoming mail (pre-content_filter) Original Message Subject: Re: Possibility to store all incoming mail (pre-content_filter) From: Mark Goodge m...@good-stuff.co.uk To: postfix-users@postfix.org Date: Thu Dec 15 2011 18:04:06 GMT+0100 (CET) On 15/12/2011 16:58, Michael Weissenbacher wrote: schrieb Mark Goodge: On 15/12/2011 16:24, Michael Weissenbacher wrote: Hi! You can do this with recpients_bcc_maps Well, as far as i know this just adds a bcc address to the message and as a result the mail would still pass through amavis and through the smarthost before leaving the system, thus it would get altered (and destroyed if i hit the bug). Set up a user on the local system, and bcc to that. That way it won't go out through the smarthost. Hm, but this still won't bypass amavis which i call with content_filter = smtp-amavis:[127.0.0.1]:10024 It's unlikely that amavis is your problem. And if it is, you can diagnose that simply by turning amavis off temporarily to see if that makes the problem go away. Yeah, unlikely but possible. In fact the mail passes through 2 filters before being returned to postfix: postfix:25 - amavis:10024 - apache-james:10025 - postfix:10026 - smarthost All i can tell is that some mails (like 1 out of 2) get corrupted in the process and end up being unusable. I cannot disable amavis completely as spam hell would break lose. I cannot disable apache-james because it contains some custom filters. The most likely culprit here is apache-james because it contains some custom code. But if i disable it i cannot tell which mails would have triggered the bug and which ones didn't. That's why i want to store mails at postfix:25 before they get altered. cheers, Michael
Re: Possibility to store all incoming mail (pre-content_filter)
schrieb Alfonso Alejandro Reyes Jimenez: What about tcpdump capture?, then you can reasemble te tcp stream and see whats going on. You can save the capture to a file, then with wireshark you can reasemble the tcpstream looking to those emails like in postfix. You can capture traffic before your mta gets it. Would be possible, but i think it's a little scary to dig through gigabytes of raw network packets just to isolate a single tcp mail conversation. I hope there is an easy (postfix) way :-)
Re: Possibility to store all incoming mail (pre-content_filter)
On 12/15/2011 11:14 AM, Michael Weissenbacher wrote: Yeah, unlikely but possible. In fact the mail passes through 2 filters before being returned to postfix: postfix:25 - amavis:10024 - apache-james:10025 - postfix:10026 - smarthost All i can tell is that some mails (like 1 out of 2) get corrupted in the process and end up being unusable. This sounds like one of the very rare cases where the obscure http://www.postfix.org/postconf.5.html#dont_remove option might be helpful. something like # main.cf dont_remove = 1 hash_queue_names = deferred, defer, saved If you expect to have more than a few hundred thousand files, maybe also: hash_queue_depth = 2 Caution: this will fill up your hard drive. Caution: this is a debugging tool with limited warranty. The advantage is that if you can identify a corrupted mail, you'll be able to directly compare the before-filter and after-filter queue files, and all envelope information is saved for (fairly) easy resubmission. -- Noel Jones
Re: Possibility to store all incoming mail (pre-content_filter)
schrieb James Day: It should be delivered via the local transport, just set -o content_filter= under local in master.cf to override. Clever. Tried it, but somehow it doesn't work. Mail still passes through all the filters first. Maybe it's because of my odd filter chain: postfix:25 - amavis:10024 - apache-james:10025 - postfix:10026 - local
Re: Possibility to store all incoming mail (pre-content_filter)
Michael, Yeah, unlikely but possible. In fact the mail passes through 2 filters before being returned to postfix: postfix:25 - amavis:10024 - apache-james:10025 - postfix:10026 - smarthost All i can tell is that some mails (like 1 out of 2) get corrupted in the process and end up being unusable. I cannot disable amavis completely as spam hell would break lose. I cannot disable apache-james because it contains some custom filters. The most likely culprit here is apache-james because it contains some custom code. But if i disable it i cannot tell which mails would have triggered the bug and which ones didn't. That's why i want to store mails at postfix:25 before they get altered. You may enable archive quarantine in your pre-queue amavis, e.g.: $archive_quarantine_method = 'local:archive-%m'; $archive_quarantine_to = 'archive-quarantine'; # default to be able to compare a corrupted message to what was seen by amavisd. This would not help if a problem lies in stages prior to or in amavisd, but at least it can help troubleshooting later stages (SMTP output from amavisd and apache-james). Mark
Re: Possibility to store all incoming mail (pre-content_filter)
You may enable archive quarantine in your pre-queue amavis, e.g.: $archive_quarantine_method = 'local:archive-%m'; $archive_quarantine_to = 'archive-quarantine'; # default to be able to compare a corrupted message to what was seen by amavisd. This would not help if a problem lies in stages prior to or in amavisd, but at least it can help troubleshooting later stages (SMTP output from amavisd and apache-james). Mark Perfect, this will definately help! thanks, Michael
Re: Possibility to store all incoming mail (pre-content_filter)
schrieb Noel Jones: This sounds like one of the very rare cases where the obscure http://www.postfix.org/postconf.5.html#dont_remove option might be helpful. something like # main.cf dont_remove = 1 hash_queue_names = deferred, defer, saved If you expect to have more than a few hundred thousand files, maybe also: hash_queue_depth = 2 Caution: this will fill up your hard drive. Caution: this is a debugging tool with limited warranty. The advantage is that if you can identify a corrupted mail, you'll be able to directly compare the before-filter and after-filter queue files, and all envelope information is saved for (fairly) easy resubmission. -- Noel Jones Thanks Noel, this is exactly what i was searching for! Very much appreciated. Just one last question: what is the best way to inspect postfix's queue files? They look odd in vim :-) cheers, Michael
Re: Possibility to store all incoming mail (pre-content_filter)
I wrote: Just one last question: what is the best way to inspect postfix's queue files? They look odd in vim :-) OMG i'm sorry, i just found out about postcat [1] myself, silly me. [1] http://www.postfix.org/postcat.1.html Thanks for your help! cheers, Michael
Re: Possibility to store all incoming mail (pre-content_filter)
On 12/15/2011 12:00 PM, Michael Weissenbacher wrote: schrieb Noel Jones: This sounds like one of the very rare cases where the obscure http://www.postfix.org/postconf.5.html#dont_remove option might be helpful. something like # main.cf dont_remove = 1 hash_queue_names = deferred, defer, saved If you expect to have more than a few hundred thousand files, maybe also: hash_queue_depth = 2 Caution: this will fill up your hard drive. Caution: this is a debugging tool with limited warranty. The advantage is that if you can identify a corrupted mail, you'll be able to directly compare the before-filter and after-filter queue files, and all envelope information is saved for (fairly) easy resubmission. -- Noel Jones Thanks Noel, this is exactly what i was searching for! Very much appreciated. Just one last question: what is the best way to inspect postfix's queue files? They look odd in vim :-) cheers, Michael The previously supplied link suggests using the postcat(1) command. http://www.postfix.org/postconf.5.html#dont_remove http://www.postfix.org/postcat.1.html -- Noel Jones
Re: Possibility to store all incoming mail (pre-content_filter)
schrieb Noel Jones: The previously supplied link suggests using the postcat(1) command. http://www.postfix.org/postconf.5.html#dont_remove http://www.postfix.org/postcat.1.html -- Noel Jones Noel, you have been MOST helpful, thanks again! This substantinates my choice of postfix as my fave MTA :-) cheers, Michael
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Hi guys, So far no luck searching for 8A2993E3003B. :( The system is heavily used. From what I understand this machine relays all mail to our main mx server and we have a lot of email being relayed daily. The strange part is that it works all week up until late Saturday/Sunday in the AM hours. Here are all log files for mail. I have searched all log files for the specific string but no luck. Performing another search for all warning, error, fatal, panic on all previous log files has given me a bit more info. The following is certain errors I have noticed pop up more often than not: # egrep (warning|error|fatal|panic): /var/log/maillog* | more /var/log/maillog:Dec 11 05:09:19 batch-ca4-02 postfix/cleanup[31691]: warning: timeout on cleanup socket while reading input attribute name /var/log/maillog:Dec 11 05:31:27 batch-ca4-02 postfix/cleanup[31691]: warning: 8A2993E3003B: read timeout on cleanup socket /var/log/maillog:Dec 13 12:04:13 batch-ca4-02 postfix/postdrop[15153]: warning: uid=0: Illegal seek /var/log/maillog:Dec 13 04:04:13 batch-ca4-02 postfix/sendmail[15152]: fatal: root(0): queue file write error /var/log/maillog:Dec 14 12:03:07 batch-ca4-02 postfix/postdrop[12285]: warning: uid=0: Illegal seek /var/log/maillog:Dec 14 04:03:07 batch-ca4-02 postfix/sendmail[12280]: fatal: root(0): queue file write error /var/log/maillog:Dec 15 12:03:07 batch-ca4-02 postfix/postdrop[21744]: warning: uid=0: Illegal seek /var/log/maillog:Dec 15 04:03:07 batch-ca4-02 postfix/sendmail[21739]: fatal: root(0): queue file write error /var/log/maillog.1:Dec 4 05:18:29 batch-ca4-02 postfix/cleanup[6555]: warning: timeout on cleanup socket while reading input attribute name /var/log/maillog.1:Dec 4 05:45:13 batch-ca4-02 postfix/cleanup[6555]: warning: 0433D3E3003A: read timeout on cleanup socket /var/log/maillog:Dec 15 12:03:07 batch-ca4-02 postfix/postdrop[21744]: warning: uid=0: Illegal seek /var/log/maillog:Dec 15 04:03:07 batch-ca4-02 postfix/sendmail[21739]: fatal: root(0): queue file write error /var/log/maillog.1:Dec 5 12:03:47 batch-ca4-02 postfix/postdrop[4667]: warning: uid=0: Illegal seek /var/log/maillog.1:Dec 5 04:03:47 batch-ca4-02 postfix/sendmail[4660]: fatal: root(0): queue file write error (I tried searching for 0433D3E3003A as well but to no avail.) # ls -ld /var/log/maillog* -rw--- 1 root root 194889523 Dec 15 10:48 /var/log/maillog -rw--- 1 root root 370337428 Dec 11 04:04 /var/log/maillog.1 -rw--- 1 root root 644886321 Dec 4 04:03 /var/log/maillog.2 -rw--- 1 root root 250479845 Nov 27 04:03 /var/log/maillog.3 -rw--- 1 root root 11139266 Nov 20 04:02 /var/log/maillog.4 I also commented out fallback relay as it was active but left blank in master.cf. Not sure if that has anything to do with it but better safe than sorry. # When relaying mail as backup MX, disable fallback_relay to avoid MX loops relay unix - - n - - smtp # -o fallback_relay= I'm going to wait and see what happens this weekend and when it happens again I'll try to get more info for you. Thanks again for the help. Gonzo Fernandez Network Engineer On Dec 14, 2011, at 11:01 PM, Lorens Kockum wrote: On Wed, Dec 14, 2011 at 05:43:58PM -0800, Gonzo Fernandez wrote: I'm not sure I'm understanding the log file info you would like. I tried doing grep search for 8A2993E3003B on all log files under /var/log/* and only found the following line to show up: Dec 11 05:31:27 batch-ca4-02 postfix/cleanup[31691]: warning: 8A2993E3003B: read timeout on cleanup socket Can you please be more specific? Thanks for your patience and help. Your log line is dated 5 AM plus a little. Maybe your log file got rotated (that usually happens at 4 or 5 AM). The reason that your grep on all log files did not yield the result is probably that the rotated log files are zipped. zgrep (at least my version) behaves nicely when the files aren't zipped, so zgrep 8A2993E3003B /var/log/maillog* should yield the information Wietse was asking for. If not, an ls -ld /var/log/maillog* would be useful. Is this a very heavily used system?
Re: Restrict authenticated senders with domain/email SQL lookup table
On 15/12/2011, at 5:28 PM, Noel Jones wrote: Thanks again... what if i just wanted postfix to check a mysql-based list of approved sending email addresses and/or domains? e.g. NOT associate it with a SASL login but has an approved sender list. e.g. all SASL login's would be able to send from all of the domains/addresses on the list? (I'm thinking of a specific situation where i would need this). Simon That's easy enough to do with a check_sender_access map. Assuming an MSA (user submission only, no general incoming mail), something as simple as: smtpd_sender_restrictions = check_sender_access hash:/path/to/allowed_senders reject With allowed_senders table something like us...@example.com OK example.org OK Any sender not on the approved list gets rejected. Do this in smtpd_sender_restrictions to avoid possible open relay accidents that could occur if you do this test in smtpd_recipients_restrictions. These restrictions could also be put into master.cf as -o options on the submission or smtps services. Thanks Noel, What if i needed todo this with SASL-authenticated senders... This is my current setup: smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_sender_domain, permit Can you assist me to get the order correct here? I would like permit_sasl_authenticated as well as check_sender_access (from a mysql table) if possible... Many thanks! Simon
Re: Restrict authenticated senders with domain/email SQL lookup table
On 12/15/2011 2:12 PM, Simon wrote: On 15/12/2011, at 5:28 PM, Noel Jones wrote: Thanks again... what if i just wanted postfix to check a mysql-based list of approved sending email addresses and/or domains? e.g. NOT associate it with a SASL login but has an approved sender list. e.g. all SASL login's would be able to send from all of the domains/addresses on the list? (I'm thinking of a specific situation where i would need this). Simon That's easy enough to do with a check_sender_access map. Assuming an MSA (user submission only, no general incoming mail), something as simple as: smtpd_sender_restrictions = check_sender_access hash:/path/to/allowed_senders reject With allowed_senders table something like us...@example.com OK example.org OK Any sender not on the approved list gets rejected. Do this in smtpd_sender_restrictions to avoid possible open relay accidents that could occur if you do this test in smtpd_recipients_restrictions. These restrictions could also be put into master.cf as -o options on the submission or smtps services. Thanks Noel, What if i needed todo this with SASL-authenticated senders... This is my current setup: smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unknown_sender_domain, permit Can you assist me to get the order correct here? I would like permit_sasl_authenticated as well as check_sender_access (from a mysql table) if possible... Many thanks! Simon What I already wrote is will work for any users, but it must not be used on a general MX. If this is your general MX, your sasl users need to submit mail on submission port 587 rather than the MTA-to-MTA port 25. You can modify the master.cf submission service with something like: submission smtpd -o smtpd_sender_restrictions=check_sender_access,hash:/path/to/allowed_sender,reject -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject You can use any table type supported by your postfix in place of the hash: shown above, *sql is fine. -- Noel Jones
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Gonzo Fernandez: Hi guys, So far no luck searching for 8A2993E3003B. :( Can you then show some other pickup records? Wietse
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Wietse Venema: Gonzo Fernandez: Hi guys, So far no luck searching for 8A2993E3003B. :( Can you then show some other pickup records? In particular I am looking for NON-ERROR LOGGING from the pickup daemon around the time of the incident. Wietse
blocked by Barracuda
I run my own domain off a dynamic IP but all my postfix uses relayhost set to smtp.myisp. This works 99.9% of the time but I have encountered two recipients who use Barracuda's that block email from my domain. The bounce includes (reason: 554 Service unavailable; Client host [smtp.myisp] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=mydomainIP). The Barracuda is looking at the sender IP (mydomainIP) instead of the relayhost IP. Is there another way to run a mailserver? Is there a standard I can read?
Re: blocked by Barracuda
On Thursday, December 15, 2011 at 21:41:51 UTC, bjloc...@lockie.ca confabulated: I run my own domain off a dynamic IP but all my postfix uses relayhost set to smtp.myisp. This works 99.9% of the time but I have encountered two recipients who use Barracuda's that block email from my domain. The bounce includes (reason: 554 Service unavailable; Client host [smtp.myisp] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=mydomainIP). The Barracuda is looking at the sender IP (mydomainIP) instead of the relayhost IP. Is there another way to run a mailserver? Is there a standard I can read? My guess, whoever is running the Barracuda appliance has the deep header parsing option turned on and should turn it off. -- If at first you don't succeed, so much for skydiving.
Re: blocked by Barracuda
On Thu, Dec 15, 2011 at 04:41:51PM -0500, James wrote: I run my own domain off a dynamic IP but all my postfix uses relayhost set to smtp.myisp. This works 99.9% of the time but I have encountered two recipients who use Barracuda's that block email from my domain. The bounce includes (reason: 554 Service unavailable; Client host [smtp.myisp] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=mydomainIP). The Barracuda is looking at the sender IP (mydomainIP) instead of the relayhost IP. Is there another way to run a mailserver? Is there a standard I can read? I would contact Barracuda to find out why your mail reputation is bad. Then you may be able to figure out what to do about it. You setup sounds fine and you are not really having a postfix problem. Regards, Ken
Re: blocked by Barracuda
Am 15.12.2011 22:41, schrieb James: I run my own domain off a dynamic IP but all my postfix uses relayhost set to smtp.myisp. This works 99.9% of the time but I have encountered two recipients who use Barracuda's that block email from my domain. The bounce includes (reason: 554 Service unavailable; Client host [smtp.myisp] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=mydomainIP). The Barracuda is looking at the sender IP (mydomainIP) instead of the relayhost IP. Is there another way to run a mailserver? Is there a standard I can read? this is mostly missconfiguration seen the before , but rare you can try to delete your dny ip from the header read .i.e for ideas http://blog.tenak.net/2011/04/2011-04-dont-send-client-ip-postfix.html you might mix it up with a special transport only matching that recipient domain i did some solution like this in master.cf transport buggyipcheck unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/buggyip_header_check /etc/postfix/buggyip_header_check /^Received: / IGNORE /etc/postfix/transport buggycheckdomain.de buggyipcheck: -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
On Thu, Dec 15, 2011 at 11:49:35AM -0800, Gonzo Fernandez wrote: /var/log/maillog:Dec 14 04:03:07 batch-ca4-02 postfix/sendmail[12280]: fatal: root(0): queue file write error /var/log/maillog:Dec 15 12:03:07 batch-ca4-02 postfix/postdrop[21744]: warning: uid=0: Illegal seek In addition to what Wietse asked for in another mail just now, do look at the output of the commands mount dmesg That should show if there is a hardware problem. If it is not, then is it not possible that the 8A2993E3003B you are worrying about is a locally submitted mail from some system daemon (like logwatch) that is too big for your configured system limits? The times on the error messages make me suspect some kind of cron job. See: http://www.electrictoolbox.com/logwatch-postfix-sendmail-errors/ http://www.cyberciti.biz/tips/linux-unix-posttfix-mutt-illegal-seek-error.html 8A2993E3003B would then be a minor consequence of your main problem, which is mail freezing up over weekends. To diagnose that problem, it would be interesting to grep on a queue id that was correctly queued, like (from an earlier mail): Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: warning: 884643E30022: message has been queued for 1 days Since mails such as those have been correctly queued, there should be a wealth of information about when and how and why it's staying in the queue so long. HTH
Re: blocked by Barracuda
Am 15.12.2011 22:54, schrieb Robert Schetterer: you can try to delete your dny ip from the header read .i.e for ideas http://blog.tenak.net/2011/04/2011-04-dont-send-client-ip-postfix.html you can not because you are not in the position to change any received from of the target-server the problem is a 5.1 barracuda firmware and a braindead admin enabling deep header inspection - in firmware = 5.1 this option doesn no longer exists in this way and is in a smater form enabled by default NEW to version 5.1 (Beta) Mail Processing New Trusted Forwarder behavior: For IP addresses in the Trusted Forwarder list, the Barracuda Spam Virus Firewall performs reputation and IP checks on the first non-trusted forwarder IP address. If multiple IP addresses are in the list, the first received header IP that is not trusted undergoes reputation and IP checks. signature.asc Description: OpenPGP digital signature
Re: blocked by Barracuda
Am 15.12.2011 22:54, schrieb Robert Schetterer: Am 15.12.2011 22:41, schrieb James: I run my own domain off a dynamic IP but all my postfix uses relayhost set to smtp.myisp. This works 99.9% of the time but I have encountered two recipients who use Barracuda's that block email from my domain. The bounce includes (reason: 554 Service unavailable; Client host [smtp.myisp] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=mydomainIP). The Barracuda is looking at the sender IP (mydomainIP) instead of the relayhost IP. Is there another way to run a mailserver? Is there a standard I can read? this is mostly missconfiguration seen the before , but rare you can try to delete your dny ip from the header read .i.e for ideas http://blog.tenak.net/2011/04/2011-04-dont-send-client-ip-postfix.html you might mix it up with a special transport only matching that recipient domain i did some solution like this in master.cf transport buggyipcheck unix - - n - - smtp -o smtp_header_checks=regexp:/etc/postfix/buggyip_header_check /etc/postfix/buggyip_header_check /^Received: / IGNORE /etc/postfix/transport buggycheckdomain.de buggyipcheck: sorry, for sure your postmaster ( if you arent it yourself) from the isp smtp relayhost has to do it for you if not possible, call the recipient fixing his broken baracuda setup -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: blocked by Barracuda
On Thursday 15 December 2011 15:50:42 Duane Hill wrote: On Thursday, December 15, 2011 at 21:41:51 UTC, bjloc...@lockie.ca confabulated: I run my own domain off a dynamic IP but all my postfix uses relayhost set to smtp.myisp. This works 99.9% of the time but I have encountered two recipients who use Barracuda's that block email from my domain. The bounce includes (reason: 554 Service unavailable; Client host [smtp.myisp] blocked using Barracuda Reputation; Not your host ... http://bbl.barracudacentral.com/q.cgi?ip=mydomainIP). ... but blocking because of your IP address The Barracuda is looking at the sender IP (mydomainIP) instead of the relayhost IP. Is there another way to run a mailserver? Sounds like you are doing it right. If you were to try to send mail using your ISP-provided address to this place, they'd probably block that as well. Is there a standard I can read? My guess, whoever is running the Barracuda appliance has the deep header parsing option turned on and should turn it off. Barracuda Deep header parsing is a disaster. A large percentage of legitimate mail from end users on dynamic IP addresses (most people are in that group) will be blocked. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: warning: problem talking to service private/scache: Operation timed out
On Thu, 2011-12-15 at 07:09:15 -0500, Wietse Venema wrote: Sahil Tandon: These warnings appear a few times daily, and are sometimes followed by: warning: disabling connection caching This occurs on a slightly older Postfix (2.7.1). The machine receives mail from the internet and relays everything (that it does not reject) to an internal mail store which is listed as relayhost. I have not How many SMTP client processes? The related master.cf lines are below; default_process_limit remains 100. smtp unix - - n - - smtp relay unix - - n - - smtp -o fallback_relay= -- Sahil Tandon
Re: warning: problem talking to service private/scache: Operation timed out
Sahil Tandon: Dec 14 02:00:13 mx0 postfix/smtp[52172]: 82A9D8FC0A: to=r...@example.org, relay=internal.example.org[ip_address]:25, delay=1.8, delays=0.66/0/0/1.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 47E9B1065670) Dec 14 02:00:18 mx0 postfix/smtp[52172]: warning: problem talking to service private/scache: Operation timed out Dec 14 02:00:25 mx0 postfix/smtp[52172]: warning: problem talking to service private/scache: Operation timed out Dec 14 02:00:25 mx0 postfix/smtp[52172]: warning: disabling connection caching The default connection_cache_protocol_timeout setting is 5 seconds, which explains the time between the first attempts. There is an extra 1-second delay between retry attempts, which explains the longer time between the second attempt and giving up. So the connection cache client side seems to work as intended. Most of the information sent over the protocol is of the same kind that Postfix sends between daemons all the time: domain names, IP addresses, and numbers. The only distinguishing property of the protocol is that it also sends file descriptors, just like postscreen-smtpd does (and postscreen-tlsproxy). And indeed I recall that I ran into a bizarre bug with FreeBSD 7.1 file descriptor passing, as I was developing the first versions of postscreen in 2009. This comment is from postscreen: /* * Closing the smtp_client_fd here triggers a FreeBSD 7.1 kernel bug * where smtp-source sometimes sees the connection being closed after * it has already received the real SMTP server's 220 greeting! */ This is about closing the remote SMTP client socket in postscreen, after postscreen had made the kernel request to send that socket to smtpd. The postscreen workaround was to wait until the smtpd process closes the file descriptor over which the remote SMTP client socket was received, before closing the remote SMTP client socket in postscreen. It's 2.5 years later now, and I do not recall if this happened on my uniprocessor laptop or on my multiprocessor workstation. In the scache client, the file descriptor sending operation is always preceeded and followed by a data read. For this reason we can't be triggering the same bug that postscreen triggered, but maybe there is another bug in FreeBSD file descriptor passing code. Wietse
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Lorens, Thanks for your info about the mailbox size limit. I do have log watch running and have not received any emails. Took care of that by expanding the size limit to 20MB. As for doing a grep search on 884643E30022 (The ID that said stuck in queue for 1 day), here is the output: # egrep 884643E30022 /var/log/maillog Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: warning: 884643E30022: message has been queued for 1 days Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: 884643E30022: uid=500 from=x...@.com Dec 12 10:08:50 batch-ca4-02 postfix/cleanup[26937]: 884643E30022: message-id=20111212180850.884643E30022@batch-ca4-02 Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_active_feed: incoming/884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_message_alloc: active 884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: 884643E30022: from=x...@.com, size=1503, nrcpt=1 (queue active) Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_peer_select: 884643E30022 smtp 192.168.X.X (5 of 10) Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_job_retire: 884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: send attr queue_id = 884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/smtp[26956]: input attribute value: 884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/smtp[26956]: deliver_request_get: file active/884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/smtp[26956]: 884643E30022: to=x...@.net, relay=192.168.X.X[192.168.X.X]:25, delay=102997, delays=102997/0/0/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 8DBA6D0016E) Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_active_done: 884643E30022 Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: 884643E30022: removed Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_job_free: 884643E30022 smtp Here is everything that I could find between the hours where the read timeout on cleanup socket error happened. (Dec 11 05:31:27 batch-ca4-02 postfix/cleanup[31691]: warning: 8A2993E3003B: read timeout on cleanup socket) Dec 11 04:04:26 batch-ca4-02 postfix/pickup[25527]: 9CC1F3E3003A: uid=0 from=root Dec 11 04:06:17 batch-ca4-02 postfix/smtpd[31631]: dict_eval: const pickup Dec 11 04:06:17 batch-ca4-02 postfix/smtp[31689]: dict_eval: const pickup Dec 11 04:09:19 batch-ca4-02 postfix/pickup[25527]: 7905B3E3003A: uid=500 from=x...@.com Dec 11 07:15:59 batch-ca4-02 postfix/smtpd[5663]: dict_eval: const pickup And here is everything before the read timeout on cleanup socket: Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: diag_type Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: diag_text Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: diag_text Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: mta_type Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: mta_type Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: mta_mname Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: mta_mname Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: action Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: action Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: reason Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: reason Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: status Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: status Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute value: 0 Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: private/smtp socket: wanted attribute: (list terminator) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: input attribute name: (end) Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: qmgr_queue_unthrottle: queue 192.168.X.X Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: qmgr_active_done: 177013E30037 Dec 11 04:07:59 batch-ca4-02 postfix/smtp[31689]: master_notify: status 1 Dec 11 04:07:59 batch-ca4-02 postfix/smtp[31689]: connection closed Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: 177013E30037: removed Dec 11 04:07:59 batch-ca4-02 postfix/qmgr[28082]: qmgr_job_free: 177013E30037 smtp Dec 11 04:09:19 batch-ca4-02 postfix/pickup[25527]: 7905B3E3003A:
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Gonzo Fernandez: # egrep 884643E30022 /var/log/maillog Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: warning: 884643E30022: message has been queued for 1 days Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: 884643E30022: uid=500 from=x...@.com What user acccount has uid=500? Is this your web server? Perhaps you have an exploitable web application. This is very popular with spammers. To block local submissions from this user, /etc/postfix/main.cf: authorized_submit_users = !username, static:anyone Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_active_feed: incoming/884643E30022 Please turn off all your verbose logging in master.cf. It makes Postfix VERY VERY SLOW and makes mail overload problems much worse. On the other hand, if your email overload is caused by spam, please turn on verbose logging on everything, to slow down the delivery of spam. Wietse
Re: Postfix Not Sending Emails. Timeout on Cleanup socket error.
Hi Wietse, The UID 500 is from our batch email not spam. It constantly sends out emails to our clients on a regular basis. Also, I turned off verbose logging on all options. I originally turned it on to try and figure out why it was getting stuck on the weekends, but now it is off. I will see if that helps this weekend. Thank you. Gonzo Fernandez Network Engineer On Dec 15, 2011, at 5:35 PM, Wietse Venema wrote: Gonzo Fernandez: # egrep 884643E30022 /var/log/maillog Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: warning: 884643E30022: message has been queued for 1 days Dec 12 10:08:50 batch-ca4-02 postfix/pickup[26935]: 884643E30022: uid=500 from=x...@.com What user acccount has uid=500? Is this your web server? Perhaps you have an exploitable web application. This is very popular with spammers. To block local submissions from this user, /etc/postfix/main.cf: authorized_submit_users = !username, static:anyone Dec 12 10:08:50 batch-ca4-02 postfix/qmgr[26936]: qmgr_active_feed: incoming/884643E30022 Please turn off all your verbose logging in master.cf. It makes Postfix VERY VERY SLOW and makes mail overload problems much worse. On the other hand, if your email overload is caused by spam, please turn on verbose logging on everything, to slow down the delivery of spam. Wietse
Re: using postscreen on port 25
On 12/15/2011 8:19 AM, /dev/rob0 wrote: The old default of most MUAs to use port 25 was wrong, and it is now coming back to haunt you. That said, you have workarounds: - Use a different IP address for port 25 MX and submission mail If *all* your MUAs submitting to TCP 25 are on a known internal subnet, such as corporate network desktops, the fix is even easier as it requires no MUA reconfiguration. The following assuming your Postfix server is Linux. Simply create a new submission service such as the one below. Create iptables rules to redirect all traffic from the local subnet destined to TCP 25 to the TCP port of the new submission service. The submission service may look something like: /etc/postfix/master.cf ... 10125 inet n - - - - smtpd -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o receive_override_options=no_unknown_recipient_checks,\ no_address_mappings,no_header_body_checks Google will find you the iptables information you need to implement this pretty quickly. -- Stan
Re: Possibility to store all incoming mail (pre-content_filter)
On 12/15/2011 11:14 AM, Michael Weissenbacher wrote: All i can tell is that some mails (like 1 out of 2) get corrupted in the process and end up being unusable. I cannot disable amavis completely as spam hell would break lose. I cannot disable apache-james because it contains some custom filters. The most likely culprit here is apache-james because it contains some custom code. But if i disable it i cannot tell which mails would have triggered the bug and which ones didn't. That's why i want to store mails at postfix:25 before they get altered. Then simply create a new submission service for exclusive use by the back end system in question, and override everything. Have the back end host relay all its mail to the new submission service. Problem solved. If if then still see a corrupted message every 20k or so, you know it's the back end application causing the problem. -- Stan
