Re: 451 4.3.0 Error: queue file write error
On Sun, 24 Jan 2010, Shawn Fee wrote: Is there a fix for the 451 4.3.0 Error: queue file write error yet? I heard to increase the smtp_proxy_timeout = 600s in the main.cf file, but then I heard that can run down your server. The 451 sent from your server to SMTP clients is purposely vague to protect your internal configuration details from public exposure. See the log on the server in question for more useful debugging. If you need more help, please clearly explain the problem after reviewing DEBUG_README. Is there any patches or hot fixes that actually work? I have Postfix 9.3.0 and the 451 error is still not fixed. Postfix 9.3.0 does not exist; what version are you actually using? -- Sahil Tandon sa...@tandon.net
Re: Putting $data_directory on a RAM filesystem
* Victor Duchovni victor.ducho...@morganstanley.com: On Sat, Jan 23, 2010 at 06:08:40PM +0100, Stefan Foerster wrote: In case of severe server overload, with postscreen(8) complaining about lookup and update times around 400ms almost every mail, is it (reasonably) safe as a last desperate measure to put $data_directory, or at least the file referenced by $postscreen_cache_map, on a ramdisk (e.g. tmpfs with Linux)? Yes, but I would still try to find out why the lookup times are so absurdly large? An exotic bug in the raid controller's firmware of the three servers slowed down access to certain parts of the raid array to the speed of molasses. It affected /var (and /boot), but not the LV which held $queue_directory. On the fourth, identical server, a slightly different disk layout was used for all testing and benchmarking. After verifying that the unattended installation worked, the three other servers were deployed into production with a larger LV for /usr. Upgrading the faulty firmware solved the problem. N.B: If you bother with testing at all, do it right. Stefan
greylisting question
I have noticed (at times) that sometimes email gets greylisted when the user doesn't exist in my system. The mail ultimately get's rejected, but I cant figure out why it's greylisting when it's invalid to begin with? Greylisting, to me..should be the last resort.. I have this way up near the top of main.cf: # REJECTING MAIL FOR UNKNOWN LOCAL USERS local_recipient_maps = proxy:unix:passwd.byname $alias_maps # ADDRESS REWRITING alias_maps = $default_database_type:/etc/postfix/aliases alias_database = $default_database_type:/etc/postfix/aliases and then the typical stuff: smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_client, reject_unauth_pipelining, check_policy_serviceinet:127.0.0.1:10023 -- J.D. Bronson Information Technology Aurora Health Care - Milwaukee WI Office: 414.978.8282 // Fax: 414.978.3988
Re: greylisting question
On Sun, 24 Jan 2010 14:00:21 +0100, J.D. Bronson jd_bron...@sbcglobal.net wrote: I have noticed (at times) that sometimes email gets greylisted when the user doesn't exist in my system. The mail ultimately get's rejected, but I cant figure out why it's greylisting when it's invalid to begin with? Greylisting, to me..should be the last resort.. I have this way up near the top of main.cf: # REJECTING MAIL FOR UNKNOWN LOCAL USERS local_recipient_maps = proxy:unix:passwd.byname $alias_maps # ADDRESS REWRITING alias_maps = $default_database_type:/etc/postfix/aliases alias_database = $default_database_type:/etc/postfix/aliases and then the typical stuff: smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_client, reject_unauth_pipelining, check_policy_serviceinet:127.0.0.1:10023 You need to tell Postfix when to lookup the recipient address or else that will happen after all the other checks, i.e. after a client has passed greylisting. Just add the reject_unlisted_recipient check somewhere before your greylisting service. http://www.postfix.org/postconf.5.html#reject_unlisted_recipient
Re: greylisting question
On 1/24/10 8:09 AM, Martin Strand wrote: On Sun, 24 Jan 2010 14:00:21 +0100, J.D. Bronson jd_bron...@sbcglobal.net wrote: I have noticed (at times) that sometimes email gets greylisted when the user doesn't exist in my system. The mail ultimately get's rejected, but I cant figure out why it's greylisting when it's invalid to begin with? Greylisting, to me..should be the last resort.. I have this way up near the top of main.cf: # REJECTING MAIL FOR UNKNOWN LOCAL USERS local_recipient_maps = proxy:unix:passwd.byname $alias_maps # ADDRESS REWRITING alias_maps = $default_database_type:/etc/postfix/aliases alias_database = $default_database_type:/etc/postfix/aliases and then the typical stuff: smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_unknown_client, reject_unauth_pipelining, check_policy_service inet:127.0.0.1:10023 You need to tell Postfix when to lookup the recipient address or else that will happen after all the other checks, i.e. after a client has passed greylisting. Just add the reject_unlisted_recipient check somewhere before your greylisting service. http://www.postfix.org/postconf.5.html#reject_unlisted_recipient . Bingo...that was it. Much thanks! -- J.D. Bronson Information Technology Aurora Health Care - Milwaukee WI Office: 414.978.8282 // Fax: 414.978.3988
Re: 451 4.3.0 Error: queue file write error
Shawn Fee: Is there a fix for the 451 4.3.0 Error: queue file write error yet? I heard to increase the smtp_proxy_timeout = 600s in the main.cf file, but then I heard that can run down your server. You have a configuration error, and you need to look in the Postfix mail logfile for details. Postfix will not reveal these details in its reponses to SMTP clients. Wietse
smtpd skips command line parameters from master.cf?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I can't figure out why but to me it looks like smtpd instances started from master.cf don't pick up all the parameter assignments. I have an smtpd transport defined as: 10.121.8.1:smtp inet n - n - - smtpd -o local_transport=vpn-procmail -o local_recipient_maps= -o inet_interfaces=10.121.8.1 -o content_filter= -o smtpd_proxy_filter= -o mynetworks=10.121.8.0/24 -o mydestination=vpn.3d.hu -o relaydomains= -o virtual_alias_domains= -o virtual_alias_maps= -o smtpd_sender_restrictions=reject_non_fqdn_sender,permit -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_reject_unlisted_sender=no -o smtpd_sasl_auth_enable=no -o smtpd_sasl_security_options= But if I try to send a mail through this smtpd instance, in the logs I see: Jan 24 19:54:52 morpheus postfix/smtp[19916]: 79C3C14105: to=u...@vpn.3d.hu, relay=none, delay=14, delays=14/0.04/0.03/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=vpn.3d.hu type=A: Host found but no data record of requested type) I can't understand why it says relay=none, it should be relay=vpn-procmail... I think so since the recipient address is u...@vpn.3d.hu that matches $mydestination, so it falls into the local address class, and the transport for that is redefined to vpn-procmail. If I put vpn.3d.hu at the end of mydestination= option in main.cf, the same mail sent to the same smtpd instance is treated as a local address class as it should. Am I doing something wrong or is this a possible bug? Thanks, - -- cc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktcnoQACgkQGJRwVVqzMkONRgCgm5nvfF9ve1fhIR++An75MxCK 9yAAnj/Hm0C1pxF34jNe7/HkLMFfkanD =VMU2 -END PGP SIGNATURE-
Re: smtpd skips command line parameters from master.cf?
* SZÉKELYI Szabolcs c...@mail.3d.hu: Hi, I can't figure out why but to me it looks like smtpd instances started from master.cf don't pick up all the parameter assignments. I have an smtpd transport defined as: 10.121.8.1:smtp inet n - n - - smtpd -o local_transport=vpn-procmail smtpd knows no local_transport see man smtpd -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
RE: 451 4.3.0 Error: queue file write error
Sorry I meant Plesk 9.3.0. And the problem was suppose to be fixed in this realease. Shawn Fee SGF IT Solutions, LLC | IT Manager 813.817.8706 s...@sgfitsolutions.com -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sahil Tandon Sent: Sunday, January 24, 2010 3:57 AM To: postfix-users@postfix.org Subject: Re: 451 4.3.0 Error: queue file write error On Sun, 24 Jan 2010, Shawn Fee wrote: Is there a fix for the 451 4.3.0 Error: queue file write error yet? I heard to increase the smtp_proxy_timeout = 600s in the main.cf file, but then I heard that can run down your server. The 451 sent from your server to SMTP clients is purposely vague to protect your internal configuration details from public exposure. See the log on the server in question for more useful debugging. If you need more help, please clearly explain the problem after reviewing DEBUG_README. Is there any patches or hot fixes that actually work? I have Postfix 9.3.0 and the 451 error is still not fixed. Postfix 9.3.0 does not exist; what version are you actually using? -- Sahil Tandon sa...@tandon.net
Re: 451 4.3.0 Error: queue file write error
Shawn Fee: Sorry I meant Plesk 9.3.0. And the problem was suppose to be fixed in this realease. What is the Postfix logfile warning message? Wietse
Maildir problem
Hi My maildir is /mail/netnet.hu/username I was configure dovecot for this using text user database in /mail/netnet.hu/user.txt currently gy...@netnet.hu is an existing adress at /mail/netnet.hu/gyuri. Content is: cur dovecot.index dovecot.index.cache dovecot.index.log new tmp I can't configure postfix to delivery mail to this folder. Can see my config at http://www.netnet.hu/main.cf Thanks for help!
RE: 451 4.3.0 Error: queue file write error
What is the command to check that..I've never checked the Postfix log file. It would be extremely helpful to know. I know how to SSH into my server just don't know all the commands. Shawn Fee SGF IT Solutions, LLC | IT Manager 813.817.8706 s...@sgfitsolutions.com -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Wietse Venema Sent: Sunday, January 24, 2010 5:28 PM To: Postfix users Subject: Re: 451 4.3.0 Error: queue file write error Shawn Fee: Sorry I meant Plesk 9.3.0. And the problem was suppose to be fixed in this realease. What is the Postfix logfile warning message? Wietse
Re: 451 4.3.0 Error: queue file write error
On 1/24/10 4:35 PM, Shawn Fee at s...@sgfitsolutions.com wrote: Wietse said: What is the Postfix logfile warning message? What is the command to check that..I've never checked the Postfix log file. It would be extremely helpful to know. I know how to SSH into my server just don't know all the commands. Please don't top post here. Find the log file (location is implementation specific - mine is /var/log/mail.log). Inspect with your favorite method (vi, emacs, more, etc. - you may want to make a copy to avoid any issues with new stuff being written to it). Find the relevant section and extract. -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/
Re: 451 4.3.0 Error: queue file write error
Shawn Fee: What is the command to check that..I've never checked the Postfix log file. It would be extremely helpful to know. I know how to SSH into my server just don't know all the commands. You can find suggestions for logfile trouble shooting in http://www.postfix.org/DEBUG_README.html#logging The logfile name is system dependent. On typical linux/bsd/solaris systems, the pathnames are specified in /etc/syslog.conf. Once we have a Postfix warning message there may be a possible workaround. Wietse
Maildir problem2
log file contains: Jan 24 23:46:25 www postfix/smtpd[28521]: connect from unknown[192.168.4.9] Jan 24 23:46:25 www postfix/smtpd[28521]: 8CC4B7C703B: client=unknown[192.168.4.9] Jan 24 23:46:25 www postfix/cleanup[28533]: 8CC4B7C703B: message-id=5b3d1a99b19240b4966c10ce3f613...@gyuri Jan 24 23:46:25 www postfix/qmgr[28047]: 8CC4B7C703B: from=i...@netnet.hu, size=1379, nrcpt=1 (queue active) Jan 24 23:46:25 www postfix/smtpd[28521]: disconnect from unknown[192.168.4.9] Jan 24 23:46:25 www postfix/local[28534]: 8CC4B7C703B: to=gy...@netnet.hu, relay=local, delay=0.1, delays=0.08/0.02/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Jan 24 23:46:25 www postfix/qmgr[28047]: 8CC4B7C703B: removed
Re: Maildir problem2
Please don't hijack threads. If you want to start a new topic: write a new mail. If you want to add information to your topic: reply to your original mail, instead of replying *again* to some unrelated thread. On 2010-01-24 netnet.hu - HelpDesk wrote: log file contains: Jan 24 23:46:25 www postfix/smtpd[28521]: connect from unknown[192.168.4.9] Jan 24 23:46:25 www postfix/smtpd[28521]: 8CC4B7C703B: client=unknown[192.168.4.9] Jan 24 23:46:25 www postfix/cleanup[28533]: 8CC4B7C703B: message-id=5b3d1a99b19240b4966c10ce3f613...@gyuri Jan 24 23:46:25 www postfix/qmgr[28047]: 8CC4B7C703B: from=i...@netnet.hu, size=1379, nrcpt=1 (queue active) Jan 24 23:46:25 www postfix/smtpd[28521]: disconnect from unknown[192.168.4.9] Jan 24 23:46:25 www postfix/local[28534]: 8CC4B7C703B: to=gy...@netnet.hu, relay=local, delay=0.1, delays=0.08/0.02/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Jan 24 23:46:25 www postfix/qmgr[28047]: 8CC4B7C703B: removed Well, according to your logfile the mail is delivered to the mailbox. Either you misconfigured the destination of that delivery or this is a Dovecot issue. The latter would be off-topic on this list. Please post the output of postconf -n. I doubt that anyone will read through your heavily commented main.cf to find out what your actual configuration is. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Maildir problem2
Ansgar Wiechers wrote: Well, according to your logfile the mail is delivered to the mailbox. Either you misconfigured the destination of that delivery As a first guess, that is the case. The config file contains home_mailbox = Mailbox while the OP's file structure does look like a Maildir/ . It furthermore seems to me the OP has mixed up the spool and home directory configuration, but I'm not familiar with virtual domain setup (if applicable here?). postconf -n will surely be of help; if there is no virtual domain setup involved, I'd suggest to check the home directory settings for the users mentioned. Does the dovecot setup already work? If yes, it might also be helpful to include that configuration to see what dovecot expects. -hannes
DNS round robin does not give fair load balancing
I try load balancing using a relayhost to a DNS A record with multiple IP's But I find that somehosts *always* get more mails than others Doesnt help if I use MX records instead of A records How do I do fair loadbalancing with postfix Thanks Ram