Turning of milter checks
I'm running postfix 2.5.6, and I'm using amavis through the milter interface by setting 'smtpd_milters= inet:[127.0.0.1]:10023'. I'm trying to set up a different port for skipping amavis checks on email that has already been checked. In master.cf I have: 2525inetn - n - - smtpd -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8,xx.yy.zz.0/24 It is still being handed off to amavis via the milter interface. I tried adding '-o smtpd_milters=' but that didn't stop it either. The above worked in postfix 2.4.6. Any idea why this isn't working? Thanks, Dan
Re: Turning of milter checks
On Thu, Apr 23, 2009 at 6:14 PM, Wietse Venema wrote: > > First, show that Postfix receives mail via port 2525. This requires > a transcript of a telnet session, and the Postfix logging for the > corresponding email delivery. > > Second, show with "ps" command output that port 2525 actually has > receive_override_options=no_milters. It won't have this unless you > do "postfix reload". > >Wietse > I misspoke slightly. I actually have this in master.conf: 2525inetn - n - - smtpd -o content_filter= -o receive_override_options=no_header_body_checks,no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8,xx.yy.zz.0/24 The pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks If I remove no_header_body_checks (-o receive_override_options=no_milters) it works: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 If I have just no_header_body_checks (-o receive_override_options=no_header_body_checks) it does not work: 92553 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks I believe that the ps output is sufficient to see the problem, but if you still want the telnet transcript, I can provide that. Here is log entries showing no errors (I didn't do a full session, just enough to get a ps): Apr 23 19:31:24 mail5 postfix/master[940]: reload configuration /usr/local/etc/postfix Apr 23 19:31:32 mail5 postfix/smtpd[93895]: connect from server.example.net [xx.yy.zz.140] Apr 23 19:32:33 mail5 postfix/smtpd[93895]: timeout after CONNECT from server.example.net[xx.yy.zz.140]
Re: Turning of milter checks
On Fri, Apr 24, 2009 at 6:48 AM, Wietse Venema wrote: > FYI, > > The header_checks parameter does not control whether or not Milter > operation is invoked, so your observations are incorrect. > > If you want to pursue this further, show a telnet mail submission > and the corresponding logging. > > Also, instead of "it does work" and "it does not work" please > describe what happens and what you expected to happen. > >Wietse > Well, today the milter checks are not happening, which is correct. It doesn't make any sense to me. My best guess is there was a typo somewhere, though I checked that and did not find one. I'm sorry for wasting your time, I thought I tried everything (twice) before posting. The ps/pgrep output is still perplexing. If I have just -o receive_override_options=no_milters the pgrep output is: 92212 smtpd -n 2525 -t inet -u -o stress= -o content_filter= -o receive_override_options=no_milters -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks= 127.0.0.0/8,xx.yy.zz.0/24 If I have -o receive_override_options=no_header_body_checks,no_milters pgrep output is: 91904 smtpd -n 2525 -t inet -u -o stress -o content_filter -o receive_override_options -o smtpd_sender_restrictions -o smtpd_recipient_restrictions -o mynetworks
Not Using reverse DNS
I am seeing the following in my logs: Apr 26 10:18:43 mailhost postfix/smtpd[46627]: connect from unknown[98.118.152.26] However, the IP does resolve: mailhost # host 98.118.152.26 26.152.118.98.in-addr.arpa domain name pointer onlinecourseevaluations.com. mailhost # host onlinecourseevaluations.com onlinecourseevaluations.com has address 98.118.152.28 onlinecourseevaluations.com mail is handled by 10 aspmx4.googlemail.com. onlinecourseevaluations.com mail is handled by 10 aspmx5.googlemail.com. onlinecourseevaluations.com mail is handled by 2 aspmx.l.google.com. onlinecourseevaluations.com mail is handled by 5 alt1.aspmx.l.google.com. onlinecourseevaluations.com mail is handled by 5 alt2.aspmx.l.google.com. onlinecourseevaluations.com mail is handled by 10 aspmx2.googlemail.com. onlinecourseevaluations.com mail is handled by 10 aspmx3.googlemail.com. Why isn't postfix using the hostname returned by the reverse DNS lookup? Is it because the forward and reverse DNS do not match? I thought I've seen cases where forward and reverse did not match but it still showed a hostname for the client. I've checked google and the mailing list archives, and none of the things I saw apply here. I am not in a chroot environment, and I am running a local caching DNS server. This is happening across a cluster of 5 servers, and the load is fine on all the servers. Other clients are resolving as expected. Thanks for your input, Dan
multiple IPs in and out
We host email for several domains. Occasionally an account will get phished and our outbound server will get blacklisted by hotmail and others. We'd like to separate the outbound email so that one domain with a phished account doesn't get all outbound email blacklisted. I'm trying to set up an outbound server with multiple IPs. I'd like email that arrives on an IP to leave on the same IP. In my master.cf I put: :smtp inet n - n - - smtpd -o myhostname=smtp1.host.dom :smtp inet n - n - - smtpd -o myhostname=smtp2.host.dom Email comes in on the different IPs, and the hostname is set to smtp1 or smtp2 in the Received headers. The email is all going out from the server's main IP not the separate IPs. I've tried adding "-o smtp_bind_address=" etc. I've tried setting up multiple smtp services and adding "-o default_transport=smtp1". Email is still going out on the server's main IP. I thought it would be easy to get email to go in and out on the same IP, but I cannot get it to work. What am I missing? Thanks, Dan
Unknown Recipient Domain
When a user mistypes an email address domain (eg @monsant.com), the message is sitting in the queue for days before they know about it. We'd like to give them immediate feedback instead of making them wail. I'm trying to have the outbound mail server permanently reject email with an invalid sender domain. I am using postfix 2.7-20100117 on FreeBSD 7.1 p10. I have: smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_mynetworks, reject_unauth_destination unknown_address_reject_code = 550 This works if the domain exists but the hostname does not, for example email to nob...@asdf.gmail.com: Jan 29 11:49:27 outbound postfix/smtpd[65568]: NOQUEUE: reject: RCPT from hostname[12.34.56.78]: 550 5.1.2 : Recipient address rejected: Domain not found; from= to= proto=ESMTP helo= If the domain does not exist, it is giving a 450. Here is the log for an email to monsant.com: Jan 29 11:48:23 outbound postfix/smtpd[65568]: NOQUEUE: reject: RCPT from hostname[12.34.56.78]: 450 4.1.2 : Recipient address rejected: Domain not found; from= to= proto=ESMTP helo= How can I make postfix issue a 550 error when the domain does not exist? Thanks, Dan
Re: Unknown Recipient Domain
On Fri, Jan 29, 2010 at 12:22 PM, Noel Jones wrote: > On 1/29/2010 11:57 AM, Dan Lists wrote: >> >> When a user mistypes an email address domain (eg @monsant.com), the >> message is sitting in the queue for days before they know about it. >> We'd like to give them immediate feedback instead of making them wail. >> >> I'm trying to have the outbound mail server permanently reject email >> with an invalid sender domain. >> >> I am using postfix 2.7-20100117 on FreeBSD 7.1 p10. >> >> I have: >> >> smtpd_recipient_restrictions = >> reject_non_fqdn_recipient, >> reject_unknown_recipient_domain, >> permit_mynetworks, >> reject_unauth_destination >> unknown_address_reject_code = 550 >> >> This works if the domain exists but the hostname does not, for example >> email to nob...@asdf.gmail.com: >> >> Jan 29 11:49:27 outbound postfix/smtpd[65568]: NOQUEUE: reject: RCPT >> from hostname[12.34.56.78]: 550 5.1.2: >> Recipient address rejected: Domain not found; from= >> to= proto=ESMTP helo= >> >> If the domain does not exist, it is giving a 450. Here is the log for >> an email to monsant.com: >> >> Jan 29 11:48:23 outbound postfix/smtpd[65568]: NOQUEUE: reject: RCPT >> from hostname[12.34.56.78]: 450 4.1.2: Recipient >> address rejected: Domain not found; from= >> to= proto=ESMTP helo= >> >> How can I make postfix issue a 550 error when the domain does not exist? >> >> Thanks, >> >> Dan > > $ host monsant.com > Host monsant.com not found: 2(SERVFAIL) > > This is a temporary error. The name server for monsant.com could not be > contacted. You don't know if the domain exists or not. "whois" shows this > domain does exist, but the listed name servers return an error rather than > an authoritative NXDOMAIN. I am getting an NXDOMAIN: # host monsant.com Host monsant.com not found: 3(NXDOMAIN)
Re: Unknown Recipient Domain
On Fri, Jan 29, 2010 at 1:17 PM, Wietse Venema wrote: > Dan Lists: > [ Charset ISO-8859-1 unsupported, converting... ] >> > $ host monsant.com >> > Host monsant.com not found: 2(SERVFAIL) >> > >> > This is a temporary error. The name server for monsant.com could not be >> > contacted. ?You don't know if the domain exists or not. ?"whois" shows this >> > domain does exist, but the listed name servers return an error rather than >> > an authoritative NXDOMAIN. >> >> I am getting an NXDOMAIN: >> >> # host monsant.com >> Host monsant.com not found: 3(NXDOMAIN) > > For me, all three name servers for monsant.com fail to respond. > That's ns1.monsanto.com, ns3.monsanto.com, and ns4.monsanto.com. > > Wietse > Is there a way to change how long postfix waits before the first warning email is sent back to the sender?
postscreen scalability
How much traffic can postscreen handle? Each mail server in our cluster handles 800,000 to 1,000,000 messages per day. We typically have 60-120 smptd processes, with peaks as high as 320. Adding a greeting delay will result in a lot of open connections. Can postscreen handle this volume even with the postscreen_greet_wait value of 6 seconds? Would I need to use drop instead of enforce on my actions? Thanks, Dan
Re: postscreen scalability
On Thu, Mar 8, 2012 at 4:06 PM, Wietse Venema wrote: > Dan Lists: >> How much traffic can postscreen handle? Each mail server in our >> cluster handles 800,000 to 1,000,000 messages per day. We typically > > This is mainly limited by the whitelist database latency: the > time needed to decide that a client is OK, and to hand off the > connection to a real SMTP server process. > > In your example, postscreen would have to be able to do 10 lookups > a second, but we all know that mail is not spread out evenly over > a day, so 100 lookups/second would be more appropriate. > > If the number of distinct clients is not overwhelmingly large, > putting a memcache between postscreen and the persistent whitelist > database will help to reduce whitelist lookup latency. I assume you are referring to the temporary whitelist. I do not see any way to configure what is uses to store the temporary whitelist. Is it configurable? Is there any way to share the temp whitelist between multiple servers? >> have 60-120 smptd processes, with peaks as high as 320. Adding a >> greeting delay will result in a lot of open connections. Can >> postscreen handle this volume even with the postscreen_greet_wait >> value of 6 seconds? Would I need to use drop instead of enforce on my >> actions? > > postscreen does not wait 6 seconds on all connections; that > would be a terrible mistake. Every connection not in the whitelist or a blacklist sees the delay, correct? We get connections from around 250,000 different IPs per day, most of which are blacklisted. Thanks! Dan
Re: postscreen scalability
On Wed, Mar 14, 2012 at 2:09 PM, Wietse Venema wrote: >> I assume you are referring to the temporary whitelist. I do not see >> any way to configure what is uses to store the temporary whitelist. >> Is it configurable? Is there any way to share the temp whitelist >> between multiple servers? > > See: http://www.postfix.org/POSTSCREEN_README.html#temp_white > and text linked from there. Thanks. I searched the postscreen manual page for whitelist and didn't find that info. Would it be possible to use a mysql map instead of a btree? Or is that going to be too complicated? Thanks, Dan
postscreen dnsbl reply text
I am looking to switch one or more of my blacklists to run from postscreen. I send custom replies based on the blacklist, which reduces the number of calls I get. The relevant part of my current configs: smtpd_client_restrictions = reject_rbl_client zen.local, reject_rbl_client b.barracudacentral.org rbl_reply_maps = hash:$config_directory/rbl_reply_maps $config_directory/rbl_reply_maps: # Spamhaus rbls (all in one) zen.local $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked because it has been blacklisted. : To be removed from this blacklist please visit: http://www.spamhaus.org/query/bl?ip=$rbl_what # Barracuda Central Reputation System b.barracudacentral.org $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked because it has been blacklisted. : To be removed from this blacklist please visit: http://www.barracudacentral.org/rbl/removal-request/$rbl_what I do not see any way to set the response text when using postscreen. I see postscreen_dnsbl_reply_map, but it looks like that just changes the domain (ie zen.local to zen.spamhaus.org) not the reply text. Is there any way to set the postscreen DNSBL reply message? Thanks, Dan
user lookup error
I recently upgraded our mail servers from FreeBSD 7.3 running postfix 2.8.7 to FreeBSD 8.3 running postfix 2.9.3. We have account information stored in mysql and are using libnns-mysql to access the information through the normal password routines. After the upgrade, when a user does not exist I get an error looking up the passwd info: Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up passwd info for user: Invalid argument Nov 30 10:39:59 server postfix/local[50947]: 6F8985082A: to=, orig_to=, relay=local, delay=163222, delays=163222/0/0/0.04, dsn=4.0.0, status=deferred (user lookup error) Because it is a temporary error, it keeps trying over and over. In the case of aliases, the valid recipients get a copy each time it retries. Delivery to users that exist works fine. IMAP and POP work fine. All other system functions work fine. We've been using the libnss-mysql module for a very long time, over 5 years, and we've never had a problem before. Does anyone have suggestions on how to debug this? Thanks, Dan
Re: user lookup error
On Fri, Nov 30, 2012 at 1:49 PM, Wietse Venema wrote: > Dan Lists: >> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up >> passwd info for user: Invalid argument > > The getpwnam_r() SYSTEM LIBRARY ROUTINE reports an error, > with errno set to EINVAL (Invalid argument). > > Find out why the SYSTEM LIBRARY ROUTINE reports this error. > If the user name is longer that 16 chars and the user does not exist, getpwnam_r() returns EINVAL. If the user exists, it works fine regardless of the length. I saw a report of this same behavior with dovecot. There is a patch to dovecot to fix it. Does postfix need to treat the EINVAL as if the user does not exist? Is there a way to change the behavior of getpwnam*? Dan
Re: user lookup error
On Mon, Dec 3, 2012 at 5:14 PM, Wietse Venema wrote: > Dan Lists: > [ Charset ISO-8859-1 unsupported, converting... ] >> On Fri, Nov 30, 2012 at 1:49 PM, Wietse Venema wrote: >> > Dan Lists: >> >> Nov 30 10:39:59 server postfix/local[50947]: warning: error looking up >> >> passwd info for user: Invalid argument >> > >> > The getpwnam_r() SYSTEM LIBRARY ROUTINE reports an error, >> > with errno set to EINVAL (Invalid argument). >> > >> > Find out why the SYSTEM LIBRARY ROUTINE reports this error. >> > >> >> If the user name is longer that 16 chars and the user does not exist, >> getpwnam_r() returns EINVAL. If the user exists, it works fine >> regardless of the length. I saw a report of this same behavior with >> dovecot. There is a patch to dovecot to fix it. > > Why not submit a fix to have getpwnam_r fixed instead? If a system > library function returns an undefined error code, then that is a BUG. > >> Does postfix need to treat the EINVAL as if the user does not exist? >> Is there a way to change the behavior of getpwnam*? > > EINVAL is not a documented result code. > http://pubs.opengroup.org/onlinepubs/009695399/functions/getpwnam.html > > Postfix is built accoirding to standards, not by tinkering with > library calls and guessing what the result means. > > Wietse I just ran my test program on FreeBSD 7.3, and it has the same result as on FreeBSD 8.3: Looking up: doesnotexist Returned no result! Looking up: doesnotexisty Return code: 22 It was working on FreeBSD 7.3 with postfix 2.8.7, and it is not working on FreeBSD 8.3 with postfix 2.9.3. Since the behavior of getpwnam_r is the same between the OS versions, it seems likely that some change between postfix 2.8.7 and 2.9.3 is causing postfix to react differently to getpwnam_r returning EINVAL. I downgraded postfix from 2.9.3 to 2.8.11 on the FreeBSD 8.3 box and everything works as expected.
Re: user lookup error
On Mon, Dec 3, 2012 at 7:42 PM, Wietse Venema wrote: > Dan Lists: >> >> Does postfix need to treat the EINVAL as if the user does not exist? >> >> Is there a way to change the behavior of getpwnam*? >> > >> > EINVAL is not a documented result code. >> > http://pubs.opengroup.org/onlinepubs/009695399/functions/getpwnam.html >> > >> > Postfix is built accoirding to standards, not by tinkering with >> > library calls and guessing what the result means. >> >> I just ran my test program on FreeBSD 7.3, and it has the same result >> as on FreeBSD 8.3: > > If an errno value is not defined in any standard API documentation, > why would one one errno value mean that a user does not exist, while > some other errno value means that the library function was unable > to complete a request? Postfix is written according to standard > APIs not by randomly experimenting with function calls and guessing > what the result means. > > You mention FreeBSD. They don't even bother to document EINVAL as > a "user does not exist" result. I looked at the Linux manpage and > it is clear that they tried harder to document getpwnam_r(), but > they also gave up. This function's API is a stinking mess. > >> I downgraded postfix from 2.9.3 to 2.8.11 on the FreeBSD 8.3 box and >> everything works as expected. > > Postfix avoids using using getpwnam() because it is fundamentally > broken on lots of systems (reporting "user does not exist" after > failure to complete the request). > > You can force Postfix to use getpwnam() if you know that you > will never use *SQL or LDAP etc. datbases: > > $ make makefiles CCARGS=-DNO_POSIX_GETPW_R > $ make We are using mysql databases. > Alternatively, I can try to implement a configurable getpwnam_r() > errno whitelist. This way I am off the hook, and you jump the > hoops if you like. Taking a quick look at the source, it looks like 2.8 does not use the thread-safe getpwnam_r. It does not appear that postfix is threaded, so it should be safe to not use getpwnam_r. On FreeBSD it looks like errno can be EINVAL, ERANGE, or inherited from open(2), dbopen(3), socket(2), or connect(2). EINVAL appears to be the only one that is returned when when it should be an invalid user. The rest probably should be treated as temporary errors.
Re: user lookup error
On Tue, Dec 4, 2012 at 5:48 AM, Wietse Venema wrote:
>> Taking a quick look at the source, it looks like 2.8 does not use the
>> thread-safe getpwnam_r. It does not appear that postfix is threaded,
>> so it should be safe to not use getpwnam_r.
>
> It has NOTHING TO TO WITH THREADS.
>
> Postfix avoids using using getpwnam() because it is fundamentally
> broken on lots of systems (reporting "user does not exist" after
> failure to complete the request).
>
> Sheesh.
"The functions getpwent_r(), getpwnam_r(), and getpwuid_r() are
thread-safe versions of getpwent(), getpwnam(), and getpwuid(),
respectively."
getpnam() returns NULL if the entry is not found or if an error
occurs. If an error does occur, errno will be set. It works like that
on Linux, FreeBSD, and Solaris.
err=getpwnam_r(name, pwd, buffer, bufsize, &result);
if( err ){
printf("Error is %d\n", err);
}
is the same as
result=getpwnam(name);
if( !result && errno ){
printf("Error is %d\n", errno);
}
For this particular problem, err or errno would be EINVAL. So using
getpwnam_r or using getwpnam and checking errno would both result in
this problem. I think the best thing would be to ignore EINVAL, at
least on FreeBSD. Perhaps something like:
err = getpwnam_r(name, &pwbuf, pwstore, sizeof(pwstore), &pwd);
#if defined(__FreeBSD__)
if( err == EINVAL )
err=0;
#endif
if (err != 0)
...
Re: user lookup error
On Wed, Dec 5, 2012 at 11:55 AM, Wietse Venema wrote: > > I will not base Postfix development on UNDOCUMENTED return values. > That is unmaintainable. I've brought it up on the FreeBSD lists. I suggested that it is a bug for getpwnam_r to act the way it is. I'll probably end up submitting a bug report. I think getpwnam_r should act differently. If not, it should be documented. > I can offer to provide a config option with an errno whitelist for > getpwxx_r errno values, so that you can deal with the mess. > That would certainly work. Thanks.
Holding Email from Specific Sender
We relay email for our customers. They had some accounts Phished. I wanted to hold email from those users so I could see the spam that was going out and requeue the valid email. In main.cf I have: smtpd_sender_restrictions = check_sender_access hash:$config_directory/sender_domains, reject sender_domains has: u...@domain.tld HOLD domain.tld OK What u...@domain.tld sends email I get: Dec 6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: hold: RCPT from clientserv[12.34.56.78]: : Sender address triggers HOLD action; from= to= proto=ESMTP helo= Dec 6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: reject: RCPT from clientserv[12.34.56.78]: 554 5.7.1 : Sender address rejected: Access denied; from= to= proto=ESMTP helo= What am I doing wrong? Thanks, Dan
Re: Holding Email from Specific Sender
On Thu, Dec 6, 2012 at 5:09 PM, Noel Jones wrote: > On 12/6/2012 4:29 PM, Dan Lists wrote: >> We relay email for our customers. They had some accounts Phished. I >> wanted to hold email from those users so I could see the spam that was >> going out and requeue the valid email. >> >> In main.cf I have: >> >> smtpd_sender_restrictions = >> check_sender_access hash:$config_directory/sender_domains, >> reject >> >> sender_domains has: >> >> u...@domain.tld HOLD >> domain.tld OK >> >> What u...@domain.tld sends email I get: >> >> Dec 6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: hold: RCPT >> from clientserv[12.34.56.78]: : Sender address >> triggers HOLD action; from= to= >> proto=ESMTP helo= >> Dec 6 16:14:26 mailserver postfix/smtpd[47661]: NOQUEUE: reject: RCPT >> from clientserv[12.34.56.78]: 554 5.7.1 : Sender >> address rejected: Access denied; from= >> to= proto=ESMTP helo= >> >> What am I doing wrong? > > Just a misconception... HOLD does not immediately freeze the > message, nor does it instruct postfix to accept the message. > Processing continues and a later restriction can still reject the > message. Interesting. It worked when I did something similar in smtpd_client_restrictions. smtpd_client_restrictions = check_client_access hash:$config_directory/client_access client_access: 12.34.56.78 HOLD Is that because the smtpd_client_restrictions does not have reject listed? > Probably the easiest solution here it to create your own HOLD_OK > action so it works as you expect. > > # main.cf > smtpd_restriction_classes = > HOLD_OK > > HOLD_OK = > reject_unauth_destination > check_client_access static:hold > permit We are relaying for them, so I assume I would want to leave out reject_unauth_destinaion. > > Then, in your sender_domain file, > u...@domain.tld HOLD_OK > domain.tld OK > > > -- Noel Jones
Error: queue file write error
I am receiving the transcript file with the error "Error: queue file write error." It appears that postfix is timing out the connection after 10 minutes. The thing that disturbs me is that nothing is logged. Is there a way to get postfix to put something in the logs? Here is the transcript: Transcript of session follows. Out: 220 myserver.net ESMTP Postfix In: EHLO avas10tiga.indosat.net.id Out: 250-myserver.net Out: 250-PIPELINING Out: 250-SIZE 104857600 Out: 250-ETRN Out: 250-ENHANCEDSTATUSCODES Out: 250-8BITMIME Out: 250 DSN In: MAIL FROM:<2...@heathfield.co.nz> SIZE=2873224 Out: 250 2.1.0 Ok In: RCPT TO: Out: 250 2.1.5 Ok In: DATA Out: 354 End data with . Out: 451 4.3.0 Error: queue file write error In: QUIT Out: 221 2.0.0 Bye And here are the log entries: Oct 10 09:13:26 myserver postfix/smtpd[18826]: connect from avas10tiga.indosat.net.id[219.83.54.103] Oct 10 09:13:34 myserver policyd: rcpt=18817141, greylist=update, host=219.83.54.103 (avas10tiga.indosat.net.id), from=2...@heathfield.co.nz, to=u...@myserver.net, size=2873224 Oct 10 09:13:34 myserver postfix/smtpd[18826]: 89C476DF8C3: client= avas10tiga.indosat.net.id[219.83.54.103] Oct 10 09:13:37 myserver postfix/cleanup[18080]: 89C476DF8C3: message-id=<32609497.108184811317.JavaMail.defaultUser@defaultHost> Oct 10 09:13:37 myserver postfix/cleanup[18080]: 89C476DF8C3: warning: header Subject: CONFIDENTAIL: CLAIM YOUR PRIZE from avas10tiga.indosat.net.id[219.83.54.103]; from=<2...@heathfield.co.nz> to=< u...@myserver.net> proto=ESMTP helo= Oct 10 09:23:10 myserver postfix/smtpd[18826]: disconnect from avas10tiga.indosat.net.id[219.83.54.103] Thanks!
Re: Error: queue file write error
On Sat, Oct 10, 2015 at 11:30 AM, Viktor Dukhovni < postfix-us...@dukhovni.org> wrote: > On Sat, Oct 10, 2015 at 10:53:12AM -0500, Dan Lists wrote: > > > Out: 451 4.3.0 Error: queue file write error > > > > And here are the log entries: > > > > Oct 10 09:13:26 myserver postfix/smtpd[18826]: connect from > > avas10tiga.indosat.net.id[219.83.54.103] > > Oct 10 09:13:34 myserver policyd: rcpt=18817141, greylist=update, > > host=219.83.54.103 (avas10tiga.indosat.net.id), from= > 2...@heathfield.co.nz, > > to=u...@myserver.net, size=2873224 > > Oct 10 09:13:34 myserver postfix/smtpd[18826]: 89C476DF8C3: client= > > avas10tiga.indosat.net.id[219.83.54.103] > > Oct 10 09:13:37 myserver postfix/cleanup[18080]: 89C476DF8C3: > > message-id=<32609497.108184811317.JavaMail.defaultUser@defaultHost> > > Oct 10 09:13:37 myserver postfix/cleanup[18080]: 89C476DF8C3: warning: > > header Subject: CONFIDENTAIL: CLAIM YOUR PRIZE from > > avas10tiga.indosat.net.id[219.83.54.103]; from=<2...@heathfield.co.nz> > to=< > > u...@myserver.net> proto=ESMTP helo= > > Oct 10 09:23:10 myserver postfix/smtpd[18826]: disconnect from > > avas10tiga.indosat.net.id[219.83.54.103] > > Sorry that can't be all that's in the logs, look at your syslog > configuration and check any additional log files. > > -- > Viktor. > I did eventually manage to find something in the logs: Oct 10 09:13:39 nook postfix/cleanup[18080]: fatal: pcre map /usr/local/etc/postfix/body_checks, line 17: matched text exceeds buffer limit We handle around 1 million messages per day, so it can be hard to find an entry that is not associated with the client IP, queue id, message id, sender, or recipient. Why didn't smtpd log the 451 error? This is the first time I have ever seen smtpd not log the final outcome. Is there a way to increase the buffer limit? Is there a way to get postfix to reject these in a way that generates a log entry associated with the queue id? Thanks, Dan
Re: Error: queue file write error
On Sat, Oct 10, 2015 at 2:23 PM, Wietse Venema wrote: > Dan Lists: > > > > Out: 451 4.3.0 Error: queue file write error > > Oct 10 09:13:39 nook postfix/cleanup[18080]: fatal: pcre map > > /usr/local/etc/postfix/body_checks, line 17: matched text exceeds buffer > > limit > > Yes, in case of trouble, look for panic or fatal messages first. > Especially when the SMTP transcript tells you to look in the log > for details. > > The PCRE client does not know the queue ID, and the SMTP daemon > does not know that the PCRE client aborted (nor does the SMTP daemon > know why). This will not change. Logging the full execution context > for every possible error comes with a significant cost. > cleanup knows the queue id, it logged: Oct 10 09:13:37 myserver postfix/cleanup[18080]: 89C476DF8C3: warning: header Subject: CONFIDENTAIL: CLAIM YOUR PRIZE from avas10tiga.indosat.net.id[219.83.54.103]; from=<2...@heathfield.co.nz> to=< u...@myserver.net> proto=ESMTP helo= Couldn't the cleanup fatal log entry be changed to add the queue id? So like this: Oct 10 09:13:39 myserver postfix/cleanup[18080]: 89C476DF8C3: fatal: pcre map /usr/local/etc/postfix/body_checks, line 17: matched text exceeds buffer limit > Why didn't smtpd log the 451 error? This is the first time I have ever > > seen smtpd not log the final outcome. > > Postfix will not log all [45]xx replies. That would make it way > too easy to flood the file system. However, every panic or fatal > error should be investigated whether it happened during an SMTP > session or otherwise. > > Is there a way to increase the buffer limit? > > Maybe this helps: > > https://groups.google.com/forum/#!topic/mailing.postfix.users/14GV4g4kNyk > My expression does not have any .* in it. Here it is: %https?://[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*/public/% REJECT I would like to reject this message so they stop trying to send it. I could modify the expression but then it wold not match and the message would not be rejected. What is the buffer size for pcre? The machine has a lot of resources, can I bump the limit? Wietse >
