Re: How to drop the recipient address hostname when delivering mail via LMTP?
I wonder if I was being too imprecise? I can of course provide postconf -n
(and/or dovecot -n) output if it should be required to answer my question.
Original Message
Subject: How to drop the recipient address hostname when delivering mail via
LMTP?
Date: Wed, 25 Aug 2010 21:08:42 +0200
From: Ralph Seichter postfix...@seichter.de
To: postfix-users@postfix.org
There is a thread in the Dovecot mailing list discussing this subject,
but I think it best to ask here aswell:
My Dovecot 2.0 configuration contains these lines
auth_username_format = %Ln
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
user = postfix
group = postfix
mode = 0660
}
}
and I have included the lines
myhostname = server.domain.tld
mydestination = $myhostname localhost.$mydomain localhost
mailbox_transport = lmtp:unix:private/dovecot-lmtp
in my main.cf. When Postfix is asked to deliver mail to
u...@server.domain.tld
it does so using Dovecot's LMTP socket. What bothers me about this
configuration is auth_username_format = %Ln in my Dovecot config.
The parameter affects all user lookups, which means that one cannot
distinguish between u...@domaina and u...@domainb during IMAP login.
I wonder how I can setup a transport which drops the @server.domain.tld
suffix when Postfix delivers mail via LMTP?
-Ralph
global output concurrency limit
Manao ahoana, Hello, Bonjour, I would like to setup a SMTP relay (out-only, no maildir delivery) that accepts messages for relay with high limit, but delivers slowly (i.e concurrency = 2). The spool will be big, then. I am looking for a setup that doesnt limit incoming messages, but globally (*not* per destination) limits the delivery. *destination_concurrency_limit settings are not what I want. I dont want a per-destination limit but a global one. I assume this relay I is a out-only and not a mix of IN/OUT. I had a look at the active queue control, and thought about qmgr_message_active_limit, but: Will the message input be limited (it's active, no?)? Misaotra, Thanks, Merci. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche Developpement +261 34 56 000 19
Postfix with PostgreSQL backend - number of connections to the database issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I use postfix with postgresql backend using pgsql_virtual_* maps. Is it possible somehow to limit the number of the connections to the postgresql databases? Sometimes the connection number grows up to 30-40. And it uses persistent connection as well. I'd be happy if postfix could use on demand postgresql connection. It seems postfix keeps-up 8-10-15 connections always, but i guess 2 or 3 would be enough. The queries are very quick, so it's not necessary to keep the SQL connection open. The documentation does not mention any part of this issue. Thanks in advance, - -- Adam PAPAI BSD Support Service http://www.wooh.hu E-mail: w...@wooh.hu Phone: +36 30 33-55-735 (Hungary) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMd4rtAAoJEGq0EWvh5uiIlmwIAMf75viNa/b31TbBV1quUcPw +wBbimnqtoieFHzvldPKyb3Ho3/JmEcThUlY2m3Hkx5L9KrOypHNpXSOVPntKGGN WW8X0hqEI59AWMG4ckBPDh2QX1xEYnYiBd0Cxjouk8c3ZqJIu2lCsUaZ3py22GBK ZvpajAx/rAvoNK9qd0wCTB3Dt8q+mTumP4Y3A/O2x3J0IdIQnnKGttySZYvF98qS cXRW71ifllXNKdi+bZtFZ6DqVKKTnGqnMxgp55ghAj7au1XhCs9ZllUDlIvvlmI+ +T0f8l5rWmr3xaYHfbjUDcu3sM64qyfj0Na+lctF8n/ZEs4YRZH1D5FlH8WoIF8= =6MMZ -END PGP SIGNATURE-
Re: Postfix with PostgreSQL backend - number of connections to the database issue
On Friday 27 August 2010 10:52:46 Adam PAPAI wrote: It seems postfix keeps-up 8-10-15 connections always, but i guess 2 or 3 would be enough. The queries are very quick, so it's not necessary to keep the SQL connection open. The documentation does not mention any part of this issue. Read the documentation concerning proxymap, if all tables are proxied then the connections should be limited by the number of proxymap processes, and all will be efficient. Although Postgres shouldn't have a problem with many tens of simulateneous connections. Open connections from idle processes shouldn't be a big issue either. The problem I have seen is under dictionary attack a box hit a limit on database connections before the botnet drove it into the dust on some other parameter. Ensuring everything used proxymap meant that it took a much bigger botnet to stop our email working - che sera sera. So if the number of connections you are seeing is an issue already it might be worth considering how robust things might be when nasty things start happening (Postfix is amazingly good under such conditions I find, although sometimes it throws up the odd sub-optimal configuration choice - like my not using proxymap for all tables).
Re: Postfix with PostgreSQL backend - number of connections to the database issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/27/10 12:24 PM, Simon Waters wrote: Read the documentation concerning proxymap, if all tables are proxied then the connections should be limited by the number of proxymap processes, and all will be efficient. Proxymap will probably solve my problem. Thanks! - -- Adam PAPAI NETIDEA Informatikai Szolgáltató Kft. http://www.netidea.hu E-mail: w...@wooh.hu Phone: +36 30 33-55-735 (Hungary) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMd5yYAAoJEGq0EWvh5uiIWQ0H/3hh9XEqmrSHlY7/48bC2qFG +R736HMF0eEfDpkeQyFqrsnnmtDxmYRP//tC0uqLIa+lE9v1ZhzWQzknDQ7Fay4A evolvrjHX8h0IgIKpZdN0m7BBgIgSZ1/iTpY0gKh+59vMM4Mtu2qYyDzKsV9gvDl j6jHAzw+AhuRrYYB2vyvIRY/kP5ilyxQID5HNRYeJ+A7Bneyv5qnrGDXyLamjzeu dRjkr2bisVbEVbdZiBMv5HEwDd5GLo1EuU7EoxDzHlSNAD0yxH8CHaek8Xl40h12 uGtfu1EYeVBO9yG0OgBADMsAgUC876ULNApC56SEtwyhQNdleIkuI76nnaaKC1I= =9vwv -END PGP SIGNATURE-
Re: Another timed out while sending end of data Error
Lie, Jafaruddin: Hi Wietse 1. No 220 *2**0**200*02*0*00 when telneting into the Exchange server: [r...@mailinglist]~# telnet x.x.1.74 25 Trying x.x.1.74... Connected to x.x.1.74 (192.168.1.74). Escape character is '^]'. 220 xx.xx.edu.au Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Aug 2010 11:35:55 +1000 There is no problem in Postfix that causes sessions to block, so it is a problem down-stream. You can record a session ON THE POSTFIX HOST with tcpdump (www.postfix.org/DEBUG_README.html) and see that the sending side is not in error. Wietse
Re: global output concurrency limit
Mihamina Rakotomandimby: I am looking for a setup that doesnt limit incoming messages, but globally (*not* per destination) limits the delivery. Configure the appropriate PROCESS LIMIT in master.cf. See: man 5 master Wietse
Want description
Hi, I want the description of following lines which are found in maillog file : Aug 27 04:23:21 dell860-504 postfix/scache[20225]: statistics: start interval Aug 27 04:19:59 Aug 27 04:23:21 dell860-504 postfix/scache[20225]: statistics: domain lookup hits=1 miss=10 success=9% Aug 27 04:23:21 dell860-504 postfix/scache[20225]: statistics: max simultaneous domains=1 addresses=1 connection=10 -- Incase of any further queries, Please feel free to mail me or contact me on the numbers provided below. Thanks Regards, Avinash Pawar Software Engineer. Viva Infomedia Pvt. Ltd. 242, Oshiwara Industrial Centre, New Link Road, Opp. Oshiwara Bus Depot, Goregaon West, Mumbai 400104. Direct: +91.22.40310356 Board: +91.22.40310310 Viva Infomedia: Awarded as Best SME (E-Commerce) at CNBC Emerging India Awards 2009
Re: Want description
On 2010-08-27 Avinash Pawar // Viva wrote: I want the description of following lines which are found in maillog file : Aug 27 04:23:21 dell860-504 postfix/scache[20225]: statistics: start interval Aug 27 04:19:59 Aug 27 04:23:21 dell860-504 postfix/scache[20225]: statistics: domain lookup hits=1 miss=10 success=9% Aug 27 04:23:21 dell860-504 postfix/scache[20225]: statistics: max simultaneous domains=1 addresses=1 connection=10 http://www.postfix.org/CONNECTION_CACHE_README.html Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Fixed: version of sendmail vacation for postfix
Thank you to everyone for helping me to solve that problem. You're right Simon, your email made me look at the vacation program even though I was not getting any error message. If anyone care to know the issue, I didn't have a /usr/sbin/sendmail link that is why nobody would get a vacation reply message. Daniel On 8/27/2010 3:53 AM, Simon Waters wrote: On Thursday 26 August 2010 21:48:06 Daniel Prieto wrote: delays=0.04/0/0/0.02, dsn=2.0.0, status=sent (delivered to command: /usr/bin/vacation testuser) I suspect at this point it ceases to be a postfix issue and becomes a vacation configuration issue.
Re: Mail rejected: Client host rejected: cannot find your hostname
On 8/26/2010 11:15 PM, Benoît Dubé wrote: Hi, I'm using zimbra with Postfix as MTA. I got the following error message which indicate mail rejection based on hostname not find. Aug 26 04:05:49 courriel postfix/smtpd[17755]: NOQUEUE: reject: RCPT from unknown[67.210.171.12]: 450 4.7.1 Client host rejected: cannot find your hostname, [67.210.171.12]; from=communi...@fcm.ca to=x...@domain.name.tld proto=ESMTP helo=smtp.fcm.ca However, the DNS config of the sender's mta looks good. Here are the reverse resolution and the forward resolution: bd...@bdube-laptop:~$ host 67.210.171.12 12.171.210.67.in-addr.arpa domain name pointer smtp.fcm.ca. bd...@bdube-laptop:~$ host smtp.fcm.ca smtp.fcm.ca has address 67.210.171.12 And for the MX field for this domain, I got: bd...@bdube-laptop:~$ dig fcm.ca MX ; DiG 9.7.0-P1 fcm.ca MX ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21616 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;fcm.ca.IN MX ;; ANSWER SECTION: fcm.ca. 900 IN MX 10 smtp.fcm.ca. fcm.ca. 900 IN MX 40 globalb.mxsave.com. fcm.ca. 900 IN MX 30 globala.mxsave.com. ;; Query time: 169 msec ;; SERVER: 24.200.241.37#53(24.200.241.37) ;; WHEN: Fri Aug 27 00:12:52 2010 ;; MSG SIZE rcvd: 103 Then, what are the other possible causes to have this mail rejected which are not tested by the commands I have done. Thanks for your help. Benoît Yes, this was rejected by reject_unknown_client_hostname. Yes, it appears the client's DNS is working correctly /now/. The mail was deferred with a 450 code. This implies that there was a temporary DNS error of some type. Just because dig works now doesn't guarantee that it worked when postfix asked earlier. You can look in the log for warning: messages from the postfix/smtpd[17755] process that proceed the reject message. -- Noel Jones
Re: TLS with Subject Alternative Name
On 8/24/2010 3:55 PM, Dieter Kluenter wrote: Clayton Kellerinetad...@ruraltel.net writes: First off, my apologies if this strays a bit off-list. I'm trying to setup a test environment using TLS and a self-signed certificate using Subject Alternative Name. From my research this should allow me to use multiple hostnames with a single certificate. I have no issues using TLS and a single domain with a self-signed cert. However, when creating the certificate using the multiple hostnames, my I see the following type of issue: 1. The email client generates an error indicating the certificate is invalid and requires an exception be added. 2. The following shows up in my logging: --- Aug 24 14:41:54 mta-test postfix/smtpd[27174]: SSL3 alert read:fatal:bad certificate Aug 24 14:41:54 mta-test postfix/smtpd[27174]: warning: TLS library problem: 27174:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1086:SSL alert number 42: --- If anyone has experience with the use of Subject Alternative Name with their certificates any info would greatly be appreciated, or any additional info regarding the SSL alert number 42 that I am seeing. If you create server certificates with openssl just add to openssl.cnf ... [ usr_cert ] ... subjectAltName=DNS:localhost,DNS:smtp2.example.com,DNS:smtp3.example.com ... and create and sign an appropriate server certificate. -Dieter I believe I have solved my problem. I was having issues with the mail client and the public CA cert, as well as making sure that CA cert was also in the file specified by smtpd_tls_CAfile. After taking care of both I am now successfully sending using a server name that is included in the list of Subject Alt. Name of the self-signed certificate. Looks like it was more along the lines of allowing them to trust the self-signed cert more than anything. Clay
Re: How to drop the recipient address hostname when delivering mail via LMTP?
On 8/27/2010 2:17 AM, Ralph Seichter wrote:
I wonder if I was being too imprecise? I can of course provide postconf -n
(and/or dovecot -n) output if it should be required to answer my question.
Original Message
Subject: How to drop the recipient address hostname when delivering mail via
LMTP?
Date: Wed, 25 Aug 2010 21:08:42 +0200
From: Ralph Seichterpostfix...@seichter.de
To: postfix-users@postfix.org
There is a thread in the Dovecot mailing list discussing this subject,
but I think it best to ask here aswell:
My Dovecot 2.0 configuration contains these lines
auth_username_format = %Ln
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
user = postfix
group = postfix
mode = 0660
}
}
and I have included the lines
myhostname = server.domain.tld
mydestination = $myhostname localhost.$mydomain localhost
mailbox_transport = lmtp:unix:private/dovecot-lmtp
in my main.cf. When Postfix is asked to deliver mail to
u...@server.domain.tld
it does so using Dovecot's LMTP socket. What bothers me about this
configuration is auth_username_format = %Ln in my Dovecot config.
The parameter affects all user lookups, which means that one cannot
distinguish between u...@domaina and u...@domainb during IMAP login.
I wonder how I can setup a transport which drops the @server.domain.tld
suffix when Postfix delivers mail via LMTP?
-Ralph
I think the problem is better solved in the delivery agent.
If you're using the postfix LMTP client, this might work:
http://www.postfix.org/postconf.5.html#lmtp_generic_maps
/^(.*)@server\.example\.com$/$1
This will also mangle To: headers.
If you're using a postfix pipe(8) based transport, you could
use the ${user} or ${mailbox} macros to eliminate the domain
name, but these options aren't available for lmtp or smtp.
http://www.postfix.org/pipe.8.html
-- Noel Jones
Re: How to drop the recipient address hostname when delivering mail via LMTP?
On Fri, Aug 27, 2010 at 10:58:37AM -0500, Noel Jones wrote: I think the problem is better solved in the delivery agent. If you're using the postfix LMTP client, this might work: http://www.postfix.org/postconf.5.html#lmtp_generic_maps /^(.*)@server\.example\.com$/$1 This will also mangle To: headers. Standard-compliant LMTP addresses are (as with SMTP) localp...@domain not localpart. So LMTP servers are expected to correctly map domains to mailboxes. It is best to no generate invalid LMTP, mangle the headers, ... -- Viktor.
Lookup key of smtp_tls_policy_maps
Dear list, I would be grateful for some input and confirmation about how smtp_tls_policy_maps works. The documentation are a bit obscure on the matter, and the results of my experimentation aren't perfectly clear to me. I found that smtp_tls_policy_maps is not necessarily indexed by the next-hop destination: in cases when there is no explicit next-hop defined in $transport_maps or $relayhost (and hence DNS would be asked for the MXs), the policy map is searched for the recipient's domain instead. This is probably done because DNS cannot generally be trusted, and the only information that can be trusted is the recipient domain. Can you confirm this? I have not found a way to override this behaviour (i.e. if DNSSEC is being used). Do you know of one? -- martin | http://madduck.net/ | http://two.sentenc.es/ always remember you're unique, just like everyone else. spamtraps: madduck.bo...@madduck.net digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
temporary dns errors are a pain
Is there any known policy server or add-on, that will change the tempfail action after a couple of hours, for things like reject_unknown_client_hostname and reject_unknown_client_hostname? Sending a reject has problems. I don't want to flat out reject, based on a temp error. Sending a 450 has problems. Some sender clients may try to resend the email, once per minute for two or three days before giving up. So while that message is in limbo on the sending server: The end user who sent it assumes that there is something wrong on our end. The recipient who expects it assumes that there is something wrong on our end. And the admin on the sender side does not find out that the problem is on their end, until several days later. I guess it would be an adaptation of greylisting, where. default unknown client/hostname = DEFER_IF_PERMIT greyhostclient policy firstseen timestamp for unknown client/hostname greyhostclient_delay = 4h return DEFER_IF_PERMIT during the 4h window. Then after 4 hours, REJECT is returned instead. Anything like that out there?
Re: temporary dns errors are a pain
pf at alt-ctrl-del.org put forth on 8/27/2010 1:23 PM: Is there any known policy server or add-on, that will change the tempfail action after a couple of hours, for things like reject_unknown_client_hostname and reject_unknown_client_hostname? Sending a reject has problems. I don't want to flat out reject, based on a temp error. Sending a 450 has problems. Some sender clients may try to resend the email, once per minute for two or three days before giving up. So while that message is in limbo on the sending server: The end user who sent it assumes that there is something wrong on our end. The recipient who expects it assumes that there is something wrong on our end. And the admin on the sender side does not find out that the problem is on their end, until several days later. I guess it would be an adaptation of greylisting, where. default unknown client/hostname = DEFER_IF_PERMIT greyhostclient policy firstseen timestamp for unknown client/hostname greyhostclient_delay = 4h return DEFER_IF_PERMIT during the 4h window. Then after 4 hours, REJECT is returned instead. Anything like that out there? You're barking up the wrong tree. Assuming you have Postfix 2.3 or later, use reject_unknown_reverse_client_hostname _instead of _ reject_unknown_client_hostname Read the definition of each at: http://www.postfix.org/postconf.5.html#smtpd_client_restrictions reject_unknown_client_hostname is far too restrictive in most cases, and will cause all kinds of temp fails. It will, for instance, temp fail every connection from Hotmail (unless MS fixed their DNS recently). -- Stan
Re: temporary dns errors are a pain
Is there any known policy server or add-on, that will change the tempfail action after a couple of hours, for things like reject_unknown_client_hostname and reject_unknown_client_hostname? Sending a reject has problems. I don't want to flat out reject, based on a temp error. Sending a 450 has problems. Some sender clients may try to resend the email, once per minute for two or three days before giving up. So while that message is in limbo on the sending server: The end user who sent it assumes that there is something wrong on our end. The recipient who expects it assumes that there is something wrong on our end. And the admin on the sender side does not find out that the problem is on their end, until several days later. I guess it would be an adaptation of greylisting, where. default unknown client/hostname = DEFER_IF_PERMIT greyhostclient policy firstseen timestamp for unknown client/hostname greyhostclient_delay = 4h return DEFER_IF_PERMIT during the 4h window. Then after 4 hours, REJECT is returned instead. Anything like that out there? I meant reject_unknown_helo_hostname and reject_unknown_client_hostname. Not the double listing of reject_unknown_client_hostname
Baffled by User unknown in virtual alias table
I have a working Postfix server, and I copied the configuration files over to another box with the exact same version(s) to do some testing. But right away the box won't deliver messages to virtual domains, it always says User unknown in virtual alias table. After what looks like a successful lookup: Aug 27 14:49:42 localhost postfix/smtpd[4963]: CHECKING RECIPIENT MAPS existing entry key adam.t.willi...@example.com ... Aug 27 14:49:42 localhost postfix/smtpd[4963]: dict_ldap_lookup: No existing connection for LDAP source /etc/postfix/ldap-delivery.cf, reopening .. dict_ldap_lookup: /etc/postfix/ldap-delivery.cf: Searching with filter ((objectclass=inetLocalMailRecipient)(maillocaladdress=adam.t.willi...@example.com)) Aug 27 14:49:42 localhost postfix/smtpd[4963]: dict_ldap_get_values[1]: Search found 1 match(es) Aug 27 14:49:42 localhost postfix/smtpd[4963]: dict_ldap_get_values[1]: search returned 1 value(s) for requested result attribute mailRoutingAddress Aug 27 14:49:42 localhost postfix/smtpd[4963]: dict_ldap_get_values[1]: Leaving dict_ldap_get_values Aug 27 14:49:42 localhost postfix/smtpd[4963]: dict_ldap_lookup: Search returned ot...@example.com Aug 27 14:49:42 localhost postfix/smtpd[4963]: maps_find: virtual_alias_maps: ldap:/etc/postfix/ldap-delivery.cf(0,lock|fold_fix): adam.t.willi...@example.com = ot...@example.com Aug 27 14:49:42 localhost postfix/smtpd[4963]: mail_addr_find: adam.t.willi...@example.com - ot...@example.com - then, down the file - Aug 27 14:49:42 localhost postfix/smtpd[4963]: unknown[172.16.54.1]: 250 2.0.0 Ok Aug 27 14:49:42 localhost postfix/smtpd[4963]: watchdog_pat: 0x9840df0 Aug 27 14:49:42 localhost postfix/smtpd[4963]: vstream_fflush_some: fd 10 flush 14 Aug 27 14:49:42 localhost postfix/error[4967]: 36FEBC03B5: to=adam.t.willi...@example.com, relay=none, delay=0.1, delays=0.08/0.01/0/0.01, dsn=5.0.0, status=bounced (User unknown in virtual alias table) Aug 27 14:49:42 localhost postfix/cleanup[4966]: 4AA66C03B7: message-id=20100827184942.4aa66c0...@kyack.example.com Aug 27 14:49:42 localhost postfix/qmgr[4961]: 4AA66C03B7: from=, size=2335, nrcpt=1 (queue active) What could I be missing?
Re: How to drop the recipient address hostname when delivering mail via LMTP?
On Fri, 27 Aug 2010 12:22:59 -0400, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Fri, Aug 27, 2010 at 10:58:37AM -0500, Noel Jones wrote: I think the problem is better solved in the delivery agent. If you're using the postfix LMTP client, this might work: http://www.postfix.org/postconf.5.html#lmtp_generic_maps /^(.*)@server\.example\.com$/$1 This will also mangle To: headers. Standard-compliant LMTP addresses are (as with SMTP) localp...@domain not localpart. So LMTP servers are expected to correctly map domains to mailboxes. It is best to no generate invalid LMTP, mangle the headers, ... I wonder What is the best solution to use dovecot lda for its use or complicate the config using lmtp dovecot whereas with a simple config we manage to walk amavisd what is it the best way many welcome are smile
Re: temporary dns errors are a pain
On 8/27/2010 1:43 PM, Stan Hoeppner wrote: pf at alt-ctrl-del.org put forth on 8/27/2010 1:23 PM: Is there any known policy server or add-on, that will change the tempfail action after a couple of hours, for things like reject_unknown_client_hostname and reject_unknown_client_hostname? Sending a reject has problems. I don't want to flat out reject, based on a temp error. Sending a 450 has problems. Some sender clients may try to resend the email, once per minute for two or three days before giving up. So while that message is in limbo on the sending server: The end user who sent it assumes that there is something wrong on our end. The recipient who expects it assumes that there is something wrong on our end. And the admin on the sender side does not find out that the problem is on their end, until several days later. I guess it would be an adaptation of greylisting, where. default unknown client/hostname = DEFER_IF_PERMIT greyhostclient policy firstseen timestamp for unknown client/hostname greyhostclient_delay = 4h return DEFER_IF_PERMIT during the 4h window. Then after 4 hours, REJECT is returned instead. Anything like that out there? You're barking up the wrong tree. Assuming you have Postfix 2.3 or later, use reject_unknown_reverse_client_hostname _instead of _ reject_unknown_client_hostname Read the definition of each at: http://www.postfix.org/postconf.5.html#smtpd_client_restrictions This will only help for clients with no rDNS; no effect on clients where the forward hostname lookup fails, nor where the rDNS lookup fails. Mr. pf will need to write his own policy server. A greylist policy is a good place to start. reject_unknown_client_hostname is far too restrictive in most cases, Generally true, but outsiders don't dictate local policy. and will cause all kinds of temp fails. It would be irresponsible of postfix to lose mail just because someone's DNS hiccuped. Persistent clients will need to be added to a local blacklist - that's what the OP wants to automate. It will, for instance, temp fail every connection from Hotmail (unless MS fixed their DNS recently). You'll need to show evidence of that claim. Hotmail passes reject_unknown_client_hostname here consistently. In fact I have a check_sender_access map that specifically does reject_unknown_client_hostname on any @hotmail sender address. -- Noel Jones
Re: temporary dns errors are a pain
On 8/27/2010 2:41 PM, pf at alt-ctrl-del.org wrote: On: August 27, 2010 2:23 PM, I wrote: Is there any known policy server or add-on, that will change the tempfail action after a couple of hours, for things like reject_unknown_client_hostname and reject_unknown_client_hostname? I guess it would be an adaptation of greylisting, where. default unknown client/hostname = DEFER_IF_PERMIT greyhostclient policy firstseen timestamp for unknown client/hostname greyhostclient_delay = 4h return DEFER_IF_PERMIT during the 4h window. Then after 4 hours, REJECT is returned instead. Anything like that out there? Well, the first half was easy. I just made a few minor changes to the example greylist.pl. My greyhelo.pl works from the example test of: perl greyhelo.pl (bunch of attributes) But how to call it, only when a client fails reject_unknown_helo_hostname? The following does not work: unknown_helo_hostname_tempfail_action = check_policy_service unix:private/greyhelo You'll have to call the policy service for each mail, and recreate the reject_unknown_* tests in your policy server. That's the only way you can detect temp failures. -- Noel Jones
Re: Baffled by User unknown in virtual alias table
Adam Tauno Williams: virtual_alias_maps: ldap:/etc/postfix/ldap-delivery.cf(0,lock|fold_fix): adam.t.willi...@example.com = ot...@example.com As DOCUMENTED, virtual alias domains MUST replace the recipient domain by a DIFFERENT domain
Re: temporary dns errors are a pain
Noel Jones, August 27, 2010 3:56 PM:
On: August 27, 2010 2:23 PM, I wrote:
Is there any known policy server or add-on, that will change
the tempfail action after a couple of hours, for things like
reject_unknown_client_hostname and
reject_unknown_client_hostname?
I guess it would be an adaptation of greylisting,
Anything like that out there?
Well, the first half was easy. I just made a few minor changes
to the example greylist.pl.
My greyhelo.pl works from the example test of: perl
greyhelo.pl (bunch of attributes)
But how to call it, only when a client fails
reject_unknown_helo_hostname?
The following does not work:
unknown_helo_hostname_tempfail_action = check_policy_service
unix:private/greyhelo
You'll have to call the policy service for each mail, and
recreate the reject_unknown_* tests in your policy server.
That's the only way you can detect temp failures.
So I'd have to test for nxdomain, against $attr{helo_name}?
Sounds easy enough. But unfortunately, beyond my skill set.
Re: temporary dns errors are a pain
pf at alt-ctrl-del.org:
Noel Jones, August 27, 2010 3:56 PM:
On: August 27, 2010 2:23 PM, I wrote:
Is there any known policy server or add-on, that will change
the tempfail action after a couple of hours, for things like
reject_unknown_client_hostname and
reject_unknown_client_hostname?
I guess it would be an adaptation of greylisting,
Anything like that out there?
Well, the first half was easy. I just made a few minor changes
to the example greylist.pl.
My greyhelo.pl works from the example test of: perl
greyhelo.pl (bunch of attributes)
But how to call it, only when a client fails
reject_unknown_helo_hostname?
The following does not work:
unknown_helo_hostname_tempfail_action = check_policy_service
unix:private/greyhelo
You'll have to call the policy service for each mail, and
recreate the reject_unknown_* tests in your policy server.
That's the only way you can detect temp failures.
So I'd have to test for nxdomain, against $attr{helo_name}?
Postfix already replies with a 5XX for an NXDOMAIN result.
Wietse
RE: Another timed out while sending end of data Error
Thanks, Wietse. At this stage it is working again. I think you are right, it must be something downstream because when I relayed the mails from the queue to another mail server, all went through ok. I have a suspicion it might be the spam filter on the Exchange server (was told it runs Trend's ScanMail) If it happens again, I'll follow the instruction to debug :) -Original Message- From: owner-postfix-us...@postfix.org on behalf of Wietse Venema Sent: Fri 8/27/2010 9:08 PM To: Postfix users Subject: Re: Another timed out while sending end of data Error Lie, Jafaruddin: Hi Wietse 1. No 220 *2**0**200*02*0*00 when telneting into the Exchange server: [r...@mailinglist]~# telnet x.x.1.74 25 Trying x.x.1.74... Connected to x.x.1.74 (192.168.1.74). Escape character is '^]'. 220 xx.xx.edu.au Microsoft ESMTP MAIL Service, Version: 6.0.3790.4675 ready at Fri, 27 Aug 2010 11:35:55 +1000 There is no problem in Postfix that causes sessions to block, so it is a problem down-stream. You can record a session ON THE POSTFIX HOST with tcpdump (www.postfix.org/DEBUG_README.html) and see that the sending side is not in error. Wietse - Please consider the environment before you print
Re: Delayed-ACK holdups to a proxy content filter on lo0 for mid-size messages
On Friday August 27 2010 19:06:02 Victor Duchovni wrote: Just so everyone else is clear on the context, this is not a post-queue content_filter issue (post-queue content filters use the SMTP/LMTP delivery agent which already does the right thing). This applies only to the pre-queue proxy filters. True. Post-queue content filtering setup was not affected. You could try the following patch: That was fast!!! Looks good, both a test case and later our main mailer now behave as they should, no more 100ms entries in the logs. I'll grep the logs on Monday to re-gather statistics just in case, but it seems the patch does the right thing. Thank you! Mark
Re: temporary dns errors are a pain
pf at alt-ctrl-del.org:
Wietse:
pf at alt-ctrl-del.org:
Noel Jones, August 27, 2010 3:56 PM:
On: August 27, 2010 2:23 PM, I wrote:
Is there any known policy server or add-on, that will change
the tempfail action after a couple of hours, for things like
reject_unknown_client_hostname and
reject_unknown_client_hostname?
I guess it would be an adaptation of greylisting,
Anything like that out there?
Well, the first half was easy. I just made a few minor changes
to the example greylist.pl.
My greyhelo.pl works from the example test of: perl
greyhelo.pl (bunch of attributes)
But how to call it, only when a client fails
reject_unknown_helo_hostname?
The following does not work:
unknown_helo_hostname_tempfail_action = check_policy_service
unix:private/greyhelo
You'll have to call the policy service for each mail, and
recreate the reject_unknown_* tests in your policy server.
That's the only way you can detect temp failures.
So I'd have to test for nxdomain, against $attr{helo_name}?
Postfix already replies with a 5XX for an NXDOMAIN result.
??
nslookup mailserver.jtl.co.in
google-public-dns-a.google.com can't find mailserver.jtl.co.in: Non-existent
domain
NOQUEUE: reject: RCPT from outgoing.jeevantechnologies.com[61.12.114.170]:
450 4.7.1 mailserver.jtl.co.in:
Helo command rejected: Host not found;
proto=ESMTP helo=mailserver.jtl.co.in
postconf | grep 450
Re: Delayed-ACK holdups to a proxy content filter on lo0 for mid-size messages
Mark Martinec: On Friday August 27 2010 19:06:02 Victor Duchovni wrote: Just so everyone else is clear on the context, this is not a post-queue content_filter issue (post-queue content filters use the SMTP/LMTP delivery agent which already does the right thing). This applies only to the pre-queue proxy filters. True. Post-queue content filtering setup was not affected. You could try the following patch: That was fast!!! Looks good, both a test case and later our main mailer now behave as they should, no more 100ms entries in the logs. I'll grep the logs on Monday to re-gather statistics just in case, but it seems the patch does the right thing. You are also welcome to have a look at today's Postfix snapshot 20100827. Wietse
Re: temporary dns errors are a pain
Wietse:
pf at alt-ctrl-del.org:
Noel Jones, August 27, 2010 3:56 PM:
On: August 27, 2010 2:23 PM, I wrote:
Is there any known policy server or add-on, that will change
the tempfail action after a couple of hours, for things like
reject_unknown_client_hostname and
reject_unknown_client_hostname?
I guess it would be an adaptation of greylisting,
Anything like that out there?
Well, the first half was easy. I just made a few minor changes
to the example greylist.pl.
My greyhelo.pl works from the example test of: perl
greyhelo.pl (bunch of attributes)
But how to call it, only when a client fails
reject_unknown_helo_hostname?
The following does not work:
unknown_helo_hostname_tempfail_action = check_policy_service
unix:private/greyhelo
You'll have to call the policy service for each mail, and
recreate the reject_unknown_* tests in your policy server.
That's the only way you can detect temp failures.
So I'd have to test for nxdomain, against $attr{helo_name}?
Postfix already replies with a 5XX for an NXDOMAIN result.
??
nslookup mailserver.jtl.co.in
google-public-dns-a.google.com can't find mailserver.jtl.co.in:
Non-existent
domain
NOQUEUE: reject: RCPT from
outgoing.jeevantechnologies.com[61.12.114.170]:
450 4.7.1 mailserver.jtl.co.in:
Helo command rejected: Host not found;
proto=ESMTP helo=mailserver.jtl.co.in
postconf | grep 450
Wietse, I was looking for a way to do both temporary and permanent rejects.
Not one or the other.
Default to a temporary reject for temporary errors, then return a permanent
reject to a specific client after x attempts or x hours.
Greylisting gives a default defer, then dunno after x minutes.
I was thinking along the lines of default defer, then reject after x
minutes, for reject_unknown_helo_hostname clients.
Re: temporary dns errors are a pain
On 8/27/2010 8:36 PM, pf at alt-ctrl-del.org wrote:
Wietse:
pf at alt-ctrl-del.org:
Noel Jones, August 27, 2010 3:56 PM:
On: August 27, 2010 2:23 PM, I wrote:
Is there any known policy server or add-on, that
will change
the tempfail action after a couple of hours, for
things like
reject_unknown_client_hostname and
reject_unknown_client_hostname?
I guess it would be an adaptation of greylisting,
Anything like that out there?
Well, the first half was easy. I just made a few
minor changes
to the example greylist.pl.
My greyhelo.pl works from the example test of: perl
greyhelo.pl (bunch of attributes)
But how to call it, only when a client fails
reject_unknown_helo_hostname?
The following does not work:
unknown_helo_hostname_tempfail_action =
check_policy_service
unix:private/greyhelo
You'll have to call the policy service for each mail, and
recreate the reject_unknown_* tests in your policy
server.
That's the only way you can detect temp failures.
So I'd have to test for nxdomain, against
$attr{helo_name}?
Postfix already replies with a 5XX for an NXDOMAIN result.
??
nslookup mailserver.jtl.co.in
google-public-dns-a.google.com can't find
mailserver.jtl.co.in: Non-existent
domain
NOQUEUE: reject: RCPT from
outgoing.jeevantechnologies.com[61.12.114.170]:
450 4.7.1 mailserver.jtl.co.in:
Helo command rejected: Host not found;
proto=ESMTP helo=mailserver.jtl.co.in
postconf | grep 450
Wietse, I was looking for a way to do both temporary and
permanent rejects.
Not one or the other.
With unknown_hostname_reject_code set to 550, NXDOMAIN hosts
will be rejected, and temporary error hosts will get the
unknown_helo_hostname_tempfail_action (default
DEFER_IF_PERMIT). So you do get both.
Default to a temporary reject for temporary errors, then
return a permanent
reject to a specific client after x attempts or x hours.
Greylisting gives a default defer, then dunno after x minutes.
I was thinking along the lines of default defer, then reject
after x
minutes, for reject_unknown_helo_hostname clients.
Any kind of counting will need to be done in a policy server.
Maybe you can cheat and only pass the clients that tempfail to
the policy server, try this:
# main.cf
unknown_hostname_reject_code = 550
Hmmm, I bet the check_policy_service will need to be in a
restriction class... Continuing main.cf:
unknown_helo_hostname_tempfail_action = helo_tempfail_test
smtpd_restriction_classes = helo_tempfail_test
helo_tempfail_test =
check_policy_service foo:bar
where foo:bar is the policy service endpoint.
-- Noel Jones
Re: temporary dns errors are a pain
pf at alt-ctrl-del.org: Postfix already replies with a 5XX for an NXDOMAIN result. NOQUEUE: reject: RCPT from outgoing.jeevantechnologies.com[61.12.114.170]: 450 4.7.1 mailserver.jtl.co.in: Helo command rejected: Host not found; proto=ESMTP helo=mailserver.jtl.co.in postconf | grep 450 Meaning, you need to RTFM these parameters. Wietse
Re: temporary dns errors are a pain
Noel Jones put forth on 8/27/2010 2:28 PM: You'll need to show evidence of that claim. Hotmail passes reject_unknown_client_hostname here consistently. In fact I have a check_sender_access map that specifically does reject_unknown_client_hostname on any @hotmail sender address. Unfortunately this occurred many many months ago and I didn't save any logs or the correspondence. Upon reflection, the hotmail farm servers themselves may not have had the problem. The servers sending the abuse desk acks definitely had the problem--mismatched forward/reverse names. I specifically had to disable reject_unknown_client_hostname to allow them through. I wasn't about to whitelist them. After this saga I switched back to reject_unknown_reverse_client_hostname and haven't had problems with MS or any other site since, WRT these checks. -- Stan
Re: temporary dns errors are a pain
Wietse: Postfix already replies with a 5XX for an NXDOMAIN result. pf at alt-ctrl-del.org: nslookup mailserver.jtl.co.in google-public-dns-a.google.com can't find mailserver.jtl.co.in: Non-existent domain NOQUEUE: reject: RCPT from outgoing.jeevantechnologies.com[61.12.114.170]: 450 4.7.1 mailserver.jtl.co.in: Helo command rejected: Host not found; proto=ESMTP helo=mailserver.jtl.co.in Wietse: postconf | grep 450 pf at alt-ctrl-del.org: Wietse, I was looking for a way to do both temporary and permanent rejects. Not one or the other. Noel Jones: With unknown_hostname_reject_code set to 550, NXDOMAIN hosts will be rejected, and temporary error hosts will get the unknown_helo_hostname_tempfail_action (default DEFER_IF_PERMIT). So you do get both. Thanks, I guess I missed that in the docs, about the behavior if set to 550. In my reading of the docs, I thought that dns is unreliable and that anything that is not found via dns lookup is treated as a tempfail. Any kind of counting will need to be done in a policy server. Maybe you can cheat and only pass the clients that tempfail to the policy server, try this: # main.cf unknown_hostname_reject_code = 550 Hmmm, I bet the check_policy_service will need to be in a restriction class... Continuing main.cf: unknown_helo_hostname_tempfail_action = helo_tempfail_test smtpd_restriction_classes = helo_tempfail_test helo_tempfail_test = check_policy_service foo:bar where foo:bar is the policy service endpoint. I've had something very similar running for the last few hours. An access table sends all .cc helo domains to a custom restriction_class, that then kicks off to the policy service. Which returns 450 for 4 hours, then 504. Noel, thanks for your plain language answers. Wietse, thanks for creating a smtp server that is flexible enough to let me do this sort of thing, even if it isn't needed.
