RE: notification messages
On 4/26/2012 10:46 AM, Amira Othman wrote: Hi all I am working on project that requires notification messages of delivery not to be sent to users. I asked before and you told me that it's not good idea to disable notifications so what I need now is to redirect all notifications for each domain to certain account and not to the actual sender. I tried header checks with null return path and other header info that is sent with notification but not working. I also tried virtual maps but it works for each individual user. I have 3 postfix instances running on same host, two of these instances are for two separate domains so what I need is to collect all notification messages (bounces) generated by each instance in one mailbox. How can I do that? regards Please describe the actual problem rather than asking how to implement a broken solution. I need to prevent all notification messages of a domain from being sent to outside users that sends mail through postfix. Because the application that push mails already handles bounces so no need of notification to be sent again to the actual sender -- Noel Jones
Re: notification messages
Amira Othman: I need to prevent all notification messages of a domain from being sent to outside users that sends mail through postfix. Because the application that push mails already handles bounces so no need of notification to be sent again to the actual sender What you describe handles only mail delivery errors during the initial application-to-Postfix SMTP transaction. What you describe DOES NOT handle the delivery errors that will happen AFTER the initial SMTP transaction. To control the path of non-delivery notifications, the proper procedure is to set an appropriate envelope sender (SMTP MAIL FROM) address. You will referred to the correct procedure no matter how many times you ask for an incorrect one. Wietse
postfix non-smtpd-command issues
As a follow-up to [this question][1], I have more issues appearing that are related but a bit more complex than initially perceived. [1]: http://serverfault.com/questions/379964/postfix-unknown-command I have a postfix server set up to receive specific messages bounced from an external mail gateway for milter processing. I'm noticing in the logs that, in some cases (albeit rare ones), parts of the message are being passed to SMTPD as commands. This, in turn, causes the milter to partially fail. example: (edited for content) Apr 26 19:03:26 mailproc postfix/smtpd[12912]: connect from mail-gw.MYDOMAIN.com[10.102.2.29] Apr 26 19:03:26 mailproc postfix/smtpd[12912]: DBE686E612EE: client=mail-gw.MYDOMAIN.com[10.102.2.29] Apr 26 19:03:26 mailproc postfix/cleanup[13346]: DBE686E612EE: message-id=D04184B070A8014FAE433E611B370C25033A7C@SENDERDOMAIN-MAIL10.c orp.SENDERDOMAIN.com Apr 26 19:03:26 mailproc postfix/smtpd[12912]: mail-gw.MYDOMAIN.com[10.102.2.29]: replacing command to, Emeryville, Oakland. with Apr 26 19:03:26 mailproc postfix/smtpd[12912]: mail-gw.MYDOMAIN.com[10.102.2.29]: replacing command res but do not contain LID. with Apr 26 19:03:26 mailproc postfix/qmgr[392]: DBE686E612EE: from=ajo...@senderdomain.com, size=15945, nrcpt=1 (queue active) Apr 26 19:03:27 mailproc postfix/smtp[13559]: DBE686E612EE: to=jsm...@sf.mydomain.com, relay=ph-svr-exch1.MYDOMAIN.com[10.102.2.30]:25, delay=0.15, delays=0.07/0.03/0/0.04, dsn=2.6.0, status=s\ ent (250 2.6.0 d04184b070a8014fae433e611b370c25033...@senderdomain-mail10.corp.SENDERD OMAIN.com Queued mail for delivery) Apr 26 19:03:27 mailproc postfix/qmgr[392]: DBE686E612EE: removed Apr 26 19:03:29 mailproc postfix/smtpd[12912]: warning: non-SMTP command from mail-gw.MYDOMAIN.com[10.102.2.29]: http://www.MYDOMAIN.com/ | MYDOMAIN, LLChttp://www.w= Apr 26 19:03:30 mailproc postfix/smtpd[12912]: disconnect from mail-gw.MYDOMAIN.com[10.102.2.29] Apr 26 19:03:50 mailproc postfix/smtpd[12912]: connect from mailproc.MYDOMAIN.com[10.102.2.164] Apr 26 19:03:50 mailproc postfix/smtpd[12912]: disconnect from mailproc.MYDOMAIN.com[10.102.2.164] Apr 26 19:04:41 mailproc postfix/smtpd[12912]: connect from phsmtp.MYDOMAIN.com[10.102.2.29] Apr 26 19:04:41 mailproc postfix/smtpd[12912]: CF9886E612EE: client=phsmtp.MYDOMAIN.com[10.102.2.29] Apr 26 19:04:41 mailproc postfix/cleanup[13346]: CF9886E612EE: message-id=D04184B070A8014FAE433E611B370C25033AA7@SENDERDOMAIN-MAIL10.c orp.SENDERDOMAIN.com Apr 26 19:04:41 mailproc postfix/qmgr[392]: CF9886E612EE: from=ajo...@senderdomain.com, size=16075, nrcpt=1 (queue active) Apr 26 19:04:41 mailproc postfix/smtpd[12912]: phsmtp.MYDOMAIN.com[10.102.2.29]: replacing command to, Emeryville, Oakland. with Apr 26 19:04:41 mailproc postfix/smtpd[12912]: phsmtp.MYDOMAIN.com[10.102.2.29]: replacing command res but do not contain LID. with Apr 26 19:04:41 mailproc postfix/smtp[13559]: CF9886E612EE: to=jsm...@sf.mydomain.com, relay=ph-svr-exch1.MYDOMAIN.com[10.102.2.30]:25, delay=0.1, delays=0.05/0/0/0.04, dsn=2.6.0, status=sent \ (250 2.6.0 d04184b070a8014fae433e611b370c25033...@senderdomain-mail10.corp.SENDERD OMAIN.com Queued mail for delivery) The replacing command notes you see from the log are replaced via smtpd_command_filter Thanks, Larry G. Wapnitsky MBA, MCSE, MCP+I IT SUPPORT ADMINISTRATION COORDINATOR WRT http://www.wrtdesign.com/ | Wallace Roberts Todd, LLC http://www.wrtdesign.com/ 1700 Market Street, 28th Fl Philadelphia, PA 19103 T 215.430.5068 C 215.713.8635 E lwapnit...@wrtdesign.com mailto:lwapnit...@wrtdesign.com wrtmail--%3423wrt%
RE: postfix non-smtpd-command issues
Forgot the postconf - n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
mailbox_size_limit = 0
message_size_limit = 0
milter_default_action = accept
milter_protocol = 6
mydestination = mailproc.wrtdesign.com, localhost.wrtdesign.com,
localhost
myhostname = mailproc.wrtdesign.com
mynetworks = 10.102.0.0/16, 192.168.0.0/24
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = ph-svr-exch1.wrtdesign.com
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_command_filter = pcre:/etc/postfix/bogus_commands
smtpd_milters = unix:/var/spool/RBL/RBLmilter.sock,
unix:/var/spool/EARS/EARSmilter.sock
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
Larry G. Wapnitsky MBA, MCSE, MCP+I
IT SUPPORT ADMINISTRATION COORDINATOR
WRT http://www.wrtdesign.com/ | Wallace Roberts Todd, LLC
http://www.wrtdesign.com/
1700 Market Street, 28th Fl
Philadelphia, PA 19103
T 215.430.5068
C 215.713.8635
E lwapnit...@wrtdesign.com mailto:lwapnit...@wrtdesign.com
From: Larry G. Wapnitsky
Sent: Friday, April 27, 2012 10:58 AM
To: postfix-users@postfix.org
Subject: postfix non-smtpd-command issues
As a follow-up to [this question][1], I have more issues appearing that
are related but a bit more complex than initially perceived.
[1]: http://serverfault.com/questions/379964/postfix-unknown-command
I have a postfix server set up to receive specific messages bounced from
an external mail gateway for milter processing. I'm noticing in the
logs that, in some cases (albeit rare ones), parts of the message are
being passed to SMTPD as commands. This, in turn, causes the milter to
partially fail.
example: (edited for content)
Apr 26 19:03:26 mailproc postfix/smtpd[12912]: connect from
mail-gw.MYDOMAIN.com[10.102.2.29]
Apr 26 19:03:26 mailproc postfix/smtpd[12912]: DBE686E612EE:
client=mail-gw.MYDOMAIN.com[10.102.2.29]
Apr 26 19:03:26 mailproc postfix/cleanup[13346]: DBE686E612EE:
message-id=D04184B070A8014FAE433E611B370C25033A7C@SENDERDOMAIN-MAIL10.c
orp.SENDERDOMAIN.com
Apr 26 19:03:26 mailproc postfix/smtpd[12912]:
mail-gw.MYDOMAIN.com[10.102.2.29]: replacing command to, Emeryville,
Oakland. with
Apr 26 19:03:26 mailproc postfix/smtpd[12912]:
mail-gw.MYDOMAIN.com[10.102.2.29]: replacing command res but do not
contain LID. with
Apr 26 19:03:26 mailproc postfix/qmgr[392]: DBE686E612EE:
from=ajo...@senderdomain.com, size=15945, nrcpt=1 (queue active)
Apr 26 19:03:27 mailproc postfix/smtp[13559]: DBE686E612EE:
to=jsm...@sf.mydomain.com,
relay=ph-svr-exch1.MYDOMAIN.com[10.102.2.30]:25, delay=0.15,
delays=0.07/0.03/0/0.04, dsn=2.6.0, status=s\
ent (250 2.6.0
d04184b070a8014fae433e611b370c25033...@senderdomain-mail10.corp.SENDERD
OMAIN.com Queued mail for delivery)
Apr 26 19:03:27 mailproc postfix/qmgr[392]: DBE686E612EE: removed
Apr 26 19:03:29 mailproc postfix/smtpd[12912]: warning: non-SMTP
command from mail-gw.MYDOMAIN.com[10.102.2.29]:
http://www.MYDOMAIN.com/ | MYDOMAIN, LLChttp://www.w=
Apr 26 19:03:30 mailproc postfix/smtpd[12912]: disconnect from
mail-gw.MYDOMAIN.com[10.102.2.29]
Apr 26 19:03:50 mailproc postfix/smtpd[12912]: connect from
mailproc.MYDOMAIN.com[10.102.2.164]
Apr 26 19:03:50 mailproc postfix/smtpd[12912]: disconnect from
mailproc.MYDOMAIN.com[10.102.2.164]
Apr 26 19:04:41 mailproc postfix/smtpd[12912]: connect from
phsmtp.MYDOMAIN.com[10.102.2.29]
Apr 26 19:04:41 mailproc postfix/smtpd[12912]: CF9886E612EE:
client=phsmtp.MYDOMAIN.com[10.102.2.29]
Apr 26 19:04:41 mailproc postfix/cleanup[13346]: CF9886E612EE:
message-id=D04184B070A8014FAE433E611B370C25033AA7@SENDERDOMAIN-MAIL10.c
orp.SENDERDOMAIN.com
Apr 26 19:04:41 mailproc postfix/qmgr[392]: CF9886E612EE:
from=ajo...@senderdomain.com, size=16075, nrcpt=1 (queue active)
Apr 26 19:04:41 mailproc postfix/smtpd[12912]:
phsmtp.MYDOMAIN.com[10.102.2.29]: replacing command to, Emeryville,
Oakland. with
Apr 26 19:04:41 mailproc postfix/smtpd[12912]:
phsmtp.MYDOMAIN.com[10.102.2.29]: replacing command res but do not
contain LID. with
Apr 26 19:04:41 mailproc postfix/smtp[13559]: CF9886E612EE:
to=jsm...@sf.mydomain.com,
relay=ph-svr-exch1.MYDOMAIN.com[10.102.2.30]:25, delay=0.1,
delays=0.05/0/0/0.04, dsn=2.6.0, status=sent \
(250 2.6.0
d04184b070a8014fae433e611b370c25033...@senderdomain-mail10.corp.SENDERD
OMAIN.com Queued mail for delivery)
The replacing command notes you see from the log are replaced via
smtpd_command_filter
Thanks,
Larry G. Wapnitsky MBA, MCSE, MCP+I
IT SUPPORT ADMINISTRATION COORDINATOR
WRT
Sending SMS
Hi, Is it possible to send SMS to mobiles via postfix. Any help/support/clue will be appereciated. Thanks/regards, Vishal Agarwal
Re: postmap ldap lookups and case folding
On Thu, Apr 26, 2012 at 08:43:56PM -0400, b...@bitrate.net wrote: OK, thanks for the clarification. The impetus for this question - I was setting up check_ccert_access to use an ldap lookup, and was using an ldap attribute whose matching rules happened to be case sensitive. I'd copied/pasted the fingerprint from the log messages [uppercase] for the ldap attribute value. This introduced a bit of an incongruence in my testing with postmap, since i didn't then know that case was being folded. It also appears that case folding occurs during actual operation [e.g. not just with postmap]?: The lookups in access(5) fold keys to lower-case for indexed tables, and leave them unchanged with regexp tables. Apr 26 20:32:49 exo postfix/smtpd[10641]: unknown[50.33.151.70]: Trusted: subject_CN=msa.example.net, issuer=example corp, fingerprint=86:A5:5C:85:A3:98:2E:19:7A:54:57:99:76:9D:D5:A3:7E:46:85:C5 [...] Apr 26 20:32:49 exo postfix/smtpd[10641]: dict_ldap_lookup: /etc/postfix/tables/ccert_access.cf: Searching with filter (?(objectclass=mailserver)?(certfingerprint=86:a5:5c:85:a3:98:2e:19:7a:54:57:99:76:9d:d5:a3:7e:46:85:c5)?(memberof=cn=mail_relayers-hosts,ou=exo,ou=servers,ou=groups,dc=example,dc=net)) Your LDAP schema should specify certfingerprint as a case-insensitive attribute. This is a hexadecimal number (with some : characters thrown in for readability), and the case of A-F is insignificant. -- Viktor.
RE: notification messages
I need to prevent all notification messages of a domain from being sent to outside users that sends mail through postfix. Because the application that push mails already handles bounces so no need of notification to be sent again to the actual sender What you describe handles only mail delivery errors during the initial application-to-Postfix SMTP transaction. What you describe DOES NOT handle the delivery errors that will happen AFTER the initial SMTP transaction. To control the path of non-delivery notifications, the proper procedure is to set an appropriate envelope sender (SMTP MAIL FROM) address. You will referred to the correct procedure no matter how many times you ask for an incorrect one. Wietse Ok I tried to change envelope sender from postfix configuration added the following mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME -t -f bou...@mydoamin.com but nothing change in log and the notification is sent to the user . is something missing ?
Re: postfix non-smtpd-command issues
On Fri, Apr 27, 2012 at 10:58:24AM -0400, Larry G. Wapnitsky wrote: I have a postfix server set up to receive specific messages bounced from an external mail gateway for milter processing. I'm noticing in the logs that, in some cases (albeit rare ones), parts of the message are being passed to SMTPD as commands. This, in turn, causes the milter to partially fail. The SMTP client fails to implement the SMTP protocol correctly: https://tools.ietf.org/html/rfc5321#section-4.5.2 Whoever controls the SMTP client needs to fix the software on that end. -- Viktor.
Can I improve the efficiency of my dnsbl reject configuration?
I just installed a Postfix server and enabled DNSBL-based rejection with smtpd_recipient_restrictions = check_recipient_access hash:/usr/local/etc/postfix/conf/bozos, reject_non_fqdn_recipient, permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org, permit It looks like it's working. Spam is getting rejected. In every case though there are multiple connections made with multiple rejects. For example Apr 26 11:13:07 liam postfix/smtpd[22946]: connect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:08 liam postfix/smtpd[22946]: NOQUEUE: reject: RCPT from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23]: 554 5.7.1 Service unavailable; Client host [130.43.53.23] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=130.43.53.23; from=de...@site.careerbuilder.com to=kar...@domain.com proto=ESMTP helo=dyn.forthnet.gr Apr 26 11:13:08 liam postfix/smtpd[22946]: lost connection after DATA from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:08 liam postfix/smtpd[22946]: disconnect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:32 liam postfix/smtpd[22946]: connect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:32 liam postfix/smtpd[22946]: NOQUEUE: reject: RCPT from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23]: 554 5.7.1 Service unavailable; Client host [130.43.53.23] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=130.43.53.23; from=de...@site.careerbuilder.com to=kar...@domain.com proto=ESMTP helo=dyn.forthnet.gr Apr 26 11:13:33 liam postfix/smtpd[22946]: lost connection after DATA from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:33 liam postfix/smtpd[22946]: disconnect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:59 liam postfix/smtpd[22946]: connect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:59 liam postfix/smtpd[23175]: connect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:14:00 liam postfix/smtpd[22946]: NOQUEUE: reject: RCPT from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23]: 554 5.7.1 Service unavailable; Client host [130.43.53.23] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=130.43.53.23; from=vie...@site.careerbuilder.com to=kar...@domain.com proto=ESMTP helo=dyn.forthnet.gr Apr 26 11:14:00 liam postfix/smtpd[23175]: NOQUEUE: reject: RCPT from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23]: 554 5.7.1 Service unavailable; Client host [130.43.53.23] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=130.43.53.23; from=ale...@site.careerbuilder.com to=kar...@domain.com proto=ESMTP helo=dyn.forthnet.gr Apr 26 11:14:00 liam postfix/smtpd[22946]: lost connection after DATA from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:14:00 liam postfix/smtpd[22946]: disconnect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:14:00 liam postfix/smtpd[23175]: lost connection after DATA from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:14:00 liam postfix/smtpd[23175]: disconnect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] In the end it's getting blocked, and that's what I want. But, if I understand how this works, every one of those rejects is a DNS check to spamhaus, and some postfix load on my server. Can I somehow configure to be more efficient about this? Maybe somehow cache the rejected IP for 15mins or something? I'll first ask how to do this without postscreen. -- Thanks, Karen
Re: notification messages
Am 27.04.2012 17:53, schrieb Amira Othman: To control the path of non-delivery notifications, the proper procedure is to set an appropriate envelope sender (SMTP MAIL FROM) address. You will referred to the correct procedure no matter how many times you ask for an incorrect one. Wietse Ok I tried to change envelope sender from postfix configuration added the following mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME -t -f bou...@mydoamin.com but nothing change in log and the notification is sent to the user . is something missing ? yes, you are missing basics this has NOTHING to do with postfix-configuration the sender/envelope is controlled by the application sending mail signature.asc Description: OpenPGP digital signature
Re: Sending SMS
On 2012-04-27 11:38 AM, Vishal Agarwal vis...@norpknit.com wrote: Is it possible to send SMS to mobiles via postfix. Any help/support/clue will be appereciated. Most phone service providers have a format for sending texts to recipients via smtp... For example, for TMobile users, it is phonenum...@tmomail.net -- Best regards, Charles
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote: I just installed a Postfix server and enabled DNSBL-based rejection with [..] In every case though there are multiple connections made with multiple rejects. For example [..] In the end it's getting blocked, and that's what I want. But, if I understand how this works, every one of those rejects is a DNS check to spamhaus, and some postfix load on my server. The caching is done in your local resolver, not in postfix.
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 06:09 PM, Dennis Guhl wrote: The caching is done in your local resolver, not in postfix. Ok, I can check that and make sure that those results are being returned from my LAN DNS server's cache. Is there any way to prevent Postfix from making those repeated DNS checks, regardless of whether it's externally to Spamhaus' servers, or to a locally cached DNS result? If an IP is identified as 'bad' via a DNSBL check once, that should be sufficient. Any subsequent instances of that IP should also be considered 'bad', if only for some user-defined period of time. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On 27 Apr 2012, at 16:55, kar...@mailcan.com wrote: In the end it's getting blocked, and that's what I want. But, if I understand how this works, every one of those rejects is a DNS check to spamhaus, and some postfix load on my server. Can I somehow configure to be more efficient about this? Maybe somehow cache the rejected IP for 15mins or something? The info will already be cached at your local DNS server. So you've already got this check about as efficient as it could possibly be. DNS lookups for info a name server already holds are pretty much the fastest and most lightweight operations possible. When postfix checks an IP address in Spamhaus's RBL, it sends a DNS lookup to your local name server which in turn queries one of the Spamhaus name servers. Your local name server will remember that answer for a while. [A positive entry in the Spamhaus RBL -- this address is a spam source -- is cached by your name server for 15 minutes. A negative one -- this address is not a spam source -- is cached for 2.5 minutes. Spamhaus decide these TTL (time to live) values, not you.] So when postfix gets a second connection from the same IP address, it does a local DNS lookup, the local name server gets a cache hit and returns that answer without having first to query the Spamhaus name servers again. When the data expires from the local name server's cache, it will of course have to query the Spamhaus name servers. There are interesting trade-offs here. Longer TTLs can mean more frequent hits in the local name server's cache because the data live there for longer. OTOH, this could mean stale data gets to stay in the cache for too long: ie the local name server's remembering a good IP address that has just gone bad or vice versa. I'll first ask how to do this without postscreen. postscreen is not the answer anyway. This is likely to be far, far more expensive than a DNS lookup. So don't do that. :-) My advice is to leave this alone. It's already working at maximum efficiency pretty much straight out of the box and there are no meaningful postfix (or DNS) configuration tweaks which could make things even faster.
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012 at 09:20:21AM -0700, kar...@mailcan.com wrote: On Fri, Apr 27, 2012, at 06:09 PM, Dennis Guhl wrote: The caching is done in your local resolver, not in postfix. [..] Is there any way to prevent Postfix from making those repeated DNS checks, regardless of whether it's externally to Spamhaus' servers, or to a locally cached DNS result? No. Dennis [..]
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 05:23 PM, Jim Reid wrote: The info will already be cached at your local DNS server. So you've snip. Nicely explained. My advice is to leave this alone. It's already working at maximum efficiency pretty much straight out of the box and there are no meaningful postfix (or DNS) configuration tweaks which could make things even faster. I'd still think that a local check by Postfix to an 'auto-expiring hash table' (unclear so far it that can be done) to which the 'bad' address was added would still be more efficient and less overall network load than a query to locally cached DNS. I understand it's a matter of degree and from you explanation I may be down to splitting-hairs. I'll first ask how to do this without postscreen. postscreen is not the answer anyway. This is likely to be far, far more expensive than a DNS lookup. So don't do that. :-) I haven't used postscreen yet -- still reading about it. I thought the idea behind it was to be very-lightweight rejection as far forward in the transaction process as possible. At least its use of DNSBL checks. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On 27 Apr 2012, at 17:20, kar...@mailcan.com wrote: Is there any way to prevent Postfix from making those repeated DNS checks, regardless of whether it's externally to Spamhaus' servers, or to a locally cached DNS result? No. Well you could but it would be futile make-work that adds needless complexity and extra (unwanted?) configuration/management overhead. And the end result will be no better than what you already have. The cost of a DNS lookup is frankly not worth worrying about. So don't. :-) Now in principle you could develop some sort of standalone process and back-end database which remembers RBL answers for a while. But this will almost certainly be SLOWER and less efficient than a DNS lookup. You'd need to invent some sort of API or protocol for adding info to that database and looking it up. And you'd need some way of cleaning out stale entries from that database. This is beginning to smell very much like something the DNS already provides for free.
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 05:32 PM, Jim Reid wrote: This is beginning to smell very much like something the DNS already provides for free. If that auto-expiry hash table functionality is not already build into Postfix (which would be kind of nice to have for other things to; may look into it cobbling it up anyway), then that's a good point. At the moment, the only difference being the 'network traffic' to/from the DNS server. Likely not much of a burden. I could address it if need be by putting a caching DNS slave on the same box as the Postfix server. Overkill, it sounds like. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote: smtpd_recipient_restrictions = check_recipient_access hash:/usr/local/etc/postfix/conf/bozos Remove or at least move _after_ reject_unauth_destination. This is prone for open relay. reject_non_fqdn_recipient Why? permit_sasl_authenticated permit_mynetworks reject_unauth_destination reject_unlisted_recipient reject_non_fqdn_sender reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org permit Remove, it does nothing anyway. In the end it's getting blocked, and that's what I want. But, if I understand how this works, every one of those rejects is a DNS check to spamhaus, and some postfix load on my server. You have a local dns cache, it does the work for you. Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, Obsession, stardate 3620.7
Re: Sending SMS
I'm really interested by this use case. Written from my iPhone ! Le 27 avr. 2012 à 18:00, Charles Marcus cmar...@media-brokers.com a écrit : On 2012-04-27 11:38 AM, Vishal Agarwal vis...@norpknit.com wrote: Is it possible to send SMS to mobiles via postfix. Any help/support/clue will be appereciated. Most phone service providers have a format for sending texts to recipients via smtp... For example, for TMobile users, it is phonenum...@tmomail.net -- Best regards, Charles
Re: Can I improve the efficiency of my dnsbl reject configuration?
Please respond to the list as well, thanks. On Fri, Apr 27, 2012, at 05:38 PM, Jim Reid wrote: Er, think about this. How will postscreen do those RBL checks? Clearly, as I said I'm still reading, I'm not sure. It will do DNS lookups! Right. The 1st time. And if it *was* capable of storing temporary/expirable data to a local in-memory hash table, it could be very efficient. I'm asking questions and thinking about things, not debating. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 06:43 PM, Bastian Blank wrote: On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote: smtpd_recipient_restrictions = check_recipient_access hash:/usr/local/etc/postfix/conf/bozos Remove or at least move _after_ reject_unauth_destination. This is prone for open relay. 'bozos' holds a list of To: addresses that I discard. I'm not clear why/how that's prone for open relay. I'll look into it. reject_non_fqdn_recipient Why? Because countless documentation examples suggest it, including in The Postfix Book. permit_sasl_authenticated permit_mynetworks reject_unauth_destination reject_unlisted_recipient reject_non_fqdn_sender reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org permit Remove, it does nothing anyway. Remove what, specifically? All of those? What does nothing? -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
kar...@mailcan.com: On Fri, Apr 27, 2012, at 05:23 PM, Jim Reid wrote: The info will already be cached at your local DNS server. So you've snip. Nicely explained. My advice is to leave this alone. It's already working at maximum efficiency pretty much straight out of the box and there are no meaningful postfix (or DNS) configuration tweaks which could make things even faster. I'd still think that a local check by Postfix to an 'auto-expiring hash table' (unclear so far it that can be done) to which the 'bad' address Each Postfix SMTP server caches its own DNSBL lookup results. Those results are not shared with other Postfix processes. The in-process cache saves time when one message has multiple recipients, and the DNSBL check is done once per recipient in smtpd_recipient_restrictions. Wietse
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 01:47 PM, Wietse Venema wrote: I'd still think that a local check by Postfix to an 'auto-expiring hash table' (unclear so far it that can be done) to which the 'bad' address Each Postfix SMTP server caches its own DNSBL lookup results. Those results are not shared with other Postfix processes. The in-process cache saves time when one message has multiple recipients, and the DNSBL check is done once per recipient in smtpd_recipient_restrictions. Does a single Postfix SMTP server process instance remain resident/open across multiple connections? Or is a new one spawned for each connection, or perhaps after some delay, load or other trigger? If it's the former, and I understand this right, then the two somewhat-concurrent connections from the same spamhaus-banned IP, as referenced in my OP, Apr 26 11:13:07 liam postfix/smtpd[22946]: connect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:08 liam postfix/smtpd[22946]: NOQUEUE: reject: RCPT from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23]: 554 5.7.1 Service unavailable; Client host [130.43.53.23] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=130.43.53.23; ... Apr 26 11:13:32 liam postfix/smtpd[22946]: connect from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23] Apr 26 11:13:32 liam postfix/smtpd[22946]: NOQUEUE: reject: RCPT from 130.43.53.23.dsl.dyn.forthnet.gr[130.43.53.23]: 554 5.7.1 Service unavailable; Client host [130.43.53.23] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=130.43.53.23; ARE using the Postfix 'internal' DNSBL cache? How do I learn/observe that use of the cached value from logs? If it's the latter, I understand that results are not shared with other Postfix processes. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012 at 10:58:32AM -0700, kar...@mailcan.com wrote: On Fri, Apr 27, 2012, at 01:47 PM, Wietse Venema wrote: I'd still think that a local check by Postfix to an 'auto-expiring hash table' (unclear so far it that can be done) to which the 'bad' address Each Postfix SMTP server caches its own DNSBL lookup results. Those results are not shared with other Postfix processes. This is nice, I didn't knew about this. The in-process cache saves time when one message has multiple recipients, and the DNSBL check is done once per recipient in smtpd_recipient_restrictions. Does a single Postfix SMTP server process instance remain resident/open across multiple connections? Or is a new one spawned for each connection, or perhaps after some delay, load or other trigger? If it's the former, and I understand this right, then the two somewhat-concurrent connections from the same spamhaus-banned IP, as referenced in my OP, Apr 26 11:13:07 liam postfix/smtpd[22946]: connect from [..] Apr 26 11:13:32 liam postfix/smtpd[22946]: connect from [..] ARE using the Postfix 'internal' DNSBL cache? How do I learn/observe that use of the cached value from logs? You can observe the PID (22946 in this case). If it is the same, the in process cache will be hit. Dennis [..]
Re: Can I improve the efficiency of my dnsbl reject configuration?
On 2012-04-27 kar...@mailcan.com wrote: On Fri, Apr 27, 2012, at 06:43 PM, Bastian Blank wrote: On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote: reject_non_fqdn_recipient Why? Because countless documentation examples suggest it, including in The Postfix Book. For my personal mail server I use this rule, too. However, you need to be aware that it might reject some legit mail (e.g. from mail servers configured by stupid, but valid, customers), hence the rule may be inappropriate in situations where you handle business mail or mail for third parties. permit_sasl_authenticated permit_mynetworks reject_unauth_destination reject_unlisted_recipient reject_non_fqdn_sender reject_unknown_sender_domain reject_rbl_client zen.spamhaus.org reject_rbl_client b.barracudacentral.org permit Remove, it does nothing anyway. Remove what, specifically? All of those? What does nothing? Bastian probably meant just the trailing permit, because that's the default anyway. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Can I improve the efficiency of my dnsbl reject configuration?
kar...@mailcan.com: On Fri, Apr 27, 2012, at 01:47 PM, Wietse Venema wrote: I'd still think that a local check by Postfix to an 'auto-expiring hash table' (unclear so far it that can be done) to which the 'bad' address Each Postfix SMTP server caches its own DNSBL lookup results. Those results are not shared with other Postfix processes. The in-process cache saves time when one message has multiple recipients, and the DNSBL check is done once per recipient in smtpd_recipient_restrictions. Does a single Postfix SMTP server process instance remain resident/open across multiple connections? Or is a new one spawned for each connection, or perhaps after some delay, load or other trigger? Each Postfix SMTP server process is reused. http://www.postfix.org/postconf.5.html#max_use http://www.postfix.org/postconf.5.html#max_idle Wietse
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012 at 08:16:47PM +0200, Ansgar Wiechers wrote: On 2012-04-27 kar...@mailcan.com wrote: On Fri, Apr 27, 2012, at 06:43 PM, Bastian Blank wrote: On Fri, Apr 27, 2012 at 08:55:15AM -0700, kar...@mailcan.com wrote: reject_non_fqdn_recipient Why? Because countless documentation examples suggest it, including in The Postfix Book. For my personal mail server I use this rule, too. However, you need to be aware that it might reject some legit mail (e.g. from mail servers configured by stupid, but valid, customers), hence the rule may be inappropriate in situations where you handle business mail or mail for third parties. No really, I believe you have something else in mind. From http://www.postfix.org/postconf.5.html#reject_non_fqdn_recipient: reject_non_fqdn_recipient Reject the request when the RCPT TO address is not in fully-qualified domain form, as required by the RFC. Dennis
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 08:16 PM, Ansgar Wiechers wrote: reject_non_fqdn_recipient For my personal mail server I use this rule, too. However, you need to be aware that it might reject some legit mail (e.g. from mail servers configured by stupid, but valid, customers), hence the rule may be inappropriate in situations where you handle business mail or mail for third parties. Erring on the side of caution, reading http://www.postfix.org/postconf.5.html#reject_non_fqdn_recipient reject_non_fqdn_recipient Reject the request when the RCPT TO address is not in fully-qualified domain form, as required by the RFC. Iiuc, that RCPT TO belongs to the *sender's* mail, right? I.e., if they've misconfigured their RCPT TO (Different than 'Reply to', afaict) to, say, what -- 'alice@mail' ? or something? Just looking for an example case of misconfiguration. If it's a likely/reasonable scenario - and from you comment there *is* a probability of some - I'll probably remove it and see what happens. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 02:20 PM, Wietse Venema wrote: kar...@mailcan.com: Each Postfix SMTP server process is reused. http://www.postfix.org/postconf.5.html#max_use http://www.postfix.org/postconf.5.html#max_idle That answers my question. Both of the defaults seem to fit nicely enough for ~95% of what I see in my logs. -- Thanks, Karen
Re: postmap ldap lookups and case folding
On Apr 27, 2012, at 11.43, Viktor Dukhovni wrote: Your LDAP schema should specify certfingerprint as a case-insensitive attribute. This is a hexadecimal number (with some : characters thrown in for readability), and the case of A-F is insignificant. copied/pasted from my previous message- [...] in this particular case, i've accommodated for this on the ldap side, by modifying the attribute's matching rules to be case insensitive [and it makes more sense anyway for an attribute like this] - i'm wondering though if there might be value in not case folding ldap lookups. [...] the point being that this particular example aside, case sensitive ldap attributes are a possibility, raising the question as to whether or not case folding of lookup keys should occur. to be clear, i'm asking in general, with regard to ldap, not regarding one particular attribute. -ben
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 05:32 PM, Jim Reid wrote: On 27 Apr 2012, at 17:20, kar...@mailcan.com wrote: Is there any way to prevent Postfix from making those repeated DNS checks, regardless of whether it's externally to Spamhaus' servers, or to a locally cached DNS result? No. Well you could but it would be futile make-work that adds needless complexity and extra (unwanted?) configuration/management overhead. And the end result will be no better than what you already have. The cost of a DNS lookup is frankly not worth worrying about. So don't. :-) Now in principle you could develop some sort of standalone process and back-end database which remembers RBL answers for a while. But this will almost certainly be SLOWER and less efficient than a DNS lookup. You'd need to invent some sort of API or protocol for adding info to that database and looking it up. And you'd need some way of cleaning out stale entries from that database. This is beginning to smell very much like something the DNS already provides for free. Just as an interesting point from a fairly large site (fastmail.fm) we do something very like that. We run a standalone daemon, and we keep a bad list of IPs who get dumped immediately without even a DNS lookup. One of our patches to postfix allows that, dropping the connection while doing nothing more than a syslog of the IP address. We found a significant performance improvement in being able to do that with known bad IPs over doing reverse DNS. RBL lookups aren't so bad, because we have rsync agreements with all the RBLs we use, so we download the full RBL and the server locally, but reverse DNS chews up processes for longer. We also hand over sockets that we want to respond to slowly to a separate process that does non-blocking epoll IO rather than chewing up a full sized postfix process just to slowly say goodbye. ... All this is working very nicely. Honestly the biggest feature we're missing is the ability to duplicate an outbound queue to two machines and fail over quietly between them if we need to do maintainence on one. We keep out outbound queues on drbd at the moment, which smells messy, but works OK. Bron ( none of this work is worth the effort unless email is a major part of your organisation's purpose, otherwise you should probably concentrate on things that actually make you money ) -- Bron Gondwana br...@fastmail.fm
Re: Can I improve the efficiency of my dnsbl reject configuration?
Den 2012-04-27 17:55, kar...@mailcan.com skrev: reject_unauth_destination, reject_unlisted_recipient, reject_unlisted_recipient is not needed AFTER reject_unauth_destination
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 08:54 PM, Bron Gondwana wrote: Just as an interesting point from a fairly large site (fastmail.fm) we do something very like that. We run a standalone daemon, and we keep a bad list of IPs who get dumped immediately without even a DNS lookup. One of our patches to postfix allows that, dropping the connection while doing nothing more than a syslog of the IP address. That's interesting. Just our of curiosity, as I'm in the midst of reading about policy daemons, milters, before after queue filtering, etc. At a high-level -- how did you implement this? Sounds like you're actually patching postfix code, and not handing off to a dameon/milter/etc early in the process. -- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
kar...@mailcan.com: On Fri, Apr 27, 2012, at 08:54 PM, Bron Gondwana wrote: Just as an interesting point from a fairly large site (fastmail.fm) we do something very like that. We run a standalone daemon, and we keep a bad list of IPs who get dumped immediately without even a DNS lookup. One of our patches to postfix allows that, dropping the connection while doing nothing more than a syslog of the IP address. That's interesting. Just our of curiosity, as I'm in the midst of reading about policy daemons, milters, before after queue filtering, etc. At a high-level -- how did you implement this? Sounds like you're actually patching postfix code, and not handing off to a dameon/milter/etc early in the process. For small sites, postscreen has an up-front blacklist that kicks off clients before wasting resources on them. Wietse
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012 at 12:02:05PM -0700, kar...@mailcan.com wrote: On Fri, Apr 27, 2012, at 08:54 PM, Bron Gondwana wrote: Just as an interesting point from a fairly large site (fastmail.fm) we do something very like that. We run a standalone daemon, and we keep a bad list of IPs who get dumped immediately without even a DNS lookup. One of our patches to postfix allows that, dropping the connection while doing nothing more than a syslog of the IP address. That's interesting. Just our of curiosity, as I'm in the midst of reading about policy daemons, milters, before after queue filtering, etc. At a high-level -- how did you implement this? Sounds like you're actually patching postfix code, and not handing off to a dameon/milter/etc early in the process. Postfix is going to do a reverse DNS lookup of any connecting client, followed by a forward lookup of the PTR name received. This is fine for most sites. Small sites can save some of this using postscreen, which merely does a few cheap and fast checks without the PTR/A(AAA)? lookups. It sounds like Bron's patch is to do a client local blacklist lookup beforehand. Fastmail.fm might be too big to benefit from postscreen, but you are probably not. :) Your best answer, as discussed upthread, is to use postscreen. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Can I improve the efficiency of my dnsbl reject configuration?
On 4/27/2012 1:54 PM, Bron Gondwana wrote: Just as an interesting point from a fairly large site (fastmail.fm) we do something very like that. We run a standalone daemon, and we keep a bad list of IPs who get dumped immediately without even a DNS lookup. One of our patches to postfix allows that, dropping the connection while doing nothing more than a syslog of the IP address. This is exactly what postscreen is for, no patching necessary. http://www.postfix.org/postconf.5.html#postscreen_access_list Postscreen also will temporarily blacklist RBL listed clients. Subsequent connections get dropped with no DNS lookup for $postscreen_dnsbl_ttl, default 1 hour. http://www.postfix.org/POSTSCREEN_README.html -- Noel Jones
Re: Can I improve the efficiency of my dnsbl reject configuration?
On Fri, Apr 27, 2012, at 03:12 PM, Wietse Venema wrote: For small sites, postscreen has an up-front blacklist that kicks off clients before wasting resources on them. Although I was warned off postscreen in an earlier post being 'heavier' than the checks against locally cached DNS, your comment's consistent with my initial read about postscreen. Iiuc it, too, uses a standard postfix SMTP process, and probably does that local DNSBL IP caching as well. Sounds like the lightest solution, without additional clever patching or dameon writing, may well be postscreen 'out front'. I-- Thanks, Karen
Re: Can I improve the efficiency of my dnsbl reject configuration?
On 4/27/2012 2:12 PM, /dev/rob0 wrote: Postfix is going to do a reverse DNS lookup of any connecting client, followed by a forward lookup of the PTR name received. These are done in the postfix/smtpd client. This is fine for most sites. Small sites can save some of this using postscreen, which merely does a few cheap and fast checks without the PTR/A(AAA)? lookups. postscreen does no DNS lookups other than user-defined dnsbl/dnswl. It sounds like Bron's patch is to do a client local blacklist lookup beforehand. Fastmail.fm might be too big to benefit from postscreen, That's unclear. cidr tables should scale very well to a couple hundred thousand entries. For millions of entries maybe memcache would help. Testing would be required to see what's feasible. It's imperative that postscreen table lookups be extremely fast, since that's the postscreen choke point. Postfix becomes unusable when the access table and/or cache lookup delay gets high enough to throttle incoming mail. but you are probably not. :) Your best answer, as discussed upthread, is to use postscreen. Indeed. -- Noel Jones
Re: Can I improve the efficiency of my dnsbl reject configuration?
On 4/27/2012 2:17 PM, kar...@mailcan.com wrote: On Fri, Apr 27, 2012, at 03:12 PM, Wietse Venema wrote: For small sites, postscreen has an up-front blacklist that kicks off clients before wasting resources on them. Although I was warned off postscreen in an earlier post being 'heavier' I didn't see that comment, but either it's plain wrong or was referring to something different. than the checks against locally cached DNS, your comment's consistent with my initial read about postscreen. Iiuc it, too, uses a standard postfix SMTP process, and probably does that local DNSBL IP caching as well. Postscreen does not use smtpd other than to handoff good connections once they've been approved. Sounds like the lightest solution, without additional clever patching or dameon writing, may well be postscreen 'out front'. I would recommend postscreen to everyone, but extremely large sites would want to do additional testing. -- Noel Jones
