Re: Apparent pipe error
On Mon, 2014-06-30 at 10:40:18 -0400, Jerry wrote: On Mon, 30 Jun 2014 09:37:32 -0400 (EDT), Wietse Venema stated: ... Can you ping the maintainer? ... I have sent him an email ACK. -- Sahil Tandon
Re: Berkeley DB6 and Postfix
On Sun, 2014-05-11 at 18:18:45 -0400, Jerry wrote: The installation halts immediately with this error message: === postfix-current-2.12.20140507,4 cannot install: does not work with Berkeley DB version 6 (6 not supported). That is deliberately triggered when someone tries to build the Postfix port WITH_BDB_VER=6. This is so that users do not begin building, only to encounter: dict_db.c:705:2: error: Unsupported Berkeley DB version Is this correct or am I doing something terribly wrong? Version 6 has been out for quite some time now and I would have thought that Postfix would have supported it. Based on src/util/dict_db.c, the latest supported Berkeley DB major version is 5. -- Sahil Tandon
Re: [PATCH 2.11/2.12] connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
On Wed, 2014-05-07 at 06:02:30 +, Viktor Dukhovni wrote:
--- a/postfix/src/smtp/smtp.h
+++ b/postfix/src/smtp/smtp.h
@@ -195,7 +195,7 @@ typedef struct SMTP_STATE {
STR((state)-iterator-request_nexthop)[0] = 0; \
}
-#define HAVE_NEXTHOP_STATE(state) (STR((state)-iterator-request_nexthop)
!= 0)
+#define HAVE_NEXTHOP_STATE(state)
(STR((state)-iterator-request_nexthop)[0] != 0)
We applied this patch a few hours after you proposed it, then re-enabled
opportunistic TLS along with on-demand connection caching. The problem
did not recur. I see Wietse has already rolled out snapshot 20140507, to
which we will upgrade soon.
Thank you both.
--
Sahil Tandon
connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
We are experiencing a problem that seems to manifest *only* when
delivering to MXs that exhibit the SSL problem described by Viktor[1]
AND connection caching is enabled on demand. I am still reviewing the
logs to understand this, but at first glance, it appears that we try to
deliver mail to MXs that (in DNS) are not associated with the
destination domain, e.g.:
May 6 12:00:04 mx2 postfix/smtp[26171]: SSL_connect error to
iron1-mx.tops.gwu.edu[128.164.127.227]:25: -1
May 6 12:00:04 mx2 postfix/smtp[26171]: warning: TLS library problem:
error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode
error:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:762:
May 6 12:00:04 mx2 postfix/smtp[26171]: 4416951CD: Cannot start TLS:
handshake failure
...
May 6 12:00:05 mx2 postfix/smtp[26118]: 751AE5215:
to=bmtm1...@live.com,
relay=iron1-mx.tops.gwu.edu[128.164.127.227]:25, conn_use=2,
delay=3.3, delays=0.02/3.1/0.08/0.15, dsn=5.0.0, status=bounced (host
iron1-mx.tops.gwu.edu[128.164.127.227] said: 550 #5.1.0 Address
rejected. (in reply to RCPT TO command))
May 6 12:00:07 mx2 postfix/smtp[26240]: 3C02D52D2:
to=scli...@outlook.com,
relay=iron1-mx.tops.gwu.edu[128.164.127.227]:25, conn_use=3,
delay=3.9, delays=0.1/3.5/0.07/0.15, dsn=5.0.0, status=bounced (host
iron1-mx.tops.gwu.edu[128.164.127.227] said: 550 #5.1.0 Address
rejected. (in reply to RCPT TO command))
May 6 12:00:07 mx2 postfix/smtp[25609]: A9657525C:
to=kimura-...@necst.nec.co.jp,
relay=iron1-mx.tops.gwu.edu[128.164.127.227]:25, conn_use=4,
delay=4.7, delays=0.01/4.5/0.07/0.15, dsn=5.0.0, status=bounced (host
iron1-mx.tops.gwu.edu[128.164.127.227] said: 550 #5.1.0 Address
rejected. (in reply to RCPT TO command))
another example:
May 6 10:31:44 mx2 postfix/smtp[6133]: SSL_connect error to
smtp.citrix.com[66.165.176.89]:25: -1
May 6 10:31:44 mx2 postfix/smtp[6133]: warning: TLS library problem:
error:1407741A:SSL
routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode
error:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:762:
May 6 10:31:44 mx2 postfix/smtp[6133]: 59013110C: Cannot start TLS:
handshake failure
...
May 6 10:31:47 mx2 postfix/smtp[5241]: 9AC2B1145:
to=tk...@cisco.com, relay=smtp.citrix.com[66.165.176.89]:25,
conn_use=2, delay=63, delays=0.11/62/0.2/0.39, dsn=5.0.0,
status=bounced (host smtp.citrix.com[66.165.176.89] said: 550 #5.1.0
Address rejected. (in reply to RCPT TO command))
May 6 10:31:48 mx2 postfix/smtp[5918]: A9BD01152:
to=free...@coal.sentex.ca, relay=smtp.citrix.com[66.165.176.89]:25,
conn_use=3, delay=64, delays=0.11/63/0.21/0.46, dsn=5.0.0,
status=bounced (host smtp.citrix.com[66.165.176.89] said: 550 #5.1.0
Address rejected. (in reply to RCPT TO command))
May 6 10:31:49 mx2 postfix/smtp[6082]: EDFBF1181:
to=free...@gimbo.org, relay=smtp.citrix.com[66.165.176.89]:25,
conn_use=4, delay=64, delays=0.16/64/0.21/0.39, dsn=5.0.0,
status=bounced (host smtp.citrix.com[66.165.176.89] said: 550 #5.1.0
Address rejected. (in reply to RCPT TO command))
As a temporary workaround, we set 'smtp_tls_security_level = none', and
disabled on-demand connection caching; the problem has not recurred.
Obviously, the above log excerpts are incomplete; I am happy to share
the entire (large) logfile if that would be helpful for diagnosis. This
is 2.12-20140109.
postconf -n, from before we made the configuration changes noted above:
message_size_limit = 2048
mynetworks = [ ... ]
mynetworks_style = host
relay_domains = hash:/usr/local/etc/postfix/relay_domains
smtp_bind_address6 = [ ... ]
smtp_tls_CAfile = /usr/local/etc/postfix/certs/ca.pem
smtp_tls_cert_file = /usr/local/etc/postfix/certs/server.crt
smtp_tls_key_file = /usr/local/etc/postfix/certs/server.key
smtp_tls_loglevel = 0
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtpd_authorized_verp_clients = $mynetworks
smtpd_banner = $myhostname ESMTP $mail_name (Postfix FTW!)
smtpd_helo_required = yes
smtpd_recipient_restrictions = [ ... ]
smtpd_tls_CAfile = /usr/local/etc/postfix/certs/ca.pem
smtpd_tls_ccert_verifydepth = 1
smtpd_tls_cert_file = /usr/local/etc/postfix/certs/server.crt
smtpd_tls_key_file = /usr/local/etc/postfix/certs/server.key
smtpd_tls_mandatory_protocols = SSLv3, TLSv1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
transport_maps = hash:/usr/local/etc/postfix/transport
[1] http://article.gmane.org/gmane.mail.postfix.user/243056
--
Sahil Tandon
Re: connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
On Wed, 2014-05-07 at 03:31:13 +, Viktor Dukhovni wrote: On Tue, May 06, 2014 at 10:49:20PM -0400, Sahil Tandon wrote: We are experiencing a problem that seems to manifest *only* when delivering to MXs that exhibit the SSL problem described by Viktor[1] AND connection caching is enabled on demand. That is when TLS handshakes fail and cleartext connections are made to deliver the mail. Such connections may be cached. Right. Have you tried disabling TLS, but not the demand caching? Not yet, but that is being discussed with the other postmasters; will probably give it a shot in a few hours. Does the problem *only* lead to erroneous connection re-use via relays that are the result of a cleartext fallback? I cannot say definitively without more complete log analysis, but that is my hunch. And, the issue does not seem to occur as a result of the initial cleartext fallback, but later ... once on-demand caching has kicked in. [...] This is 2.12-20140109. On what platform (FreeBSD per chance)? Sorry, yes it is FreeBSD 11.0-CURRENT, r265336. I am still reviewing the logs to understand this, but at first glance, it appears that we try to deliver mail to MXs that (in DNS) are not associated with the destination domain, e.g.: May 6 12:00:04 mx2 postfix/smtp[26171]: SSL_connect error to iron1-mx.tops.gwu.edu[128.164.127.227]:25: -1 May 6 12:00:04 mx2 postfix/smtp[26171]: warning: TLS library problem: error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:762: May 6 12:00:04 mx2 postfix/smtp[26171]: 4416951CD: Cannot start TLS: handshake failure ... Where are the rest of the logs for smtpd[26171] that show the retried cleartext delivery? Here are the next two lines logged by that process: May 6 12:00:04 mx2 postfix/smtp[26171]: Host offered STARTTLS: [iron1-mx.tops.gwu.edu] May 6 12:00:05 mx2 postfix/smtp[26171]: 4416951CD: to=adu...@gwu.edu, relay=iron1-mx.tops.gwu.edu[128.164.127.227]:25, delay=3, delays=0.1/1.8/0.64/0.46, dsn=2.0.0, status=sent (250 ok: Message 606874687 accepted) The metadata for the cached connection from scache(8) indeed seems inconsistent with the expected request. You may need to enable -v in scache, to observe requests and responses. Hm, OK. May 6 10:31:44 mx2 postfix/smtp[6133]: SSL_connect error to smtp.citrix.com[66.165.176.89]:25: -1 May 6 10:31:44 mx2 postfix/smtp[6133]: warning: TLS library problem: error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:/usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/s23_clnt.c:762: May 6 10:31:44 mx2 postfix/smtp[6133]: 59013110C: Cannot start TLS: handshake failure ... Once again, where is the rest of the that delivery? Sure, the next two lines logged by that process: May 6 10:31:45 mx2 postfix/smtp[6133]: Host offered STARTTLS: [smtp.citrix.com] May 6 10:31:46 mx2 postfix/smtp[6133]: 59013110C: to=roger@citrix.com, relay=smtp.citrix.com[66.165.176.89]:25, delay=63, delays=0.11/59/1.6/1.4, dsn=2.0.0, status=sent (250 ok: Message 128162365 accepted) There seems to be corruption in the scache client or server. Hmm. -- Sahil Tandon
Re: connection cache issue correlated with SSL23_GET_SERVER_HELLO:tlsv1 alert decode error?
On Tue, 2014-05-06 at 23:57:41 -0400, Sahil Tandon wrote: On Wed, 2014-05-07 at 03:31:13 +, Viktor Dukhovni wrote: On Tue, May 06, 2014 at 10:49:20PM -0400, Sahil Tandon wrote: We are experiencing a problem that seems to manifest *only* when delivering to MXs that exhibit the SSL problem described by Viktor[1] AND connection caching is enabled on demand. That is when TLS handshakes fail and cleartext connections are made to deliver the mail. Such connections may be cached. Right. Have you tried disabling TLS, but not the demand caching? Not yet, but that is being discussed with the other postmasters; will probably give it a shot in a few hours. Does the problem *only* lead to erroneous connection re-use via relays that are the result of a cleartext fallback? I cannot say definitively without more complete log analysis, but that is my hunch. And, the issue does not seem to occur as a result of the initial cleartext fallback, but later ... once on-demand caching has kicked in. I will parse the last few days worth of logs to verify this, and then follow-up. No need to waste any more time than you already have on this hunch. -- Sahil Tandon
Re: Getting DKIM to work with Mailman and Postfix
On Mon, 2014-05-05 at 13:11:31 -0400, James B. Byrne wrote: I am wrestling with the issues arising from Yahoo.com, and now AOL.com, enforcing dkim for their addresses. Specifically we run a small number of mailing lists using Mailman which have a large number of subscribers from both these domains. As Mailman is configured to forward mail without altering the FROM: header this trips the DKIM reject. FWIW, we were bitten by this DMARC issue on the freebsd.org mailing lists and dealt with it as per: http://wiki.list.org/x/ggARAQ http://wiki.list.org/display/DEV/DMARC i.e., set dmarc_moderation_action and dmarc_quarantine_moderation_action in Mailman rather than changing Postfix. -- Sahil Tandon
Re: mailman issue
On Sat, 2014-04-05 at 18:40:39 -0400, Curtis Maurand wrote: Sahil Tandon wrote: On Fri, 2014-04-04 at 14:55:49 -0400, Curtis Maurand wrote: I'm getting local user unknown errors when I try to send email to the list., but as far as I know, I shouldn't need local aliases with this configuration that anything destined for lists.delrc.org should go to mailman and that's that. I know that I'm missing a detail somewhere. I had all of this working prior to this, but I had a server meltdown the other day and my configs were blown away with it and for whatever reason, I can't find any backups. :-( Typically, you have to update the alias_maps definition, so that Postfix is made aware of valid Mailman addresses. In your follow-up, include the output of 'postconf -n' rather than snippets from main.cf. See: http://www.gnu.org/software/mailman/mailman-install/postfix-integration.html http://www.postfix.org/postconf.5.html#alias_maps I'll remember to do that. However, i was told of a way to configure it in such a way that using transport maps all you had to do was to create the list and there would be no alias management. Please understand: regardless of transport(5) mapping, Postfix MUST in some way (e.g. aliases) be made aware of valid recipients. Otherwise, mail will be rejected by smtpd(8), well before your transport_maps are consulted. The following sections of the documentation might help you grasp this: http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_recipient http://www.postfix.org/ADDRESS_CLASS_README.html#wtf If you have a question regarding the Mailman aspects of you configuration, please ask on mailman-users. -- Sahil Tandon
Re: mailman issue
On Fri, 2014-04-04 at 14:55:49 -0400, Curtis Maurand wrote: I'm getting local user unknown errors when I try to send email to the list., but as far as I know, I shouldn't need local aliases with this configuration that anything destined for lists.delrc.org should go to mailman and that's that. I know that I'm missing a detail somewhere. I had all of this working prior to this, but I had a server meltdown the other day and my configs were blown away with it and for whatever reason, I can't find any backups. :-( Typically, you have to update the alias_maps definition, so that Postfix is made aware of valid Mailman addresses. In your follow-up, include the output of 'postconf -n' rather than snippets from main.cf. See: http://www.gnu.org/software/mailman/mailman-install/postfix-integration.html http://www.postfix.org/postconf.5.html#alias_maps -- Sahil Tandon
Re: 20-40+ second delays. Is this normal?
On Thu, 2014-03-13 at 06:26:10 -0700, jmct wrote:
Thank you for the suggestion. I have ran postfix set-permissions,
Was there any output? Did you run this command with superuser
priveledges?
but it looks like the postdrop warning is still occurring on each
message.
What, if anything, is output after you issue the following commands?
# ls -ld /var/spool/postfix/public{,/pickup}
and
# postfix check
--
Sahil Tandon
Re: 20-40+ second delays. Is this normal?
Some guesses below; hopefully an expert will eventually chime in. On Wed, 2014-03-12 at 06:18:37 -0700, jmct wrote: ... When I try sending a basic test e-mail through PowerShell using my Postfix box as the SMTP server - I'm seeing 20-40+ second delays in the /var/log/maillog per e-mail. Here is what I see in the logs: Mar 12 07:59:36 postfix/smtpd[21189]: connect from unknown[10.1.10.45] ... Mar 12 07:59:36 postfix/postdrop[21196]: warning: unable to look up public/pickup: Permission denied A permission issue prevents postdrop(1) from notifying the pickup(8) service of new mail arrival. Try running 'postfix set-permissions' to fix this. Mar 12 07:59:36 postfix/pipe[21192]: 2E69C1E0203: to=me@workdomain, relay=spamfilter, delay=0.17, delays=0.02/0.02/0/0.13, dsn=2.0.0, status=sent (delivered via spamfilter service) Mar 12 07:59:36 postfix/qmgr[20944]: 2E69C1E0203: removed Postfix delivers to the spamfilter relay in 1s from initial connect, and removes the message from the queue. Mar 12 *07:59:36* spamd[15542]: prefork: child states: II Mar 12 *08:00:06* postfix/pickup[20942]: 5B5A81E01ED: uid=5001 from=me@workdomain During its periodic scan of the maildrop queue, pickup(8) sees the new mail and passes it to cleanup(8), as logged below. Mar 12 08:00:06 postfix/cleanup[21191]: 5B5A81E01ED: message-id=20140312130006.5B5A81E01ED@localhost Mar 12 08:00:06 postfix/qmgr[20944]: 5B5A81E01ED: from=m...@workdomain.com, ... -- Sahil Tandon
Re: FreeBSD ports OpenSSL with zlib issue?
On Sun, 2014-02-16 at 11:02:08 -0500, Wietse Venema wrote: Viktor Dukhovni: On Sun, Feb 16, 2014 at 07:45:24AM -0500, Wietse Venema wrote: This looks like the same problem that Viktor referred to yesterday. Same symptom (crash in zlib+openssl), same resolution. Perhaps Sahil can comment on what the status of this issue is in FreeBSD? It has not to my knowledge been seen in other systems. I can run some tests inside a FreeBSD 10 VM (or give you a copy of the VirtualBox VM). The smaller the test program, the better. If there is a test program, I would also be happy to try it. FWIW, I recall reports about zlib+openssl problems with ejabberd in FreeBSD, but nothing in the context of Postfix. In fact, the most recent report I saw was filed by someone who noted that his zlib+openssl setup did not hiccup with Postfix, only ejabberd. http://www.freebsd.org/cgi/query-pr.cgi?pr=181994 -- Sahil Tandon
Re: Will this have side effects?
On Thu, 2014-02-06 at 17:24:06 -0600, Jay G. Scott wrote: recipient_canonical_maps=regexp:/etc/postfix/pfrecipient_canonical [root@davis postfix]# more pfrecipient_canonical /^gl@.*\.arlut\.utexas\.edu$/ g...@arlut.utexas.edu /^a@.*\.arlut\.utexas\.edu$/a...@arlut.utexas.edu /^b@.*\.arlut\.utexas\.edu$/b...@arlut.utexas.edu /^c@.*\.arlut\.utexas\.edu$/c...@arlut.utexas.edu Does this have consequences/side effects that I might not expect? In particular, I have transport_maps = hash:/etc/postfix/pftransport also in main.cf . Transport_maps will still be honored, won't it? Yes, but remember that transport mapping occurs after address rewriting; take care to accordingly specify the lookup keys in your transport table. -- Sahil Tandon
Re: Handling quotas.
On Thu, 2013-09-05 at 06:59:32 -0400, Bruce Markey wrote: I'm running postfix/courier. Is it better to let postfix handle quotas or let courier do it, or is it just a matter of preference? I'm dealing with strictly virtual users here. From the articles I've come across having postfix handle it seems pretty straightforward, although ht most of the walktheoughs i see are a bit old. A recent and useful article about how to reject pre-queue based on quota is linked below; but, it is specific to dovecot. Perhaps it will convince you to switch from courier - dovecot, like I did many years ago. :-) http://sys4.de/en/blog/2013/04/08/postfix-dovecot-mailbox-quota/ -- Sahil Tandon
Re: reject_unlisted_sender not working
On Sun, 2013-09-01 at 07:32:57 -0700, warpspasm wrote: I would like to use reject_unlisted_sender to allow only one From: address to be used to send email from my mail server. But it is not working, it seems to still just be allowing all From: addresses. Here is the output of what happened: You misunderstand how reject_unlisted_sender works. See: http://www.postfix.org/postconf.5.html#reject_unlisted_sender http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender Sep 1 08:00:52 xxx postfix/pickup[31603]: A696A34E481: uid=33 from=ran...@yyy.com Sep 1 08:00:52 xxx postfix/cleanup[31608]: A696A34E481: message-id=5222f434a1...@yyy.com Sep 1 08:00:52 xxx postfix/qmgr[31604]: A696A34E481: from=ran...@yyy.com, size=776, nrcpt=1 (queue active) Sep 1 08:00:53 xxx postfix/smtp[31610]: A696A34E481: to=u...@gmail.com, [ .. ] --- I would have expected to see a 550 or something else from postfix/smtp --- Any ideas what I have done wrong? [ .. ] smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/listed_senders reject_unlisted_sender Instead, try: # main.cf check_sender_access hash:/etc/postfix/listed_senders, reject -- Sahil Tandon
Re: reject_unlisted_sender not working
On Sun, 2013-09-01 at 11:09:33 -0400, Sahil Tandon wrote: [ .. ] Instead, try: # main.cf check_sender_access hash:/etc/postfix/listed_senders, reject To be clear, this will not help in your test case (but rather, only when mail is received via smtpd) as Wietse points out. -- Sahil Tandon
Re: MARC link on postfix.org/lists.html
On Mon, 2013-08-26 at 16:04:30 +0200, DTNX Postmaster wrote: The MARC link on the mailing lists page no longer seems to work; http://www.postfix.org/lists.html http://marc.theaimsgroup.com/?l=postfix-users As far as I can tell, the new link seems to be; http://marc.info/?l=postfix-users *nod* It seems the old link stopped working earlier this year; I remember seeing a mention of this on the SA issues tracker and just found it: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6898 -- Sahil Tandon
Re: allowing and then dropping wildcard users
On Sun, 2013-05-05 at 02:39:30 -0600, LuKreme wrote:
I have several domains on my postfix server, and I have one where the
owner wants the following behavior:
us...@domain.tld = real user account
us...@domain.tld = real user account
*@domain.tld = mail checks accepted, actual mail dropped.
Use virtual alias mapping to direct mail for user{1,2}@domain.tld to
actual accounts. Then, implement a catch-all which maps *@domain.tld to
an address that, via transport(5), directs mail to the discard(8)
service.
--
Sahil Tandon
Re: postfix and Berkeley DB
On Fri, 2013-04-12 at 05:10:09 -0600, LuKreme wrote: ... In our previous episode (Thursday, 11-Apr-2013), Sahil Tandon said: As documented, Postfix uses the default Berkeley DB version that ships with your system, which I am assuming is FreeBSD. Yes, FreeBSD VeryOld-stable. Then which of the libdb.so files on the system is postfix using? None. Postfix is using libc, which appears in your ldd(1) output, and contains the Berkeley DB 1.85 routines. # locate libdb.so /usr/local/lib/db42/libdb.so /usr/local/lib/db44/libdb.so /usr/local/lib/db48/libdb.so These were installed via ports; not part of base system, and irrelevant given the way you built Postfix. -- Sahil Tandon
Re: postfix and Berkeley DB
On Thu, 2013-04-11 at 16:35:28 -0600, LuKreme wrote: # ldd /usr/local/libexec/postfix/smtpd /usr/local/libexec/postfix/smtpd: libmysqlclient.so.16 = /usr/local/lib/mysql/libmysqlclient.so.16 (0x280cf000) libz.so.3 = /lib/libz.so.3 (0x28139000) libm.so.4 = /lib/libm.so.4 (0x2814a000) libssl.so.7 = /usr/local/lib/libssl.so.7 (0x2816) libcrypto.so.7 = /usr/local/lib/libcrypto.so.7 (0x281ad000) libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x2830a000) libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x28321000) libc.so.6 = /lib/libc.so.6 (0x28354000) libcrypt.so.3 = /lib/libcrypt.so.3 (0x2843b000) So, you did not explicitly link against a non-default DB library. # file /etc/postfix/virtual.db /etc/postfix/virtual.db: Berkeley DB 1.85 (Hash, version 2, native byte-order) So, postfix appears to be using Berkeley DB but is not linked against it? As documented, Postfix uses the default Berkeley DB version that ships with your system, which I am assuming is FreeBSD. You can alter this behavior by explicitly linking against a different, non-default DB version, which would then appear in ldd(1) output. Or, you can disable Berkeley DB support entirely by including -DNO_DB in CCARGS. -- Sahil Tandon
Re: HOLDing certain recipients during migration
On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote: On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones njo...@megan.vbhcs.org wrote: HOLD acts at the message level, not the recipient level. If one recipient of a multi-recipient message is put on HOLD, all recipients of that message will be affected. I see. I believe the HOLD is better suited to our scenario as a temporary reject and this (HOLDing messages for all recipients if one matches) is acceptable. I do not understand your response; the HOLD action is not a temporary reject. Anyway, my involvement earlier in the thread is for others who might chance upon this chain in the archives, and prefer the alternative (and IMHO more robust) approach. -- Sahil Tandon
Re: HOLDing certain recipients during migration
On Mon, 2013-02-11 at 19:56:23 +0100, Miha Valencic wrote: Just want to double check if I am planning this correctly. We're migrating users from one system to another, and want to HOLD incoming messages for certain recipients during migration. For that purpose, we'll create a file with users listed: /hold-users: us...@domain.com HOLD us...@domain.com HOLD ... The HOLD action affects all recipients; you can be more specific by using the retry service. See the following thread: http://article.gmane.org/gmane.mail.postfix.user/197989 -- Sahil Tandon
Re: Postscreen status script, take two
On Wed, 2013-01-30 at 14:23:19 -0500, Mike. wrote: I made some changes to the script based upon the excellent feedback I received here. The script no longer wanders beyond the postscreen log records in order to gather the information needed to determine the postscreen rejection rate. So that removes the problems caused by multiple-recipient messages. ... Be careful with grep(1) patterns. You overstate CONNECTs by including 'NOQUEUE: reject: CONNECT' in the count. Meanwhile, the script understates total DNSBL rejections, which you measure with: | grep -c DNSBL rank [3-99] That bracket expression matches on a _single_ character, and does not capture double-digit ranks. A similar mistake occurs in the attempt to aggregate 9+ ranks: | grep -c DNSBL rank [9-99] This only counts appearances of DNSBL rank 9 in the log, as illustrated below: | % grep -c DNSBL rank [9-99] maillog | 4494 | % grep -c DNSBL rank 9 maillog | 4494 Review the re_format(7) and grep(1) manuals to improve understanding of regular expressions. In case it helps you, last year I had cobbled together a slower (it is Python rather than a set of grep(1) expressions) script[1] to collect similar statistics. No promises that it is error-free. [1] http://people.freebsd.org/~sahil/scripts/mailstats.py.txt -- Sahil Tandon
Re: Mail forwarding loop
On Sat, 2012-11-10 at 16:09:24 +0100, Daniele Nicolodi wrote: ... What I observe is that postfix is receiving messages containing a forged Delivered-To header that makes postfix think it is seeing a mail forwarding loop. The local(8) daemon bounces the messages, but those messages are spam and the from addresses are invalid, therefore the bounces get stock in the delivery queue. This is not a problem in itself, but I do not like to generate bounces for spam messages. See the list archives for previous discussion of this issue. For example: http://thread.gmane.org/gmane.mail.postfix.user/148887 Read the entire thread before trying to implement the suggestion solutions. -- Sahil Tandon
Re: mixing mbox and maildirs for local users
On Sat, 2012-11-10 at 14:47:29 -0500, maillis...@gmail.com wrote: I need to deliver mail to a couple of local users in Maildir format, but deliver to others in the standard mbox. Is there a way to accomplish this inside Postfix, without resorting to procmail? For the users that require Maildir delivery, use .forward files that specify a destination mailbox name ending in '/'. -- Sahil Tandon
Re: upgrade behavior when smtpd_relay_restrictions is explicitly empty in main.cf
On Fri, 2012-11-02 at 19:13:04 +, Viktor Dukhovni wrote: On Fri, Nov 02, 2012 at 08:18:09AM -0400, Wietse Venema wrote: Sahil Tandon: Some background: upon deinstall, unaltered files installed by a FreeBSD package are supposed to be deleted. In the context of Postfix Come on, sites that don't edit main.cf are so rare that this is not something that I would worry about. Don't ask me to pre-patch the stock main/master.cf files. That is too hard to maintain (how do I know that it is still correct? I never use those files). That's fair and understood, Wietse. I did not mean to imply that you should implement an upstream workaround to address this ports issue; sorry if it came across that way. I was just seeking advice from those who may be addressing similar (admittedly edge case) constraints. ... So while the issue is not a high priority, I think that it makes sense to ship a default master.cf that requires no tweaks, and a main.cf that likewise requires no tweaks. I don't recall to what extent this is up to the package installer. Should the installer first check whether this is a first install of Postfix, and then run only postfix set-permissions without postfix upgrade-configuration? ... That seems reasonable. Although, if we take this approach, until the smtpd_relay_restrictions tweak is phased out, it would mean first-time users who perform a fresh install would notice no mention of this parameter in their main.cf and become accustomed to default behavior. Then, when upgrading on a later date, the shim (if it's still active) would insert the safety net into the configuration. Perhaps this is not a big deal, and it should not surprise users who dutifully read RELEASE_NOTES before using/upgrading software, but not everyone does that. Anyway, I think I have enough to proceed; sorry for going off-topic and thanks for the feedback. -- Sahil Tandon
Re: upgrade behavior when smtpd_relay_restrictions is explicitly empty in main.cf
On Wed, 2012-10-31 at 09:01:23 -0400, Wietse Venema wrote: Ralf Hildebrandt: * Sahil Tandon postfix-users@postfix.org: ... test -n `$POSTCONF -c $config_directory -n smtpd_relay_restrictions` With this, the forward compatibility shim would only trigger if smtpd_relay_restrictions does not appear in an existing main.cf, while explicitly empty settings of the parameter would be preserved during an upgrade. I think your proposal is good. I encountered the same behaviour (I first set smtpd_relay_restrictions to an empty value and THEN upgraded) OK, I have changed this. Great, thank you! BTW I duplicated that test from the inet_protocols compatibility shim. That parameter is usually not set to the empty value but the shim has the same problem. Aye. I have a separate question that is tangentially related, so I hope that it is OK to broach without spawning a separate thread. Some background: upon deinstall, unaltered files installed by a FreeBSD package are supposed to be deleted. In the context of Postfix configuration files, this is done by comparing, for example, the stock main.cf in $daemon_directory with its analogue in $config_directory, and only deleting the latter if the two match. These two files are identical after a fresh install of a pre-built Postfix package, so uninstalling Postfix via the package management framework results in the expected deletion of all main.cf files. The issue I have with the smtpd_relay_restrictions compatibility shim is that it is triggered even on fresh install of a pre-built Postfix package. This is because the main.cf placed in $config_directory does not include a smtpd_relay_restrictions definition, which is therefore added by the package management system that has historically called the post-install script with the 'upgrade-package' argument. So, as of the latest 2.10 snapshot, the two main.cf's no longer match after a fresh package install. I understand this is not a Postfix issue, but I would appreciate if other package maintainers (or anyone else who is willing to opine!) could share how they handle this. I initially thought to append a default smtpd_relay_restrictions definition to the stock version so that the two main.cf files would match following a fresh install, but then I wondered if that could cause unwelcome consequences. Is there a more canonical approach to all this? BTW, there is no similar issue with the inet_protocols shim because that parameter is explicitly defined in the stock main.cf. -- Sahil Tandon
upgrade behavior when smtpd_relay_restrictions is explicitly empty in main.cf
In Postfix 2.10 Snapshot 20121022, conf/post-install tests whether smtpd_relay_restrictions is already set with: test -n `$POSTCONF -c $config_directory -nh smtpd_relay_restrictions` This evaluates to false when smtpd_relay_restrictions is explicitly set to the empty value in main.cf, resulting in the parameter being overriden as described in RELEASE_NOTES. This seems inconsistent with my (perhaps faulty) interpretation of intended behavior. Would it make more sense to revise the above test to: test -n `$POSTCONF -c $config_directory -n smtpd_relay_restrictions` With this, the forward compatibility shim would only trigger if smtpd_relay_restrictions does not appear in an existing main.cf, while explicitly empty settings of the parameter would be preserved during an upgrade. Sorry if I have misunderstood something; I just want to be clear on how this works before updating the FreeBSD port. -- Sahil Tandon
Re: Maintaining the address verification cache for positives
On Tue, 2012-08-21 at 17:13:44 +0200, DTNX Postmaster wrote: For example, when an existing account is deleted on the backend server, Postfix will have the positive result, and maintain it for quite some time using the default settings; $ /usr/sbin/postconf -d |grep address_verify_positive_ address_verify_positive_expire_time = 31d address_verify_positive_refresh_time = 7d We tried setting 'address_verify_positive_refresh_time' to a low value to test with, but that does not update the cache. This is apparently by design, no doubt for good reasons. How do others deal with this? Set 'address_verify_positive_expire_time' to a value significantly lower than the default? I have lowered the expire time but, to avoid backscattering during the interim, I add a transport entry on the front-end MX that directs mail for deleted accounts to the error(8) delivery agent. I understand that may seem kludgy and too manual, but it works for us. Force expiry from the cache manually, somehow? AFAIK, that is not possible. Also, what purpose does the refresh timer serve if there is no update done due to optimistic caching? My understanding of this parameter is that a _successful_ refresh probe updates the timestamp of an address verification result; positive expire time is measured from that revised timestamp. -- Sahil Tandon
Re: temporarily suspending delivery
On Mon, 2012-09-03 at 19:36:46 -0400, b...@bitrate.net wrote: i have an mx which then subsequently delivers incoming mail from the internet to another computer [ via relay_transport = relay-mda:[mda.example.com]:smtp-relay ] for further processing. while performing some maintenance on mda.example.com, i'd like to configure postfix on the mx to accept all mail as it has been, but instead of then delivering to mda.example.com, retain all mail until it is manually released. it looks like the hold queue may be appropriate for this? how can i accomplish this? Rather than the hold queue, use the retry service. /path/to/main.cf: transport_maps = hash:/path/to/transport /path/to/transport: mda.example.com retry:4.2.1 mda.example.com is temporarily disabled -- Sahil Tandon
Re: Rejecting mail based on destination MX records
On Tue, 2012-08-28 at 15:53:28 -0500, Noel Jones wrote:
On 8/28/2012 3:38 PM, Gábor Lénárt wrote:
On Tue, Aug 28, 2012 at 04:33:16PM -0400, Jon A. wrote:
I'd like to immediately reject mail for all destinations with ONLY a
fakemx.net record. While I could block these as I find them, I'd prefer to
detect it if possible.
One such:
hitmail.com mail is handled by 0 mx.fakemx.net.
...
Be aware the postfix built-in check_*_mx_access will match if ANY of
the MX records match.
To reject domains with ONLY fakemx MX records, you'll need to use an
external policy service.
The OP could also query, via check_recipient_access, a spawn(8)-managed
TCP table; I do not know how well that would scale. An untested code
snippet that requires the external dnspython module is below. Please do
not use it in production; it is just to illustrate the approach.
#!/usr/local/bin/python
import os, sys, dns.resolver
# autoflush STDOUT
sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
# initialize a resolver with 2s timeout
resolver = dns.resolver.Resolver()
resolver.lifetime = 2
while True:
try:
fakemx = 0
domain = raw_input().lstrip('get ').lower().rsplit('@', 1)[1]
answer = resolver.query(domain, 'MX')
for mx in answer:
if 'mx.fakemx.net' in mx.to_text(): fakemx += 1
if fakemx == len(answer):
print('200 REJECT mail not deliverable (only destination is fakemx.net)')
else:
print('200 DUNNO')
except:
print('200 DUNNO')
--
Sahil Tandon
Re: [OT] frequent TRY_AGAINs and 10s timeouts, but *only* with b.barracudacentral.org
On Sun, 2012-06-03 at 00:03:06 +0100, Ned Slider wrote: On 02/06/12 17:44, Sahil Tandon wrote: ... I've separately engaged our DNS admins in case they could offer some insight, but it would be interesting to learn if others are experiencing the same issue /only/ with barracuda. I see similar in my bind logs on a server running SpamAssassin. The barracuda RBL is queried by default in SpamAssassin so I suspect the volume of queries they receive is pretty high. I assume it's a load issue at their end. I've been seeing such entries in my logs for months but it does seen to have got worse since around April of this year. ... Thanks to you and everyone else who replied on and off-list. I'll try to get someone's attention at barracuda. -- Sahil Tandon
[OT] frequent TRY_AGAINs and 10s timeouts, but *only* with b.barracudacentral.org
I am seeing hundreds (on higher volume days, over a thousand) of lines like: Jun 2 10:04:30 mx1 postfix/dnsblog[58868]: warning: dnsblog_query: lookup error for DNS query 23.124.167.115.b.barracudacentral.org: Host or domain name not found. Name service error for name=23.124.167.115.b.barracudacentral.org type=A: Host not found, try again Jun 2 10:04:33 mx1 postfix/smtpd[89019]: warning: 17.204.24.8.b.barracudacentral.org: RBL lookup error: Host or domain name not found. Name service error for name=17.204.24.8.b.barracudacentral.org type=A: Host not found, try again Jun 2 10:04:37 mx1 postfix/postscreen[55753]: warning: dnsblog reply timeout 10s for b.barracudacentral.org These lines are interspersed among others that indicate more normal activity with b.barracudacentral.org, e.g.: Jun 2 10:04:10 mx1 postfix/dnsblog[55985]: addr 199.30.50.35 listed by domain b.barracudacentral.org as 127.0.0.2 Jun 2 10:04:47 mx1 postfix/dnsblog[66369]: addr 157.56.112.23 listed by domain b.barracudacentral.org as 127.0.0.2 I know this is not an issue with Postfix (which dutifully reports the TRY_AGAIN it receives from the system library), but I wonder if anyone else is seeing this from barracuda? Based on a week's worth of logs, I do not see even a single instance of this problem with any other RBL (and we query several). I've separately engaged our DNS admins in case they could offer some insight, but it would be interesting to learn if others are experiencing the same issue /only/ with barracuda. -- Sahil Tandon
Re: Postfix 2.9.2, 2.8.11, 2.7.10, 2.6.16 available
On Mon, 2012-05-21 at 08:55:13 -0400, Wietse Venema wrote: ... To avoid repeated warnings from postscreen(8) with connect to private/dnsblog service: Connection refused on FreeBSD, the dnsblog(8) daemon now uses the single_server program driver instead of the multi_server driver. This one-line code change has no performance impact for other systems, and eliminates a high-frequency accept() race on a shared socket that appears to cause trouble on FreeBSD. The same single_server program driver has proven itself for many years in smtpd(8). Problem reported by Sahil Tandon. I've been running 2.10-20120520 for the past 48 hours with no sign of the 'Connection refused' problem. Thanks very much for the time you spent implementing this workaround, Wietse. -- Sahil Tandon
Re: virtual alias problem
On Mon, 2012-05-28 at 17:52:24 -0700, Dirk Kleinhesselink wrote: ... Then in virtual, I put; all-groups:group_1, group_2, group_3 ... I'm now moving my mail server within the organization to a new subdomain, but I intend to keep the same mail address scheme we've always used. I copied in my old configuration on the new server, but I'm now getting a failure for the aliases in the virtual file, giving me an error: all-groups unknown user. Can we see the actual log excerpt? ... I have set mydestination to be my desired domain and added in one for the new subdomain. Thanks for any assistance. I've gone through the virtual and local readmes, but I am not seeing the solution. Can we see the output of 'postconf -n'? Absent additional information, I guess you may find a clue in virtual(5) under TABLE SEARCH ORDER. -- Sahil Tandon
Re: warning: psc_dnsbl_request: connect to private/dnsblog service: Connection refused
Just following up to close this discussion. On Sun, 2012-05-06 at 09:35:24 -0400, Wietse Venema wrote: Sahil Tandon: May 5 10:00:26 mx1 postfix/postscreen[38500]: warning: psc_dnsbl_request: connect to private/dnsblog service: Connection refused May 5 10:00:26 mx1 last message repeated 8 times dnsblog results. ... Whatever this problem may be, it should be easy enough to re-create with smtp-source -A by setting up a dummy postfix instance with: - pregreet turned off - the smallest-possible greet-wait - sending dnsbl queries to a wild-card local DNS server This will reduce sharing of DNSBL results between multiple SMTP sesssions (and thus increase the DNSBL lookup rate). ... I could not reproduce the warning with smtp-source, but FWIW it recurs daily -- with varying frequency -- on the production MX. I enabled verbose logging for dnsblog(8) and postscreen(8) for a few hours, and could not[*] glean anything useful from the logging that precedes the warning. Anyway, this is not a major problem for me, but rather something that aroused curiosity. So, we needn't waste any more time on it. :) However, if someone else happens to experience a similar issue in the future, I'd be happy to compare logs (both verbose and otherwise) off-list. [*] This is likely due to lack of clue. -- Sahil Tandon
Re: 450 instead of 550 even though DNSBL rank exceeds postscreen_dnsbl_threshold?
On Sun, 2012-05-06 at 09:43:07 -0400, Wietse Venema wrote: ... By the way, what is going on with your DNS? Why do both DNSBL replies arrive (almost) simultaneously after two seconds? My bad. postscreen reports 'DNSBL rank' after two seconds. Phew. At least we're on the same page in that regard. :-) ... postscreen will report DNSBL results when *ALL* lookups complete or when the postscreen_greet_wait timer expires. Aye. ... Ah, this is what confuses me: the exact same DNSBL hits resulted in a rank of 5 so many times earlier, and the underlying configuration (i.e. the weights per DNSBL) have not changed in quite some time, so I expected to see a 5 rank here again. I repeat, perhaps some bit got flipped as the dnsblog daemon reported its results to the postscreen daemon; postscreen '-v' logging will show how it maintains DNSBL scores. OK, thanks; I'm now running postscreen with '-v' and will report back if the same scenario recurs. -- Sahil Tandon
Re: Postscreen DNSBL weights
On Fri, 2012-05-04 at 11:29:01 -0400, Rod K wrote: Was wondering if anyone would be willing to share what DNSBL and weights they are using with Postscreen. Mine are adapted from a previous post by /dev/rob0: postscreen_dnsbl_threshold = 3 postscreen_dnsbl_sites = zen.spamhaus.org*3 b.barracudacentral.org*3 dnsbl.njabl.org*2 bl.spameatingmonkey.net*2 bl.spamcop.net dnsbl.ahbl.org spamtrap.trblspam.com swl.spamhaus.org*-5 list.dnswl.org=127.[0..255].[0..255].0*-2 list.dnswl.org=127.[0..255].[0..255].1*-4 list.dnswl.org=127.[0..255].[0..255].[2..255]*-6 And FWIW, the below statistics correspond to a recent 24hr period; TOTAL is the number of IPs listed by a given zone, and UNIQ is the number of IPs listed *only* by that zone. Regarding overlap with whitelists, I've noticed that it's consistently highest for spamtrap.trblspam.com. UNIQ/TOTAL DNSBLDNSWL 1022/17454 b.barracudacentral.org 17 54/6841bl.spamcop.net 25 4/5502bl.spameatingmonkey.net 0 5/96 dnsbl.ahbl.org 0 7/134 dnsbl.njabl.org 3 587/3842spamtrap.trblspam.com 469 1609/18263 zen.spamhaus.org 5 UNIQ/TOTAL DNSWLDNSBL 2514/2520list.dnswl.org 510 0/6 swl.spamhaus.org 0 -- Sahil Tandon
Re: 450 instead of 550 even though DNSBL rank exceeds postscreen_dnsbl_threshold?
On Sat, 2012-05-05 at 19:49:18 -0400, Wietse Venema wrote: Sahil Tandon: May 5 15:24:07 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:40294 to [69.147.83.52]:25 May 5 15:24:07 mx1 postfix/dnsblog[45237]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:24:09 mx1 postfix/postscreen[38500]: DNSBL rank 5 for [88.23.204.109]:40294 May 5 15:24:09 mx1 postfix/postscreen[38500]: HANGUP after 0.24 from [88.23.204.109]:40294 in tests after SMTP handshake May 5 15:24:09 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:40294 In this second instance, is it correct to infer that Postfix was under stress given the 2s (rather than 6s) that elapses between the last dnsblog(8) entry and when the DNSBL rank is logged by postscreen(8)? No. What your see is this: there are no more before-220 tests when the DNBLS lookups complete, therefore postscreen makes its decision immediately. Hmm, OK. Either you have pregreet tests turned off, or this this client has already passed the pregreet test recently, and that result was cached in the temporary whitelist database. Gotcha, and because PREGREET tests are enabled, it must be the cache as you note. By the way, what is going on with your DNS? Why do both DNSBL replies arrive (almost) simultaneously after two seconds? In the log excerpt quoted above, CONNECT and dnsblog entries share the same timestamp of '15:24:07', so - just so I understand your question - do you mean why the 'DNSBL rank' is logged two seconds after CONNECT? I assumed that was because Postfix waits for postscreen_greet_wait to elapse before logging 'DNSBL rank' when the score matches or exceeds the threshold. May 5 15:25:08 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:41253 to [69.147.83.52]:25 May 5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:25:10 mx1 postfix/dnsblog[45300]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:25:10 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from [88.23.204.109]:41253: 450 4.3.2 Service currently unavailable; from=unlacesj...@clickz.com, to=freebsd-...@freebsd.org, proto=ESMTP, helo=109.Red-88-23-204.staticIP.rima-tde.net May 5 15:25:11 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from [88.23.204.109]:41253 in tests after SMTP handshake May 5 15:25:11 mx1 postfix/postscreen[38500]: PASS NEW [88.23.204.109]:41253 May 5 15:25:11 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:41253 postscreen sends out DNSBL lookup requests because the client is not yet whitelisted for this test. Notice that again, both DNSBL replies arrive two seconds later. In this case I think I see what you mean: the dnsblog logging appears 2s after the CONNECT. But FWIW, in previous instances with respect to this client, the CONNECT and dnsblog share the same timestamp such that there is no 2s delay, e.g.: May 5 15:20:51 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:38458 to [69.147.83.52]:25 May 5 15:20:51 mx1 postfix/dnsblog[45022]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:20:51 mx1 postfix/dnsblog[45025]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:20:51 mx1 postfix/dnsblog[45025]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:20:57 mx1 postfix/postscreen[38500]: DNSBL rank 5 for [88.23.204.109]:38458 May 5 15:20:57 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from [88.23.204.109]:38458: 550 5.7.1 Service unavailable; client [88.23.204.109] blocked using bl.spameatingmonkey.net; from=zo...@mc2school.org, to=n...@freebsd.org, proto=ESMTP, helo=109.Red-88-23-204.staticIP.rima-tde.net ... and ... May 5 15:22:22 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:38943 to [69.147.83.52]:25 May 5 15:22:22 mx1 postfix/dnsblog[45121]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:22:22 mx1 postfix/dnsblog[45116]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:22:22 mx1 postfix/dnsblog[45116]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:22:24 mx1 postfix/postscreen[38500]: DNSBL rank 5 for [88.23.204.109]:38943 May 5 15:22:24 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from [88.23.204.109]:38943: 550 5.7.1 Service unavailable; client [88.23.204.109] blocked using bl.spameatingmonkey.net; from=welled
warning: psc_dnsbl_request: connect to private/dnsblog service: Connection refused
Is there anything I should/could do to prevent these type of occurrences? My understanding is that postscreen(8) temporarily struggles to contact dnsblog(8) and in the meantime, postscreen_greet_wait elapses before DNSBL lookup results are available for this client. May 5 10:00:26 mx1 postfix/postscreen[38500]: CONNECT from [83.59.10.37]:12954 to [69.147.83.52]:25 May 5 10:00:26 mx1 postfix/postscreen[38500]: warning: psc_dnsbl_request: connect to private/dnsblog service: Connection refused May 5 10:00:26 mx1 last message repeated 8 times ... May 5 10:00:32 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from [83.59.10.37]:12954: 450 4.3.2 Service currently unavailable; from=classi...@polysto.com, to=x...@freebsd.org, proto=ESMTP, helo=37.red-83-59-10.dynamicip.rima-tde.net ... May 5 10:00:33 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from [83.59.10.37]:12954 in tests after SMTP handshake May 5 10:00:33 mx1 postfix/postscreen[38500]: PASS NEW [83.59.10.37]:12954 These psc_dnsbl_request warnings appear throughout my logs, and are interleaved with 'normal' dnsblog(8) logging that shows it is still working just fine in response to other client CONNECTs. I could not find references to this issue in the archives, and I know others manage much higher-volume sites, so I suspect it just indicates a severely borked system (FreeBSD 8.3) on my side. -- Sahil Tandon
450 instead of 550 even though DNSBL rank exceeds postscreen_dnsbl_threshold?
For context: % postconf mail_version postscreen_dnsbl_threshold postscreen_dnsbl_action mail_version = 2.9.1 postscreen_dnsbl_threshold = 3 postscreen_dnsbl_action = enforce I have likely missed something simple, so feel free to bludgeon me with your cluebats. Earlier today, I received some UCE from 88.23.204.109. Grepping the logs for that address AND 'postscreen' or 'dnsblog', I saw several instances of this client being rejected by postscreen(8). However, the following sequence of events confused me: May 5 15:23:41 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:39722 to [69.147.83.52]:25 May 5 15:23:41 mx1 postfix/dnsblog[45216]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:23:41 mx1 postfix/dnsblog[45209]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:23:41 mx1 postfix/dnsblog[45209]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:23:47 mx1 postfix/postscreen[38500]: DNSBL rank 5 for [88.23.204.109]:39722 May 5 15:23:47 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from [88.23.204.109]:39722: 550 5.7.1 Service unavailable; client [88.23.204.109] blocked using bl.spameatingmonkey.net; from=axisf...@buxrud.se, to=freebsd-...@freebsd.org, proto=ESMTP, helo=109.Red-88-23-204.staticIP.rima-tde.net May 5 15:23:48 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from [88.23.204.109]:39722 in tests after SMTP handshake May 5 15:23:48 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:39722 As expected, the client was rejected because DNSBL rank 5 exceeds the threshold. Then, the same client connected a few seconds later, but presumably hung up without trying to transmit anything: May 5 15:24:07 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:40294 to [69.147.83.52]:25 May 5 15:24:07 mx1 postfix/dnsblog[45237]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:24:07 mx1 postfix/dnsblog[45234]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:24:09 mx1 postfix/postscreen[38500]: DNSBL rank 5 for [88.23.204.109]:40294 May 5 15:24:09 mx1 postfix/postscreen[38500]: HANGUP after 0.24 from [88.23.204.109]:40294 in tests after SMTP handshake May 5 15:24:09 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:40294 In this second instance, is it correct to infer that Postfix was under stress given the 2s (rather than 6s) that elapses between the last dnsblog(8) entry and when the DNSBL rank is logged by postscreen(8)? Perhaps that is irrelevant, but just something I noticed. Anyway, the oddness occurs just under a minute later, when the client connects again: May 5 15:25:08 mx1 postfix/postscreen[38500]: CONNECT from [88.23.204.109]:41253 to [69.147.83.52]:25 May 5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.4 May 5 15:25:10 mx1 postfix/dnsblog[45304]: addr 88.23.204.109 listed by domain zen.spamhaus.org as 127.0.0.11 May 5 15:25:10 mx1 postfix/dnsblog[45300]: addr 88.23.204.109 listed by domain bl.spameatingmonkey.net as 127.0.0.3 May 5 15:25:10 mx1 postfix/postscreen[38500]: NOQUEUE: reject: RCPT from [88.23.204.109]:41253: 450 4.3.2 Service currently unavailable; from=unlacesj...@clickz.com, to=freebsd-...@freebsd.org, proto=ESMTP, helo=109.Red-88-23-204.staticIP.rima-tde.net May 5 15:25:11 mx1 postfix/postscreen[38500]: HANGUP after 1.1 from [88.23.204.109]:41253 in tests after SMTP handshake May 5 15:25:11 mx1 postfix/postscreen[38500]: PASS NEW [88.23.204.109]:41253 May 5 15:25:11 mx1 postfix/postscreen[38500]: DISCONNECT [88.23.204.109]:41253 ... No logging of a DNSBL rank, and the client just gets a 4xx after passing the deep protocol tests. As per design, future connections are passed on to smtpd(8) which then delivers the mail. Please let me know if any other portions of the log or a full 'postconf -n' (I'll just have to sanitize certain portions) would be useful. -- Sahil Tandon
some postscreen(8) stats
Before enabling DNSBL blocklists on one site, I was tasked with gathering some postscreen(8) statistics. I liked the information display in a previous thread[1], but did not require the geoIP and mapping features in Julien Vehent's script. So, I cobbled together a smaller log parser[2] to produce only the data I need; just sharing in case the information or script could be useful to others in the community. Example output, on a day earlier this week, aftering populating 'postscreen_dnsbl_sites', but leaving the default action as 'ignore': UNIQ/TOTAL EVENT 127/494 COMMAND COUNT LIMIT 60/104 COMMAND PIPELINING 355/492 COMMAND TIME LIMIT 35823/634743 CONNECT 31504/65612 DISCONNECT 24259/323664 DNSBL 22464/51380 HANGUP 54/90 NON-SMTP 8840/9300PASS NEW 11394/292608 PASS OLD 4324/30342 PREGREET 2/1447WHITELISTED 25760/32960 reject (450) 4193/20639 reject (550) 44/230 reject (all server ports busy) 5/868 reject (too many connections) ... and for DNSBL clients only: UNIQ/TOTAL EVENT 102/326 COMMAND COUNT LIMIT 54/81 COMMAND PIPELINING 299/408 COMMAND TIME LIMIT 24259/389632 CONNECT 23061/51893 DISCONNECT 24259/323664 DNSBL 19137/44210 HANGUP 49/85 NON-SMTP 1722/1787PASS NEW 2716/62660 PASS OLD 3889/27267 PREGREET 18643/24811 reject (450) 3783/16010 reject (550) 35/220 reject (all server ports busy) 3/374 reject (too many connections) [1] http://article.gmane.org/gmane.mail.postfix.user/224979 [2] http://people.freebsd.org/~sahil/scripts/mailstats.py.txt -- Sahil Tandon
Re: smtpd_reject_footer: possible improvement
On Thu, 2012-03-29 at 18:51:49 -0400, Wietse Venema wrote: ... That is clear. However, smtpd_reject_footer is part of the stable release, so it cannot be changed. Hence, my request for suggestions how we would document this. Maybe we can use a name similar, but not identical, to smtpd_reject_footer. Another option is to extend smtpd_reject_footer's feature set, so that smtpd_reject_footer = \c Text to append Will append the text without starting a new line. All other smtpd_reject_footer features would work as before. Elegant. +1 FWIW. -- Sahil Tandon
Re: New Installation of Postfix Server
On Sun, 2012-03-25 at 14:13:12 -0500, /dev/rob0 wrote: ... On Sun, Mar 25, 2012 at 02:01:05PM -0400, John Hudak wrote: Sometimes, it is very helpful to get a view of how all the parts fit together, their inter-dependencies for configuration, some aspect of data flow, etc. In some cases, these 'kitchen sink' articles serve that purpose very well, not to mention sometimes citing/or based on OS install specifics wrt directory structures, permissions, etc. This is a valid point. You CAN use such tutorials to help gain the big picture overview of what you need. ... e.g. http://rob0.nodns4.us/howto/ -- Sahil Tandon
Re: Redundant cleanup mail to one user with different extensions
On Sun, 2012-03-18 at 11:26:57 +0200, Pavel Gulchouck wrote: ... Sorry, I thought it's simple to reproduce. I've install postfix to clean debian-6 system, add alias gul-test to gul+1, gul+2, set procmail as local delivery agent, send test email to the alias and got only one copy in mailbox and mail.log. If I comment out line mailbox_command = procmail -a $EXTENSION in main.cf then postfix deliver mail to both addresses unless I add line |/usr/bin/procmail -a $EXTENSION to my ~/.forward. ... Rather than the local aliases(5) database, use virtual aliasing to explicitly split 'gul-test' into two distinct recipients 'gul+1' and 'gul+2'. Then, procmail should receive both copies of the message. -- Sahil Tandon
Re: Building Postfix RHEL RPMs with custom LDAP packages
On Sat, 2012-03-17 at 16:46:24 +0200, Nikolaos Milas wrote: ... /usr/sbin/postconf: warning: /etc/postfix/master.cf: unused ... fallback_relay parameter has been removed is no more available in v2.9 ? % grep -A 2 fallback_relay RELEASE_NOTES-2.3 [Incompat 20051208] The fallback_relay feature is renamed to smtp_fallback_relay, to make clear that the combined SMTP/LMTP client uses this setting only for SMTP deliveries. The old name still works. ... /usr/sbin/postconf: warning: /etc/postfix/main.cf: unused parameter: var_flock_tries=40 ... I guess that the var_flock_tries parameter (which I had added according to: http://tech.groups.yahoo.com/group/postfix-users/message/277428) might not be available any more. This parameter is no nonger valid? ... Still used in the code; not documented. Most people should not have to fiddle with this parameter. -- Sahil Tandon
Re: Redundant cleanup mail to one user with different extensions
On Sat, 2012-03-17 at 13:48:17 +0200, Pavel Gulchouck wrote: I use recipient_delimiter feature and procmail processing local delivery. Messages for me+sms goes to sms, for me+xmpp - to jabber etc. But if I want to receive a message both to xmpp and sms, I have a problem, because cleanup decides that me+xmpp and me+sms is the same user, and leaves only one copy of the message. Do you have logs of this occurring? -- Sahil Tandon
Re: Redundant cleanup mail to one user with different extensions
On Sat, 2012-03-17 at 16:00:26 +0200, Pavel Gulchouck wrote: On Sat, Mar 17, 2012 at 09:19:15AM -0400, Sahil Tandon writes: On Sat, 2012-03-17 at 13:48:17 +0200, Pavel Gulchouck wrote: I use recipient_delimiter feature and procmail processing local delivery. Messages for me+sms goes to sms, for me+xmpp - to jabber etc. But if I want to receive a message both to xmpp and sms, I have a problem, because cleanup decides that me+xmpp and me+sms is the same user, and leaves only one copy of the message. Do you have logs of this occurring? Additional info: this happens when destination is alias which expands to list of addresses contain user+ext1 and user+ext2. Rather than providing tidbits of information, would you share the output of 'postconf -n' and other relevant information as described in DEBUG_README? In my test, /etc/aliases contains: gul-test: gul+1, gul+2 Here's mail.log of sending mail to gul-test: Mar 17 13:50:00 mon postfix/pickup[31038]: 35847F90660: uid=1013 from=gul Mar 17 13:50:00 mon postfix/cleanup[11341]: 35847F90660: message-id=20120317135000.35847f90...@gul.kiev.ua Mar 17 13:50:00 mon postfix/qmgr[7754]: 35847F90660: from=g...@gul.kiev.ua, size=327, nrcpt=1 (queue active) Mar 17 13:50:01 mon postfix/local[11413]: 35847F90660: to=gu...@gul.kiev.ua, orig_to=gul-test, relay=local, delay=1, delays=0/0/0/1, dsn=2.0.0, status=sent (delivered to command: procmail -a $EXTENSION) Mar 17 13:50:01 mon postfix/qmgr[7754]: 35847F90660: removed FWIW, I cannot reproduce this, though I do not hand mail off to procmail: Mar 17 10:40:35 mx1 postfix/local[67468]: 2FD108A05B: to=sahi...@mx1.example.org, orig_to=foo...@mx1.example.org, relay=local, delay=0.47, delays=0.46/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir) Mar 17 10:40:35 mx1 postfix/local[67468]: 2FD108A05B: to=sahi...@mx1.example.org, orig_to=foo...@mx1.example.org, relay=local, delay=0.47, delays=0.46/0.01/0/0, dsn=2.0.0, status=sent (delivered to maildir) -- Sahil Tandon
Re: Building Postfix RHEL RPMs with custom LDAP packages
On Thu, 2012-03-15 at 01:45:43 +0200, Nikolaos Milas wrote:
...
%if %{with_ldap}
CCARGS=${CCARGS} -DHAS_LDAP -I/usr/local/openldap/include
AUXLIBS=${AUXLIBS} -L/usr/local/openldap/lib -lldap -llber
%endif
...
However, I see that at the end of the build process, the Requires
section includes:
... liblber-2.3.so.0()(64bit) libldap-2.3.so.0()(64bit) ...
which are in /usr/lib64 and belong to native openldap v2.3.x while I
would expect to see libraries like:
liblber-2.4-releng.so.2 ... libldap-2.4-releng.so.2
or
libldap.so... libldap.so
which are in /usr/local/openldap/lib64 and belong to LTB v2.4.x
...
/usr/local/openldap/lib != /usr/local/openldap/lib64
--
Sahil Tandon
Re: Disabling debug (DEBUG=)
On Fri, 2012-02-24 at 21:33:30 -0500, Gamet A. wrote: Here are my compilation command list: --- installDir=/usr/local/postfix-2.10 make CCARGS='-DNO_DB' tidy make makefiles CCARGS=-DNO_DB -I/usr/local/ldap/include -DHAS_LDAP -DDEF_CONFIG_DIR='$installDir/etc' -DDEF_COMMAND_DIR='$installDir/sbin' -DDEF_DAEMON_DIR='$installDir/libexec' -DDEF_MAILQ_DIR='$installDir/bin' -DDEF_DATA_DIR='$installDir/data' -DDEF_QUEUE_DIR='/var/log/postfix/spool' -DDEF_MANPAGE_DIR='$installDir/man' DEBUG='' \ UXLIBS=-L/usr/local/ldap/lib -lldap -L/usr/local/ldap/lib -llber AUXLIBS, not UXLIBS. See INSTALL, which explains how to turn off debugging, and the phrase: IMPORTANT: Be sure to get the quotes right. These details matter a lot. ... I tried with both DEBUG= and DEBUG='', but with the same above outcome. Are there any other parameters to pass to disable debug? ... DEBUG= -- Sahil Tandon
FreeBSD port for the experimental release [was Re: post-install, IPv6-only: could not find any active network interfaces (again)]
I do not usually announce FreeBSD port version bumps here, but in this case, I felt it appropriate. Sorry to those for whom this is not relevant. I have updated the development port to Postfix 2.9 Snapshot 20120102 and removed the erroneous conf/post-install patch that was discussed earlier in the thread, thus preserving Wietse's safety net for incompatible changes in IPv6 defaults. PS: if anyone on this list is a FreeBSD user with interest in the maintenance of the Postfix ports, please get in touch off-list. -- Sahil Tandon
Re: post-install, IPv6-only: could not find any active network interfaces (again)
On Wed, 2011-12-28 at 10:08:05 -0500, Wietse Venema wrote: Sahil Tandon: FWIW, the FreeBSD Postfix port is patched so that post-install does not add inet_protocols=ipv4 to main.cf during upgrades. Instead, users are notified[1] about the recent change of defaults, and asked to append the ipv4 line to their main.cf, if necessary. Sorry, THAT IS A MISTAKE. Sites that already Postfix have already chosen what protocols they use. They must not be forced to take action when upgrading. FORCING SITES TO CHANGE CONFIGURATION AFTER UPGRADE IS A MISTAKE. The distinction is mostly semantic and tangential to the main discussion, but for completeness: users are supposed to consult ports/UPDATING before (not after) upgrading. * If the site used IPv4 only before 2.9 then they must not have to change their configuration when upgrading to 2.9. YOUR CHANGE BREAKS THIS TRANSITION. * If the site used IPv4 and IPv6 before 2.9 then they already have an inet_protocols setting in main.cf. It you require that these sites make a change THEN YOUR CHANGE BREAKS THIS TRANSITION. Sites that have already chosen what protocol(s) to use with an explicit declaration of inet_protocols in main.cf are not required to do anything whatsoever. People who have been around for a while know that in the past 15 years, Postfix default settings have changed over time, and each time, the Postfix upgrade procedure made those transitions painless. CHANGES IN POSTFIX DEFAULTS MUST NOT REQUIRE USERS TO CHANGE CONFIGURATIONS WHEN UPGRADING. Sure, and I make every effort to avoid POLA violations in the FreeBSD ports/packages context, while at the same time trying to harmonize the Postfix port experience with how it's intended to be delivered by upstream (that is to say, you). PLEASE DO NOT BE LIKE OTHER IDIOT POSTFIX MAINTAINERS THAT BREAK POSTFIX WITH THEIR IMPROVEMENTS. My change did not break anything for people who abide by standard port upgrade procedures; this is in part evidenced by the absence of problem reports. However, I fully appreciate your sentiment, and concern that unexpected behavior due to foolish maintainer modifications often leads to clamoring for help on this mailing list. It is not my intention to override your intentions, or improve anything by patching files just for the heck of it. Having said that, I should have handled this better; I will revise the approach once you've incorporated your recent postfix-install patch into the -current snapshot, and I have had the time to test the impact on the port in a few different scenarios[1]. Meanwhile, I'll try my very best not be an idiot. ... [1] Another reason for handling the inet_protocols default change the way I did has to do with a side-effect that is local to how the port is generally setup; but that discussion is off-topic for this list and clearly of no interest to the members of this thread. -- Sahil Tandon pgp7EYkzN2xnv.pgp Description: PGP signature
Re: post-install, IPv6-only: could not find any active network interfaces (again)
On Wed, 2011-12-28 at 18:34:45 -0500, Wietse Venema wrote: ... Sites that use Postfix 2.8 without IPv6 have no inet_protocols setting in main.cf. They have never needed one because that was the default. Having to add inet_protocols = whatever for Postfix 2.9 is an unnecessary compatibility break that can be avoided. Sites that currently rely on the default (no IPv6) must not experience a compatibility break just because the built-in default was changed. It is a major mistake at this time to turn on IPv6 in Postfix by default, because it will suck performance for the far majority of sites with useless DNS lookups and useless connection attempts. This is harmful for Postfix market share. This point is not lost on me, and believe it or not: I'm actually an advocate of Postfix, so a loss of market share is counter to my own interests. Unlike some open source products, I plan incompatible changes very carefully. Where this is possible, this goes as follows: 1) First I change the built-in default; at the same time post-install is changed to make a compatibility update to main.cf that restores the old default, for sites that have relied on the old default. 2) Several years later, I remove the post-install code. If you cannot respect my effort to avoid incompatible changes, then I will revert the change of the inet_protocols default value and go back to Postfix 2.8 behavior. This means that people such as Mark Martinec wil have to jump some extra hoops when they wish to compile in an ipv4-less build environment. That is still better than having Postfix ruined by a maintainer who does not respect my attempts to phase in a major change with a great deal of care. In my reply to your initial message, I explicitly noted that I mishandled this situation, and should have considered another solution to address the ports-specific side effect caused by the inet_protocols change. Furthermore, I stated that I intend to align the port's behavior with how you correctly designed the inet_protocols change to be phased in. Where in all this do you construe a lack of respect for your efforts? If someome makes a mistake, they are not signaling a lack of respect for your work. In fact, in the context of this thread, your accusing of *me* for lacking respect towards *you* is disappointingly ironic. I do not believe Mark should have to jump through extra hoops, or that you should revert the change. This is a FreeBSD port-specific problem created by me that I will address as soon as I can. -- Sahil Tandon pgpAExDgZOayr.pgp Description: PGP signature
Re: post-install, IPv6-only: could not find any active network interfaces (again)
On Wed, 2011-12-28 at 19:48:48 -0500, Wietse Venema wrote: Sahil Tandon: I do not believe Mark should have to jump through extra hoops, or that you should revert the change. This is a FreeBSD port-specific problem created by me that I will address as soon as I can. Considering the short time left before the next stable release I am considering the following schedule: - Revert to Postfix 2.8 behavior, and complete the 2.9 release cycle. - In the 2.10 development cycle, make Postfix build on hosts that have no network interfaces. That would eliminate problems like Mark's hosts without IPv4, FreeBSD port builds on hosts with dysfunctional IPv6, and other weird environments. - In the 2.10 development cycle, (re)start the first phase of the IPv6-on-by-default transition, and do this early enough that there is time to make sure that all maintainers are on board. Shall follow along this new route, or I can modify the Postfix development port so that (happy to modify this as you deem appropriate): 1) fresh installs without existing main.cf use the new default inet_protocols setting. 2) sites with an existing main.cf WITHOUT inet_protocols defined have the ipv4 line added as you currently do via post-install. 3) sites with an existing main.cf WITH inet_protocols defined just keep their inet_protocols as is. Again, I'm already working on making the port work within the context of how you're currenting shipping development snapshots, but am on board with whichever path you choose from here. Won't make any changes until your decision is final so as to minimize further hassles. -- Sahil Tandon pgpnJTskeyC6H.pgp Description: PGP signature
Re: post-install, IPv6-only: could not find any active network interfaces (again)
On Tue, 2011-12-27 at 17:24:57 -0500, Wietse Venema wrote:
...
After I made inet_protocols=all the default on your request, I
received notice that Postfix no longer would build on freebsd.org
build systems, and that it would be removed from ports. These
build environments have IPv6 in the kernel but they have no IPv6
interfaces. Basically, these are IPv4-only boxes with can IPv6
configuration that violates the RFCs.
These changes were made to avoid being kicked out of the ports:
2017
Workaround: don't use IPv6 at build time. File: conf/main.cf.
Workaround: don't abort when IPv6 is present but busted.
File: util/inet_proto.c.
Now, I can easily remove the first workaround. But that won't
prevent the post-install script from adding inet_protocols=ipv4
to main.cf when you upgrade Postfix.
...
FWIW, the FreeBSD Postfix port is patched so that post-install does not
add inet_protocols=ipv4 to main.cf during upgrades. Instead, users are
notified[1] about the recent change of defaults, and asked to append the
ipv4 line to their main.cf, if necessary.
[1] This is in ports/UPDATING, a file users consult before upgrading any
port. I elected to go this route to force users to pay attention to
this particular change.
--
Sahil Tandon
--- conf/post-install.orig 2011-10-11 20:39:19.0 -0400
+++ conf/post-install 2011-10-11 20:41:58.0 -0400
@@ -790,18 +790,6 @@
EOF
}
-# Postfix 2.9.
-# Safety net for incompatible changes in IPv6 defaults. This
-# requires that the default is inet_protocols = ipv4 when
-# IPv6 support is not compiled in. See util/sys_defs.h.
-
-test `$POSTCONF -dh inet_protocols` = ipv4 ||
- test -n `$POSTCONF -c $config_directory -nh inet_protocols` || {
- echo COMPATIBILITY: editing main.cf, setting inet_protocols=ipv4.
- echo Specify inet_protocols explicitly if you want to enable IPv6.
- echo In a future release IPv6 will be enabled by default.
- $POSTCONF -c $config_directory inet_protocols=ipv4 || exit 1
-}
}
# A reminder if this is the first time Postfix is being installed.
Re: unknown host error clarification
On Mon, 2011-12-26 at 20:46:03 +1000, Nick Edwards wrote: ... Show the entire log snippet, of which you elided important parts. no, I did not, all I did not include was the from/to/helo, from/to are irrelevant and the helo, I already mentioned the 5xx resolved and the 4xx did not When you are asking for help on a technical mailing list, let the experts determine what is relevant. ... Show the output of 'postconf -n' instead of cut pasting from your main.cf. Why? The information above is all that is needed as relevant, nothing else in postconf output would, apart from sticky beaks wanting to know the ins and outs of everyones configs when it clearly is not needed, reveal any further information related to this, as already pointed out the SERVFAIL results in 4x error Yes, as I already indicated in my second response to your query. And your sticky beaks comment laughably strains credulity; no one cares about the ins and outs of your configuration. Before asking for help again, make sure to review the DEBUG_README (a document to which you were referred upon joining this mailing list). ... -- Sahil Tandon pgp9iILLYIubx.pgp Description: PGP signature
Re: unknown host error clarification
On Sun, 2011-12-25 at 13:37:52 +1000, Nick Edwards wrote: I am wondering why I have two different errors for same reason? : NOQUEUE: reject: RCPT from unknown[41.203.141.1]: 450 4.7.1 Client host rejected: cannot find your hostname, : NOQUEUE: reject: RCPT from unknown[115.153.142.125]: 550 5.7.1 Client host rejected: cannot find your hostname ... Show the entire log snippet, of which you elided important parts. ... unknown_client_reject_code = 550 unknown_address_reject_code = 550 unknown_hostname_reject_code = 550 unverified_sender_reject_code = 550 unknown_local_recipient_reject_code = 550 the relevant smtpd_recipient_restrictions options I using for this are ... Show the output of 'postconf -n' instead of cut pasting from your main.cf. -- Sahil Tandon
Re: unknown host error clarification
On Sun, 2011-12-25 at 13:37:52 +1000, Nick Edwards wrote: In the absence of full information, here's a WAG: ... : NOQUEUE: reject: RCPT from unknown[41.203.141.1]: 450 4.7.1 Client host rejected: cannot find your hostname, % host 41.203.141.1 Host 1.141.203.41.in-addr.arpa not found: 2(SERVFAIL) This is treated as a temporary error condition, so Postfix applies reject_tempfail_action, which defaults to defer_if_permit. ... -- Sahil Tandon
Re: unknown host error clarification
On Sat, 2011-12-24 at 23:09:24 -0500, Sahil Tandon wrote: On Sun, 2011-12-25 at 13:37:52 +1000, Nick Edwards wrote: In the absence of full information, here's a WAG: ... : NOQUEUE: reject: RCPT from unknown[41.203.141.1]: 450 4.7.1 Client host rejected: cannot find your hostname, % host 41.203.141.1 Host 1.141.203.41.in-addr.arpa not found: 2(SERVFAIL) This is treated as a temporary error condition, so Postfix applies reject_tempfail_action, which defaults to defer_if_permit. ... Also, from postconf(5): The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address-name or name-address lookup failed due to a temporary problem. -- Sahil Tandon
Re: postfix devnull mailbox
On Fri, 2011-12-23 at 12:10:10 +1300, Peter wrote: On 23/12/11 01:53, Stan Hoeppner wrote: On 12/21/2011 5:30 PM, Peter wrote: There is nothing more frustrating than trying to figure out why your emails are not going through to your customers than when they are accepted for delivery and *not* delivered. I have very little patience for anyone who insists on doing this. That's because you're confusing discarding spam with discarding legit mail. No. ... Because this thread has veered off into a general discussion about mail operation/policy, would you consider taking it off-list or to a more appropriate forum, e.g. the mailop list? -- Sahil Tandon
Re: warning: problem talking to service private/scache: Operation timed out
On Thu, 2011-12-15 at 19:26:39 -0500, Wietse Venema wrote: 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. OK, thanks for the context. -- Sahil Tandon
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
warning: problem talking to service private/scache: Operation timed out
: problem talking to service private/scache: Operation timed out Dec 14 03:00:14 mx0 postfix/smtp[53020]: warning: problem talking to service private/scache: Operation timed out Dec 14 03:00:14 mx0 postfix/smtp[53020]: warning: disabling connection caching Dec 14 03:00:14 mx0 postfix/smtp[53020]: F1EA38FC18: to=m...@example.org, relay=internal.example.org[ip_address]:25, delay=12, delays=0.46/0.05/12/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 2895F1065670) Dec 14 03:00:14 mx0 postfix/smtp[53020]: 044B48FC1A: to=f...@example.org, relay=internal.example.org[ip_address]:25, delay=9.5, delays=0.56/8.8/0/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 41BCD1065676) Dec 14 03:00:14 mx0 postfix/smtp[53020]: B60FD8FC14: to=f...@example.org, relay=internal.example.org[ip_address]:25, delay=9.9, delays=1.1/8.6/0/0.07, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5325E1065677) ... -- Sahil Tandon
Re: Postfix lost connection after DATA from unknown... and ipfilter -AF OUT log message
On Sun, 2011-12-11 at 18:10:34 -0500, Jim Seymour wrote: Looking in /var/log/maillog... Dec 11 17:47:08 myhost postfix/smtpd[48290]: connect from unknown[89.73.201.168] Dec 11 17:47:10 myhost postfix/smtpd[48290]: NOQUEUE: reject: RCPT from unknown[89.73.201.168]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [89.73.201.168]; from=a...@carloerbareactifs.com to=nngu...@mydom.ain proto=ESMTP helo=89-73-201-168.dynamic.chello.pl Dec 11 17:47:11 myhost postfix/smtpd[48290]: lost connection after DATA from unknown[89.73.201.168] Dec 11 17:47:11 myhost postfix/smtpd[48290]: disconnect from unknown[89.73.201.168] This particular one occurred seven times in a row, in quick succession. Postfix sends a 450 response because your DNS server cannot find the client's reverse hostname; following that, the client foolishly sends DATA, to which Postfix responds with a 554. Finally, instead of gracefully QUITing, the client drops the connection. -- Sahil Tandon
Re: SMTP hangs when MySQL is down
On Mon, 2011-12-05 at 10:42:30 +0100, Sebastian Wiesinger wrote: * Sahil Tandon sahil+post...@tandon.net [2011-12-05 03:24]: I'm using Postfix with MySQL via proxy:mysql maps. The documentation states that mails should get deferred if no mysql server is reachable. However when I shut down MySQL, SMTP transaction freeze after I enter the MAIL FROM:... statement. Any ideas how I can change that? There seems to be no timeout, I left the SMTP dialog open for a few minutes at least. Do not use SQL in virtual_mailbox_domains[1]; instead, set the latter to a regular list. Then, even when MySQL is down, Postfix will defer mail with 4.3.0 instead of appearing to freeze. that's not really an option for me, I need these lists in MySQL. It seems I have to live with it and make MySQL as stable as possible. Is your list of virtual mailbox domains that large or dynamic that it must be only in SQL? Note that you can still have virtual_mailbox_maps reference an SQL location; it is just virtual_mailbox_domains (and anything else that is used by trivial-rewrite(8)) that causes the stalling symptoms you describe above. [1] Actually, you should avoid using SQL or LDAP for any tables used by the trivial-rewrite(8) daemon. For context, see: Thanks for the context but I'm still not clear on why there is no way for postfix to delay every incoming mail when that happens. Is it because local mail (injected by sendmail interface) would probably get lost? Could you explain this in a bit more detail? Victor explains well in the posts to which I linked in my original reply. -- Sahil Tandon
Re: SMTP hangs when MySQL is down
On Mon, 2011-12-05 at 10:59:35 +0100, Reindl Harald wrote: Am 05.12.2011 10:42, schrieb Sebastian Wiesinger: Do not use SQL in virtual_mailbox_domains[1]; instead, set the latter to a regular list. Then, even when MySQL is down, Postfix will defer mail with 4.3.0 instead of appearing to freeze. Hi Sahil, that's not really an option for me, I need these lists in MySQL. It seems I have to live with it and make MySQL as stable as possible. there is no need not use mysql for any postfix configuration since 2009 ALL or mailservices are mysql-backed inclduing mail-storage and there are much more options used than on most other mailservers out there This is tangential to the topic. normally mysql is rock stable and never down That's great, but: the OP's question is explicitly about how Postfix functions when MySQL *is* down. The answer to that question - as noted earlier - depends on which facet of Postfix is impacted, which in turn depends on the parameters/tables configured to query an SQL backend. -- Sahil Tandon
Re: OT: Yahoo spam load
On Sun, 2011-12-04 at 17:06:02 -0600, Noel Jones wrote: On 12/4/2011 2:15 PM, /dev/rob0 wrote: The point about gets through postscreen probably was that it's not safe nor easy to try to block spammer-controlled freemail accounts through postscreen. In postscreen, there is no difference between freemail spam and real mail from freemail users. The only reasonable pre-DATA approach to freemail-origin spam is to use check_sender_access in smtpd against a list of known bad accounts. I've been using the clamav-milter along with the Sanesecurity add-on spam signatures to reject quite a bit of the freemail garbage. +1, FWIW. -- Sahil Tandon
Re: SMTP hangs when MySQL is down
On Mon, 2011-12-05 at 01:34:17 +0100, Sebastian Wiesinger wrote: I'm using Postfix with MySQL via proxy:mysql maps. The documentation states that mails should get deferred if no mysql server is reachable. However when I shut down MySQL, SMTP transaction freeze after I enter the MAIL FROM:... statement. Any ideas how I can change that? There seems to be no timeout, I left the SMTP dialog open for a few minutes at least. Do not use SQL in virtual_mailbox_domains[1]; instead, set the latter to a regular list. Then, even when MySQL is down, Postfix will defer mail with 4.3.0 instead of appearing to freeze. [1] Actually, you should avoid using SQL or LDAP for any tables used by the trivial-rewrite(8) daemon. For context, see: http://article.gmane.org/gmane.mail.postfix.user/209024 http://article.gmane.org/gmane.mail.postfix.user/168112 http://article.gmane.org/gmane.mail.postfix.user/140543 -- Sahil Tandon
Re: Reject external mail with local destination and local sender
On Mon, 2011-11-21 at 23:55:05 +0100, Nejc Škoberne wrote: I want to reject all mail, coming from outside (Internet), where the recipient domain is in my_destination and where sender domain is in my_destination as well. However, I want to accept such mail coming from my local network or from SASL authenticated users. How to achieve this? TMTOWTDI, but one way is via a policy service. This topic has been discussed numerous times on the list; see the below link and also search the archives for other options. http://archives.neohapsis.com/archives/postfix/2009-01/0483.html -- Sahil Tandon
bin/postconf: fatal: open /usr/local/etc/postfix/master.cf: No such file or directory
When trying to install snapshot 2018, I get a fatal postconf error if master.cf does not exist in the $config_directory. There is no problem if main.cf is missing from $config_directory; bin/postconf only seems to complain (at install stage, when called by the postfix-install script) if master.cf is not found. This is new to me, and could very well be idiosyncratic to my installation procedure. But before I troubleshoot further on my end, I wonder if anyone else can generally reproduce this? -- Sahil Tandon
Re: bin/postconf: fatal: open /usr/local/etc/postfix/master.cf: No such file or directory
On Sat, 2011-11-19 at 18:08:34 -0500, Wietse Venema wrote: Sahil Tandon: When trying to install snapshot 2018, I get a fatal postconf error if master.cf does not exist in the $config_directory. There is no problem if main.cf is missing from $config_directory; bin/postconf only seems to complain (at install stage, when called by the postfix-install script) if master.cf is not found. This is new to me, and could very well be idiosyncratic to my installation procedure. But before I troubleshoot further on my end, I wonder if anyone else can generally reproduce this? This is easy enough to fix. [ .. ] Indeed. Thanks! -- Sahil Tandon
./postconf: fatal: socket: Protocol not supported
This error was reported to me by a FreeBSD user, but I cannot reproduce it on any of my development machines. It occurs during build (sorry for line wraps): rm -f ../../conf/main.cf.default cp postconf ../../bin (echo # DO NOT EDIT THIS FILE. EDIT THE MAIN.CF FILE INSTEAD. THE; echo # TEXT HERE JUST SHOWS DEFAULT SETTINGS BUILT INTO POSTFIX.; echo #; ./postconf -d) |egrep -v '^(myhostname|mydomain|mynetworks) ' ../../conf/main.cf.default ./postconf: fatal: socket: Protocol not supported ... the full log is also available[1]. This is snapshot 20111012. FWIW, this issue was recently discussed[2] on a FreeBSD mailing list. There is something particular about the machine (to which I do not have access) on which the build fails. Has anyone seen similar socket errors via postconf? My next step is to solicit access to the problematic machine and troubleshoot further. [1] http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.2003071512/postfix-current-2.9.20111012,4.log [2] http://lists.freebsd.org/pipermail/freebsd-ports/2011-November/071419.html -- Sahil Tandon
Re: ./postconf: fatal: socket: Protocol not supported
On Tue, 2011-11-15 at 20:41:08 -0500, Wietse Venema wrote: Sahil Tandon: This error was reported to me by a FreeBSD user, but I cannot reproduce it on any of my development machines. It occurs during build (sorry for line wraps): rm -f ../../conf/main.cf.default cp postconf ../../bin (echo # DO NOT EDIT THIS FILE. EDIT THE MAIN.CF FILE INSTEAD. THE; echo # TEXT HERE JUST SHOWS DEFAULT SETTINGS BUILT INTO POSTFIX.; echo #; ./postconf -d) |egrep -v '^(myhostname|mydomain|mynetworks) ' ../../conf/main.cf.default ./postconf: fatal: socket: Protocol not supported [ .. ] Postconf opens a socket to determine the mynetworks value (it determines the local interfaces and their netmasks). I have heard about bizarre errors on FreeBSD (jail) systems where the user-land library was out of sync with kernel-land, resulting in data structure mis-matches and system calls returning nonsensical results. Thanks for the quick reply. -- Sahil Tandon
Re: 450 4.7.1 Client host rejected
On Wed, 2011-11-16 at 03:58:32 +0100, Reindl Harald wrote: is there any good reason why this is rejected with 450 instead 5xx to tell the sending server do not try again with your config? Yes, and that reason is documented in postconf(5). Nov 16 03:53:37 mail postfix/smtpd[15778]: NOQUEUE: reject: RCPT from unknown[193.83.162.5]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [193.83.162.5] http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname http://www.postfix.org/postconf.5.html#unknown_client_reject_code -- Sahil Tandon pgpR0UVO8YFyj.pgp Description: PGP signature
Re: Using Postfix for email retention
On Mon, 2011-10-10 at 07:20:22 +0530, Janantha Marasinghe wrote: I want to know if postfix can be used to save a copy of every e-mail sent and received (including attachments) by a mail server for email retention. See http://article.gmane.org/gmane.mail.postfix.user/221022 and the mailing list archive for similar discussions. If it could indexed for easier searching that would be great! This has to happen outside of Postfix. -- Sahil Tandon
Re: Different SMTP hostname greeting for each IP Address
On Sun, 2011-10-02 at 10:29:20 -0700, Cameron Smith wrote: telnet 74.63.3.132 smtp Trying 74.63.3.132... Connected to alwaysbuywholesale.com. Escape character is '^]'. 220 vps.velvetpixel.net ESMTP Postfix --This is not a match :( How do I change the SMTP banner for just the vhost dedicated IP 74.63.3.132 to 220 www.alwaysbuywholesale.com ESMTP Postfix and still keep the correct banner of 220 vps.velvetpixel.net ESMTP Postfix for 74.63.2.190? Set an alternative smtpd_banner for the smtpd(8) listener on 74.63.3.132. -- Sahil Tandon
Re: Different SMTP hostname greeting for each IP Address
On Sun, 2011-10-02 at 12:34:41 -0700, Cameron Smith wrote: On Oct 2, 2011, at 11:59 AM, Sahil Tandon wrote: On Sun, 2011-10-02 at 10:29:20 -0700, Cameron Smith wrote: telnet 74.63.3.132 smtp Trying 74.63.3.132... Connected to alwaysbuywholesale.com. Escape character is '^]'. 220 vps.velvetpixel.net ESMTP Postfix --This is not a match :( How do I change the SMTP banner for just the vhost dedicated IP 74.63.3.132 to 220 www.alwaysbuywholesale.com ESMTP Postfix and still keep the correct banner of 220 vps.velvetpixel.net ESMTP Postfix for 74.63.2.190? Set an alternative smtpd_banner for the smtpd(8) listener on 74.63.3.132. How do I do that? In master.cf, where you (presumably) setup the smtpd(8) instance that listens on 74.63.3.132. See: http://www.postfix.org/postconf.5.html#smtpd_banner http://www.postfix.org/master.5.html -- Sahil Tandon
Re: dual email delivery
On Wed, 2011-09-28 at 10:36:32 +0200, Roland de Lepper wrote: I was thinking about transport-maps, but this only relay the message to the new server. It will not record the message in Mysql first on the old server, before it will relay it to the new mailserver. This is somewhat of a FAQ: http://article.gmane.org/gmane.mail.postfix.user/183665 http://article.gmane.org/gmane.mail.postfix.user/123550 You may search the list archives for other examples, but the underlying notion is that multiple deliveries require multiple recipients. -- Sahil Tandon
Re: Off Topic: Auto-whitelisting from sent mail?
On Mon, 2011-09-19 at 18:38:22 -0400, john wrote: Does anybody know of a program... that can white list inbound email based upon the addresses of emails that have been sent? http://mailfud.org/postpals/ -- Sahil Tandon sa...@freebsd.org
Re: External domain with postfix
On Sun, 2011-08-28 at 08:43:03 -0400, Ted To wrote: I have a postfix server on a VPS and I have a domain (domain.name) that is pointing to my home ip address but I've directed mail towards VPS's IP address. The email.addr...@domain.name has been aliased to this email address (rainexpec...@theo.to) but mail sent externally to email.addr...@domain.name is getting a Relay access denied error. If I send mail to email.addr...@domain.name myself (through my VPS's postfix server), it gets through. What configuration setting do I need to add/change to get this to work? Show logs and the output of 'postconf -n' on the machine with a problem. -- Sahil Tandon sa...@freebsd.org
Re: Cert auth failure - untrusted issuer - after postfix upgrade
On Sat, 2011-08-20 at 09:19:54 +, Georg Sauthoff wrote: I upgraded my Ubuntu box from 10.04 to 11.10, i.e. postfix was upgraded from 2.7.0 to 2.8.0. The local postfix is setup to relay mail to a remote server, including mandatory TLS and certificate verification. The setup worked great with 2.7.0, but after the upgrade I get following errors: certificate verification failed for example.org untrusted issuer /C=DE/ST=NW/O=My CA/CN=Me/email=mys...@example.org [..] status=deferred (Server certificate not trusted) (I did not change the postfix config during the postfix upgrade) The directory /etc/postfix contains the certificate from the relay host (and c_rehash was executed). Was the verification algorithm somehow changed between postfix 2.7.0 and 2.8.0? Without more information, my WAG is that this could be related to Incompat 20100610 noted in the RELEASE_NOTES for 2.8. -- Sahil Tandon sa...@freebsd.org
Re: Puzzled by installation message on obsolete files/directories
On Sun, 2011-08-07 at 15:15:14 +0200, Bernard T. Higonnet wrote: In connection with various other problems I shall probably need help with later, I thought I might re-install Postfix 2.8.3 from ports in FreeBSD 8.2. As part of the install I get the following messages: FYI: 2.8.4 is the latest version in ports. Note: the following files or directories still exist but are no longer part of Postfix: /etc/postfix/access /etc/postfix/aliases /etc/postfix/canonical /etc/postfix/generic /etc/postfix/header_checks /etc/postfix/postfix-files /etc/postfix/relocated /etc/postfix/transport /etc/postfix/virtual /etc/postfix/postfix-script /etc/postfix/post-install These files are indeed obsolete, as indicated by their flags in conf/postfix-files. You will notice that postfix-script, postfix-files and post-install are still placed in the $daemon_directory; their redundant placement in $config_directory is obsolete. Similarly, the other files noted above were replicas of man pages which are still installed. -- Sahil Tandon sa...@freebsd.org
Re: Multiple Domains, Mail Gateway, Two Mail Servers
On Sun, 2011-08-07 at 11:08:13 -0400, Jim Seymour wrote: Wow, over 48 hours and no solution(s) suggested? Everybody on vacation? :) It is the weekend! :-) Without being privy to configuration details (IIRC you only shared a general description of mail routing), I think transport_maps on the gateway might solve your problem. -- Sahil Tandon sa...@freebsd.org
Re: your mail
On Tue, 2011-07-26 at 10:34:57 +0300, kibirango moses wrote: I configured recipient_blacklist using postfix as below in order to block users from replying fake emails. But i am getting problems with my mail clients as they are unable to send mail. Show logs that relate exactly to the problem you are trying to troubleshoot. smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/recipient_blacklist As noted in the DEBUG_README (a document to which you were linked upon joining this mailing list), please do not cutpaste from main.cf; instead, paste the output of 'postconf -n'. -- Sahil Tandon sa...@freebsd.org
Re: multiple copies delivered
On Tue, 2011-06-28 at 18:07:07 -0500, Jay G. Scott wrote: Presently user schumi gets copies of his mail delivered to three systems. The three destinations are listed in virtual_alias_maps. schumi: sch...@inm.arlut.utexas.edu, sch...@ns8.arlut.utexas.edu, sch...@vme.arlut.utexas.edu The ':' is invalid, so what is the actual (hint: copy and paste to minimize human error) content of your virtual alias map? By management fiat, mail that is addressed incorrectly to sch...@nonexistent.arlut.utexas.edu should be delivered to sch...@arlut.utexas.edu. It is, but I get multiple copies. Before proceeding any further, I am just curious: in order for sch...@nonexistent.arlut.utexas.edu to be accepted, that hostname must be defined (either explicitly or via wildcard) in a Postfix address class -- where does this occur in your configuration? Based on a cursory glance, it seems to me that a simple virtual alias mapping is more suitable than jumping through canonical hoops. Oh, and in your follow-up: please, show logs that relate to your problem description. -- Sahil Tandon sa...@freebsd.org
Re: Blocking web mail
On Mon, 2011-06-27 at 18:25:18 -0400, Jerry wrote: OK, I found it: authorized_submit_users = !apache,static:all Since I am running Apache on FreeBSD with user/group ownership of www I assume I would use this instead: authorized_submit_users = !www, static:all Yes, and incidentally, that is the example provided in the postconf(5) manual. -- Sahil Tandon sa...@freebsd.org
Re: postfix miltiligne greeting patch
On Sun, 2011-06-26 at 21:06:17 +0200, m...@smtp.fakessh.eu wrote: is it possible to declare a personal banner http://www.postfix.org/postconf.5.html#smtpd_banner http://postfix.wl0.org/en/smtpd-multiline-banner/ If you have questions related to third-party, unsupported patches, please direct them to the appropriate maintainer. -- Sahil Tandon sa...@freebsd.org
Re: best practices for received from header removal?
On Sat, 2011-06-25 at 10:32:07 +0200, Benny Pedersen wrote: On Thu, 23 Jun 2011 16:30:52 -0400, John Baker wrote: So what is the best practice in postfix for removing headers before they relay back out into Internet? contact there postmasters, no reply back ?, list at rfc-ignorant This is something the OP can do in *addition* to more practical things (as Noel suggested) to help mail reach its recipients on a remote site. -- Sahil Tandon sa...@freebsd.org
Re: Suggestion for docs
On Tue, 2011-06-21 at 18:45:47 -0400, Wietse Venema wrote: Peter: The SASL_README doc has a section about doing a telnet test of a PLAIN SASL authentication. There are some methods suggested for generating the base64 hash required to do the authentication, Of those two methods one requires downloading a special utility to generate the auth string and the other requires installing a perl module. I have a third suggestion: echo -ne '\000username\000password' | openssl base64 This method is relatively easy to do, and will work with the programs that are already readily available on most systems. I think it would be good to add it to the docs. This does not work for me. If you make a suggestion, be sure to indicate what platform and shell this applies to. Appears to work in bash and zsh; not in (t)csh. I quickly tested on FreeBSD and Darwin. Likely related to handling of null byte/char. -- Sahil Tandon sa...@freebsd.org
Re: Suggestion for docs
On Tue, 2011-06-21 at 19:20:52 -0400, Wietse Venema wrote: Sahil Tandon: Appears to work in bash and zsh; not in (t)csh. I quickly tested on FreeBSD and Darwin. Likely related to handling of null byte/char. I'm away from home, so I can't quickly fire up a ksh box. It certainly does not work with FreeBSD8 /bin/sh. Yep, the echo(1) one-liner fails but the printf(1) that Noel suggested succeeds. -- Sahil Tandon sa...@freebsd.org
Re: Multiple domain catchall to a script
On Tue, 2011-06-21 at 00:07:34 +0200, Mike McDonard wrote: * Email sent to token-re...@subdomain.example.com AND email sent to the...@token.subdomain.example.com should *all* be redirected to a specific script (that we write), which will need access to the _whole_ destination address. Perhaps you could direct those emails to a pipe(8) transport. http://www.postfix.org/pipe.8.html http://www.postfix.org/transport.5.html http://www.postfix.org/postconf.5.html#transport_maps -- Sahil Tandon sa...@freebsd.org
Re: Multiple domain catchall to a script
On Tue, 2011-06-21 at 00:46:36 +0200, Mike McDonard wrote: I am a little bit confused with the format of the transportmap file. The format is documented. :) What you are suggesting seems very similar to what eventum does. They seem to have the transport maps as a parameter to... $mydestination (!): Sorry, I am not familiar with eventum; but piping certain recipients to a script is doable in Postfix. Please follow the documentation, and follow-up in this thread if you have a specific problem with your configuration. -- Sahil Tandon sa...@freebsd.org
Re: postfix non-standard installation location quirks
On Tue, 2011-06-14 at 11:22:22 +1100, Winston Smith wrote: [ rant snipped ] Suggestion: Leave the scripts as they are, just state in the documentation that main.cf will not pick up install_root as prefix, rendering it useless. Where in the documentation does it say that install_root is in any way recorded in main.cf? -- Sahil Tandon sa...@freebsd.org
Re: postfix non-standard installation location quirks
On Mon, 2011-06-13 at 01:46:11 +1100, Winston Smith wrote: Trying to install postfix in a non-standard location (specifically /usr/local/ instead of /), I ran into two quirks, the second one more severe than the first one: Firstly, the naming of the config variable names the user is asked when saying make install is highly confusing: First, it is asking for the install_root, and then it is asking for destination directories and paths, providing something like /etc/postfix as default, which suggests that they are overriding the setting of install_root. When accepting the default or typing something else, it is later interpreted as relative to install_root EVEN IF it starts with a / . This is confusing. Maybe the description should be changed into Please enter XYZ *relative* to install_root, or the provided values should be interpreted as absolute paths if prepended with / and as relative paths (relative to install_root) if not. Secondly, the non-standard location is not reflected in main.cf . E.g. queue_directory still points to /var/spool/postfix/ . This is the value I typed in, and it was correctly (?) interpreted to be relative to /usr/local/, so make install created /usr/local/var/spool/postfix/ . Why is main.cf still pointing to /var/spool/postfix/ ? Is this the wrong target, or is the prefix /usr/local/ hardcoded in postfix somewhere after make install? Please see the postfix-install(1) script, specifically the section titled INSTALLATION PARAMETER DESCRIPTION. There, you are cautioned to specify install_root ONLY when creating pre‐built packages for distribution to other systems, and that the parameter setting is not recorded in main.cf. To install certain Postfix files under '/usr/local', pass that prefix to the installation parameter. For more information, carefully review the install script. After all, moving to autoconf would be a good idea because the generated Makefiles can handle non-standard installation locations very well, and it has become some sort of standard for C projects. There are no plans for moving to the beast that is autoconf; that, IMHO, is a good thing. -- Sahil Tandon sa...@freebsd.org
Re: ..::Troubleshooting Advice::..
On Wed, 2011-06-08 at 19:40:13 -0500, Alfonso Alejandro Reyes Jimenez wrote: We are going to work with an old postfix (I mean old because this postfix was installed and administered by another person), It works with LDAP. I don't have any experience working with LDAP authentication. I was wondering if you can give me some advices for troubleshooting, any advice will be appreciated. Your question is too general to be answered with specificity. Please describe an *actual* problem. Before responding, carefully consult the DEBUG_README, a document to which you were introduced upon joining this mailing list: http://www.postfix.org/DEBUG_README.html#mail For general information about LDAP support in Postfix: http://www.postfix.org/LDAP_README.html http://www.postfix.org/ldap_table.5.html -- Sahil Tandon sa...@freebsd.org
Re: Clarification between smtpd_sender_restrictions smtpd_recipient_restrictions
On Thu, 2011-06-09 at 07:30:31 +0530, Janantha Marasinghe wrote: I'm a bit confused between the smtpd_recipient_restrictions http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions smtpd_sender_restrictions I want to implement RBL on my mail server and I was thinking having the reject_rbl_client on the smtpd_sender_restrictions. If someone could clarify this to me it would be great. http://www.postfix.org/SMTPD_ACCESS_README.html -- Sahil Tandon sa...@freebsd.org
Re: No Netflix, lost connection after CONNECT
On Tue, 2011-05-31 at 20:22:56 -0500, Justin Tocci wrote: I tried tcpdump and that led me to check my router for possible issues. I am now on a DMZ so that should eliminate that as a possibility. You need to capture the packets between Netflix and your server (DMZ or elsewhere) and paste them somewhere for analysis. Use the '-w' flag in tcpdump to save the capture to a file. -- Sahil Tandon sa...@freebsd.org
Re: Put mails to specific users in HOLD queue
On Sun, 2011-05-22 at 17:16:52 +0200, Leon Meßner wrote: On Sun, May 22, 2011 at 04:39:22PM +0200, Pascal Volk wrote: On 05/22/2011 04:24 PM Leon Meßner wrote: Hi, i'm curious if there is a mechanism to stop postfix from delivering mail for just specific recipients. I ask because i need to migrate some users mail storage and need to umount it. It would be nice to generate no errors and just hold the mails in the queue until i release them again. /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: john@example.comretry:4.0.0 Mailbox being migrated jane@exmpale.comretry:4.0.0 Mailbox being migrated postmap /etc/postfix/transport postfix reload If i understand right, this will send 4.0.0 as smtp status code and thus force a retry on the other end. This will suffice i suppose. You misunderstand. As documented in error(8), when the service name is retry, Postfix defers all recipients in the delivery request using the next-hop information as the reason for non-delivery. -- Sahil Tandon sa...@freebsd.org
Re: Put mails to specific users in HOLD queue
On Sun, 2011-05-22 at 20:38:09 +0200, Ralf Hildebrandt wrote: * Leon Meßner l.mess...@physik.tu-berlin.de: Hi, i'm curious if there is a mechanism to stop postfix from delivering mail for just specific recipients. I ask because i need to migrate some users mail storage and need to umount it. It would be nice to generate no errors and just hold the mails in the queue until i release them again. Of course, simply use check_recipient_access: l.mess...@physik.tu-berlin.de hold This affects all recipients of a message; the retry transport is probably more suitable for the OP. -- Sahil Tandon sa...@freebsd.org
Re: Put mails to specific users in HOLD queue
On Sun, 2011-05-22 at 23:57:18 +0200, Jeroen Geilman wrote: On 05/22/2011 09:06 PM, Sahil Tandon wrote: On Sun, 2011-05-22 at 17:16:52 +0200, Leon Meßner wrote: On Sun, May 22, 2011 at 04:39:22PM +0200, Pascal Volk wrote: On 05/22/2011 04:24 PM Leon Meßner wrote: Hi, i'm curious if there is a mechanism to stop postfix from delivering mail for just specific recipients. I ask because i need to migrate some users mail storage and need to umount it. It would be nice to generate no errors and just hold the mails in the queue until i release them again. /etc/postfix/main.cf: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport: john@example.comretry:4.0.0 Mailbox being migrated jane@exmpale.comretry:4.0.0 Mailbox being migrated postmap /etc/postfix/transport postfix reload If i understand right, this will send 4.0.0 as smtp status code and thus force a retry on the other end. This will suffice i suppose. You misunderstand. As documented in error(8), when the service name is retry, Postfix defers all recipients in the delivery request using the next-hop information as the reason for non-delivery. That said, temporarily rejecting mail is actually the RFC-correct way to take a mail server and its mailboxes out of commission. Perhaps this is not an option for the OP due to reasons unknown to us. The HOLD queue is useful when you need to act on a small number of specific messages, but in general soft-rejecting would be better, because it informs the sender as well. The retry transport results in messages being placed into the deferred (not hold) queue. Of course, if he adapts his migration plan by first setting up the new mailbox destination system, a simple transport_maps entry is all that is required. Sure, but the OP had a specific requirement, and the proposed transport solution should fulfill it. A related example from the archives: http://article.gmane.org/gmane.mail.postfix.user/198002 -- Sahil Tandon sa...@freebsd.org
