Re: Code burn-in: postscreen/verify cache cleanup
* Wietse Venema wie...@porcupine.org: I'm burning in some new code that I wrote over the past week to periodically remove old entries from postscreen(8) and verify(8) caches. This is not a sexy topic, but it helps to keep database sizes in check, it speeds up database access, and it was time. If you're courageous you can try postfix-2.7-20091227-nonprod. If I had some problems integrating the Debian patches which support dynamic loading of map types (worse, I don't even understand why), so I went for a traditional compile and install. It's working as expected, I didn't see any adverse side effects so far. OTOH, the servers where I deployed the code have almost no real workload at this time between the years, possibly rendering my observations flawed. What kind of data could we provide to help you with this? Stefan you have used postscreen(8) or verify(8) before, you will notice that they weed out lots and lots of expired entries from the databases while reporting their progress along the way. The cache cleaning code runs while a postscreen(8) or verify(8) process is waiting for real work. Cache cleaning suspends when the process does no real work for $max_idle seconds, and resumes when there is a request for postscreen(8) or verify(8) service. After a cache cleanup run is completed, no cleanup happens for 12 hours. Right now, cache cleaning cannot be disabled, so the postscreen(8) or verify(8) cache databases MUST support the delete and sequence operations. For backwards compatibility sake I may add a non-cleaning option but it won't be the default setting. Wietse
Re: In-queue rejections
Wietse Venema wrote: Daniel L. Miller: [ Charset ISO-8859-1 unsupported, converting... ] I don't know what the correct terminology is for my question - please adjust my wording as needed. When a user mistypes a remote e-mail address (not that THAT ever happens!), the result is typically either a user unknown, invalid recipient, or host or domain not found message. At least for MY Um, why is user unknown mail stuck in your queue? It should be returned as soon as Postfix finds out. It's quite possible I have something misconfigured...here's are some samples from my current mailq - 7A44F20CED3 4338053 Mon Dec 28 10:50:59 idiotu...@amfes.com (Host or domain name not found. Name service error for name=fireprotectionbymesa.com type=: Host not found) jeff...@fireprotectionbymesa.com 5F47320CEC2 4338844 Mon Dec 28 13:12:09 idiotu...@amfes.com (host mail.fireprobymesa.com[65.40.152.138] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) jeff...@fireprobymesa.com First he got the domain wrong - but he also got the username portion wrong as well. system, with MY configuration (however flawed it may be), this results in a couple messages floating in the send queue with these statuses. Periodically, I'll check for such items, notify my users of a problem, and delete them from the queue. I do have a bounce_template_file, and I've TRIED to make it a bit more informative - but my users still cross their eyes and call me and complain that OUR mail server is broken! Is there a more advanced option that can give individual messages instead of a generic bounce message? Something that might parse the rejection and give specific advice to the computer illiterate? This option is called transport(5) (and involves setting up specific rules for specific RECIPIENT addresses or domains). But I don't recommend that you do this. I believe I understand where you're headed with this - but it's NOT what I was asking! I DON'T want to manually maintain transport tables to handle user misspellings. Instead I was hoping the server could examine the error and automagically make a recommendation back to the authenticated local sender for a user correction. Something like...(pseudo code logic) if host not found, either remote server's DNS is wrong or user mistyped - recommend verifying domain name prior to re-sending. Also, is there any e-mail interface for canceling messages? So that if a slightly more competent user actually READS the bounce message, determines that they spelled it wrong - they can tell the mail server to cancel the send? Again, why is user unknown mail stuck in your queue anyway? It should be returned as soon as Postfix finds out. Wietse -- Daniel
Re: Get username of local user from recipient address
Dne 28.12.2009 v 17:49 Wietse Venema napsal(a): Michal Kurka: Because I have not got any answer, I tried trace an internal communication between postfix'es processes via UNIX-sockets. I discovered that trivial-rewrite only specifies transport or does a canonicalizing. Process verify right tell that recipient address is alias to a concrete username. If recipient is aliased to more users, all usernames is announced. Now I'm trying use verify for my business. If simply execute verify, it ends with error message in Log fatal: service verify requires a process limit of 1. Sorry, you are playing with Postfix-internal interfaces. Use of these by non-Postfix programs is UNSUPPORTED meaning that it can break even after minor Postfix release changes. I aware of this. But do I have any other option? Unfortunately I haven't got any suggestion from anybody :-( -- Michal Kurka - Mysak sluzby spojene s operacnim systemem Linux
Re: Get username of local user from recipient address
Hi, Michal Kurka: Because I have not got any answer, I tried trace an internal communication between postfix'es processes via UNIX-sockets. I discovered that trivial-rewrite only specifies transport or does a canonicalizing. Process verify right tell that recipient address is alias to a concrete username. If recipient is aliased to more users, all usernames is announced. Now I'm trying use verify for my business. If simply execute verify, it ends with error message in Log fatal: service verify requires a process limit of 1. Sorry, you are playing with Postfix-internal interfaces. Use of these by non-Postfix programs is UNSUPPORTED meaning that it can break even after minor Postfix release changes. I aware of this. But do I have any other option? Unfortunately I haven't got any suggestion from anybody :-( Can't you just use virtual alias maps based on an external service for this purpose? For example in case of mysql you can create a stored procedure that 'logs' when the resultset is empty HTH Regards, Serge Fonville -- http://www.sergefonville.nl Convince Google!! They need to support Adsense over SSL https://www.google.com/adsense/support/bin/answer.py?hl=enanswer=10528 http://www.google.com/support/forum/p/AdSense/thread?tid=1884bc9310d9f923hl=en
Re: Get username of local user from recipient address
Dne 29.12.2009 v 10:17 Serge Fonville napsal(a): Can't you just use virtual alias maps based on an external service for this purpose? For example in case of mysql you can create a stored procedure that 'logs' when the resultset is empty Yes, this is a good idea. But I need a solution independent on used address mapping system on specific server. I administrate many MTA-serveres and on some isn't posible use MySQL or other external service. -- Michal Kurka - Mysak sluzby spojene s operacnim systemem Linux
Re: In-queue rejections
Daniel L. Miller put forth on 12/29/2009 2:44 AM: I believe I understand where you're headed with this - but it's NOT what I was asking! Hi Daniel, Just a quick note. It's probably not a great idea to SHOUT! at Dr. Venema, the person to whom who were replying here, and who is trying to help you. Dr. Wietse Venema, Ph.D. Physics, Groningen University, is the creator/author of Postfix. He is currently employed at IBM's Thomas J. Watson Research Center and has been for over a decade. He runs this mailing list as a free courtesy to users of Postfix. He has no obligation to do so, as neither you nor I paid for Postfix or a support contract. Please keep this in mind, and the fact that when engaging Wieste regarding a Postfix issue, you are in essence speaking to God himself. If Wietse is making a suggestion to you, he likely already knows all the angles, and there is probably a darn good reason he is suggesting something to you. In the past, I have been guilty of allowing frustration to color my posts here, but, thankfully, never in a post directly to Wietse. :) Keep a cool head. We're all on the same team here trying to help each other fix each others' Postfix problems. Best regards, -- Stan
Re: In-queue rejections
Daniel, 5F47320CEC2 4338844 Mon Dec 28 13:12:09 idiotu...@amfes.com (host mail.fireprobymesa.com[65.40.152.138] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) jeff...@fireprobymesa.com Do you have soft_bounce=yes configured? (http://www.postfix.org/postconf.5.html#soft_bounce) That seems to be the reason why postfix isn't immediately bouncing the message to the sender. If you don't have a good reason to keep soft_bounce activated (and you shouldn't on a production machine), try if disabling solves your problem. -hannes
Re: In-queue rejections
On 2009-12-28 5:17 PM, Daniel L. Miller wrote: When a user mistypes a remote e-mail address (not that THAT ever happens!), the result is typically either a user unknown, invalid recipient, or host or domain not found message. At least for MY system, with MY configuration (however flawed it may be), this results in a couple messages floating in the send queue with these statuses. Periodically, I'll check for such items, notify my users of a problem, and delete them from the queue. Per the welcome message you received when you joined the list: TO REPORT A PROBLEM see: http://www.postfix.org/DEBUG_README.html#mail At a minimum, postfix version, output of postconf -n and unedited NON-verbose logs exhibiting the problem should be provided... This should provide an answer to Wietse's question as to why these are stuck in the queue when they should be returned immediately. Also, is there any e-mail interface for canceling messages? So that if a slightly more competent user actually READS the bounce message, determines that they spelled it wrong - they can tell the mail server to cancel the send? Fix the real problem (above) and this problem goes away... -- Best regards, Charles
Random Source Parameter Error
I'm trying to set up TLS on Postfix 2.5.5 and 'tlsmgr' keeps getting a fatal error on this statement: tls_random_source = dev:/dev/urandom It seems to work when I comment it out but I don't really understand what it does or if it is needed for TLS to work let alone what it should be to fix it. Can someone help me out? Thanks. Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
Re: Random Source Parameter Error
* Dennis Putnam dennis.put...@aimaudit.com: I'm trying to set up TLS on Postfix 2.5.5 and 'tlsmgr' keeps getting a fatal error on this statement: tls_random_source = dev:/dev/urandom Which error exactly? -- 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: Code burn-in: postscreen/verify cache cleanup
Stefan F?rster: * Wietse Venema wie...@porcupine.org: I'm burning in some new code that I wrote over the past week to periodically remove old entries from postscreen(8) and verify(8) caches. This is not a sexy topic, but it helps to keep database sizes in check, it speeds up database access, and it was time. If you're courageous you can try postfix-2.7-20091227-nonprod. If I had some problems integrating the Debian patches which support dynamic loading of map types (worse, I don't even understand why), so I went for a traditional compile and install. You may want to give a heads-up to the maintainer as I am just about to release this code as a regular experimental release. Cache cleanup will definitely be part of the Postfix 2.7 stable release, so they will have to deal with it in a month or so anyway. It's working as expected, I didn't see any adverse side effects so far. OTOH, the servers where I deployed the code have almost no real workload at this time between the years, possibly rendering my observations flawed. What kind of data could we provide to help you with this? I think the only stats of interest are the cache cleanup statistics which are logged twice a day by default. Mine have stabilized around the following numbers: Dec 29 04:20:17 spike postfix/postscreen[44900]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=134 dropped=19 entries Dec 29 06:19:33 spike postfix/verify[46072]: cache /var/lib/postfix/verify.db full cleanup: retained=1726 dropped=28 entries I had some fun when I ran it on a verify cache file that had accumulated about 300k entries. Cache cleanup took a couple minutes while at the same time responding to routine lookup/update requests. This is on an older machine. Wietse
Re: In-queue rejections
Daniel L. Miller: 5F47320CEC2 4338844 Mon Dec 28 13:12:09 idiotu...@amfes.com (host mail.fireprobymesa.com[65.40.152.138] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) jeff...@fireprobymesa.com That does not seem right. You have soft_bounce turned on in main.cf or master.cf. Wietse
Re: Code burn-in: postscreen/verify cache cleanup
* Wietse Venema wie...@porcupine.org: You may want to give a heads-up to the maintainer as I am just about to release this code as a regular experimental release. Cache cleanup will definitely be part of the Postfix 2.7 stable release, so they will have to deal with it in a month or so anyway. I'm running the unpatched version here; it seems to work Dec 29 04:20:17 spike postfix/postscreen[44900]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=134 dropped=19 entries Dec 29 06:19:33 spike postfix/verify[46072]: cache /var/lib/postfix/verify.db full cleanup: retained=1726 dropped=28 entries The initial cleanup: Dec 29 10:16:35 mail postfix/postscreen[12078]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=8460 dropped=274056 entries Dec 29 10:17:13 mail postfix/verify[12105]: cache /var/lib/postfix/verify.db full cleanup: retained=109892 dropped=648105 entries -- 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: In-queue rejections
On Dec 29, 2009, at 6:46 AM, Stan Hoeppner s...@hardwarefreak.com wrote: Daniel L. Miller put forth on 12/29/2009 2:44 AM: I believe I understand where you're headed with this - but it's NOT what I was asking! Hi Daniel, Just a quick note. It's probably not a great idea to SHOUT! at Dr. Venema, the person to whom who were replying here, and who is trying to help you. Dr. Wietse Venema, Ph.D. Physics, Groningen University, is the creator/author of Postfix. He is currently employed at IBM's Thomas J. Watson Research Center and has been for over a decade. He runs this mailing list as a free courtesy to users of Postfix. He has no obligation to do so, as neither you nor I paid for Postfix or a support contract. Please keep this in mind, and the fact that when engaging Wieste regarding a Postfix issue, you are in essence speaking to God himself. If Wietse is making a suggestion to you, he likely already knows all the angles, and there is probably a darn good reason he is suggesting something to you. In the past, I have been guilty of allowing frustration to color my posts here, but, thankfully, never in a post directly to Wietse. :) God himself? Is this a joke or are you working on some creepy, endearing biography?
Questions on virtual aliases and mailboxes
Hello: I have had virtual aliases and mailboxes working well for years. I have always had a separated virtual_*_domains and virtual_*_maps file. Now I am combining them to make administration easier. For virtual aliases, I simply commented out the virtual_alias_domains directive in the main.cf file. Since it defaults to virtual_alias_maps, everything works. I tested by adding the following line: br...@junk.schang.net brian ... Everything works. :-) For virtual mailboxes, I did the same. It's my understanding that virtual_mailbox_domains defaults to virtual_mailbox_maps. However it didn't work as I expected. When I add the following line: br...@junk2.schang.net brian_mail/somefile ... I get a domain not found error. However if I add another line: junk2.schang.net 1 ... Everything works. :-) Actually the behavior for virtual mailboxes is what I expected -- the need to have the domain defined on the left-hand-side of the lookup. I was surprised that the virtual alias didn't require that. So that's my question: why does a virtual mailbox domain need to be explicitly defined on the LHS of virtual_mailbox_maps, while a virtual alias domain works without the domain defined on the LHS of virtual_alias_maps? Thank you. -- Brian Schang address_verify_map = btree:/var/lib/postfix/verify address_verify_negative_cache = yes address_verify_negative_expire_time = 6d address_verify_negative_refresh_time = 1d address_verify_positive_expire_time = 6d address_verify_positive_refresh_time = 1d alias_database = $alias_maps alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases, ldap:/etc/postfix/ldap_aliases.cf biff = no canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix data_directory = /var/lib/postfix debug_peer_level = 2 defer_transports = delay_warning_time = 4h disable_dns_lookups = no disable_mime_output_conversion = no html_directory = /usr/share/doc/packages/postfix-doc/html inet_interfaces = all inet_protocols = all mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = /usr/bin/procmail mailbox_size_limit = 0 mailbox_transport = mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = !bb.schang.net,!blackberry.schang.net,!facebook.schang.net,!football.schang.net,!linux.schang.net,!lists.schang.net,!mobile.schang.net,!wireless.schang.net,!wixom.schang.net,schang.net masquerade_exceptions = root message_size_limit = 2048 mydestination = $myhostname,localhost.$mydomain,localhost,$mydomain,server2.schang.net mydomain = schang.net myhostname = s2.schang.net mynetworks = cidr:/etc/postfix/network_table.cidr myorigin = $mydomain newaliases_path = /usr/bin/newaliases notify_classes = resource,software,2bounce parent_domain_matches_subdomains = smtpd_access_maps queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix-doc/README_FILES relay_domains = hash:/etc/postfix/relay_domains relay_recipient_maps = relayhost = relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix-doc/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = no smtp_tls_security_level = none smtpd_client_restrictions = smtpd_data_restrictions = reject_unauth_pipelining smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = hash:/etc/postfix/access reject_unknown_reverse_client_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unlisted_recipient reject_unknown_sender_domainreject_unknown_recipient_domain permit_mynetworks reject_unlisted_sender check_client_access hash:/etc/postfix/client_checks reject_non_fqdn_helo_hostname reject_invalid_helo_hostnamereject_unauth_destination check_recipient_access hash:/etc/postfix/recipient_checks reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net smtpd_sasl_auth_enable = no smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_sender_restrictions = smtpd_tls_CAfile = /etc/postfix/ca.crt smtpd_tls_cert_file = /etc/postfix/postfix-crt.pem smtpd_tls_fingerprint_digest = sha1 smtpd_tls_key_file = /etc/postfix/postfix-key.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_security_level = none smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache smtpd_tls_session_cache_timeout = 3600s strict_8bitmime = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 550 unverified_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps, ldap:/etc/postfix/ldap_virtual_alias.cf virtual_gid_maps = hash:/etc/postfix/virtual_gid_maps virtual_mailbox_base = /var/spool/mail
Re: Random Source Parameter Error
On 12/29/2009 7:43 AM, Dennis Putnam wrote: I'm trying to set up TLS on Postfix 2.5.5 and 'tlsmgr' keeps getting a fatal error on this statement: tls_random_source = dev:/dev/urandom It seems to work when I comment it out but I don't really understand what it does or if it is needed for TLS to work let alone what it should be to fix it. Can someone help me out? Thanks. The docs tell what it is. http://www.postfix.org/postconf.5.html#tls_random_source Most systems have this set to a reasonable default; you shouldn't need to specify this parameter. If TLS works when you remove the parameter, good. -- Noel Jones
Re: Random Source Parameter Error
Hi Noel, Thanks. I think that is what I really wanted to know. That parameter was configured automatically by an installer, I think, so if I don't need it then all the better. TLS does appear to be working so I guess I won't worry. On Dec 29, 2009, at 10:41 AM, Noel Jones wrote: On 12/29/2009 7:43 AM, Dennis Putnam wrote: I'm trying to set up TLS on Postfix 2.5.5 and 'tlsmgr' keeps getting a fatal error on this statement: tls_random_source = dev:/dev/urandom It seems to work when I comment it out but I don't really understand what it does or if it is needed for TLS to work let alone what it should be to fix it. Can someone help me out? Thanks. The docs tell what it is. http://www.postfix.org/postconf.5.html#tls_random_source Most systems have this set to a reasonable default; you shouldn't need to specify this parameter. If TLS works when you remove the parameter, good. -- Noel Jones Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
Re: Random Source Parameter Error
Dennis Putnam: Hi Ralf, Thanks for the reply Here is the text of the sequence of errors: Dec 29 08:26:41 xserveeml postfix/tlsmgr[64439]: fatal: poll: Unknown error: 0 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: process /usr/libexec/postfix/tlsmgr pid 64439 exit status 1 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: /usr/libexec/postfix/tlsmgr: bad command startup -- throttling The only way I found which statement was doing it, was to comment/uncomment each TLS parameter one at a time reloading postfix. Apparently, your system's poll() implementation returns -1 with errno==0 when applied to /dev/urandom. Maybe you have security software turned on such as SeLinux, Apparmor, or other that interferes with legitimate system calls. I don't support such configurations. Otherwise, consider upgrading to a less buggy kernel. Wietse
Re: Random Source Parameter Error
On Tue, Dec 29, 2009 at 10:44:09AM -0500, Dennis Putnam wrote: Here is the text of the sequence of errors: Dec 29 08:26:41 xserveeml postfix/tlsmgr[64439]: fatal: poll: Unknown error: 0 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: process /usr/libexec/postfix/tlsmgr pid 64439 exit status 1 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: /usr/libexec/postfix/tlsmgr: bad command startup -- throttling The poll(2) system call is not implemented for the /dev/urandom device or blocked by Security Enhancements to the OS. Disable SELinux, AppArmor, ... and try again. If it still fails, you are on an unsupported O/S. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Random Source Parameter Error
On 12/29/09 5:44 PM, Dennis Putnam wrote: Hi Ralf, Thanks for the reply Here is the text of the sequence of errors: Dec 29 08:26:41 xserveeml postfix/tlsmgr[64439]: fatal: poll: Unknown error: 0 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: process /usr/libexec/postfix/tlsmgr pid 64439 exit status 1 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: /usr/libexec/postfix/tlsmgr: bad command startup -- throttling The only way I found which statement was doing it, was to comment/uncomment each TLS parameter one at a time reloading postfix. well. did you mockup the paths to commands? possibly the path /usr/libexec/postfix/tlsmgr is not correct? um, debian nonworking config by default? -- Eero
Re: TLS Configuration on Postfix
On Mon, Dec 21, 2009 at 12:05 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: Yes, sorry, the rest of OP's message was about smtpd(8), failed to notice this was smtp(8). Yes: smtp_tls_security_level = may So are you suggestion in my current 'main.cf' I need to change the parameter from smtpd_tls_security_level = may to smtp_tls_security_level = may? I got my config from the following URL Wiki / Howto: http://wiki.centos.org/HowTos/postfix_sasl#head-50a7952d755088f3f88df33cdf814800bc42835a It shows the parameter as smtpd_tls_security_level = may. Is this wrong according to you guys on the list?
Re: Random Source Parameter Error
Hi Wietse, I am running OS X (10.6.2) but beyond that I don't know what security software might interfere as Apple hides a lot from the admin. However, as I stated in an earlier reply, TLS seems to be working without that parameter. The only thing that gives me pause, is that I get this warning in the log for incoming TLS connections: postfix/tlsmgr[67966]: warning: no entropy source specified with parameter tls_random_source I don't know if that is something I need to worry about or not. On Dec 29, 2009, at 10:54 AM, Wietse Venema wrote: Dennis Putnam: Hi Ralf, Thanks for the reply Here is the text of the sequence of errors: Dec 29 08:26:41 xserveeml postfix/tlsmgr[64439]: fatal: poll: Unknown error: 0 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: process /usr/libexec/postfix/tlsmgr pid 64439 exit status 1 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: /usr/libexec/postfix/tlsmgr: bad command startup -- throttling The only way I found which statement was doing it, was to comment/uncomment each TLS parameter one at a time reloading postfix. Apparently, your system's poll() implementation returns -1 with errno==0 when applied to /dev/urandom. Maybe you have security software turned on such as SeLinux, Apparmor, or other that interferes with legitimate system calls. I don't support such configurations. Otherwise, consider upgrading to a less buggy kernel. Wietse Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
Re: TLS Configuration on Postfix
On Tue, Dec 29, 2009 at 11:14:37AM -0500, Carlos Williams wrote: On Mon, Dec 21, 2009 at 12:05 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: Yes, sorry, the rest of OP's message was about smtpd(8), failed to notice this was smtp(8). Yes: ?? ??smtp_tls_security_level = may So are you suggestion in my current 'main.cf' I need to change the parameter from smtpd_tls_security_level = may to smtp_tls_security_level = may? No. You need both. The first is for receiving mail via TLS, the second is for sending mail via TLS. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Random Source Parameter Error
On Tue, Dec 29, 2009 at 05:57:20PM +0200, Eero Volotinen wrote: On 12/29/09 5:44 PM, Dennis Putnam wrote: Hi Ralf, Thanks for the reply Here is the text of the sequence of errors: Dec 29 08:26:41 xserveeml postfix/tlsmgr[64439]: fatal: poll: Unknown error: 0 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: process /usr/libexec/postfix/tlsmgr pid 64439 exit status 1 Dec 29 08:26:42 xserveeml postfix/master[64050]: warning: /usr/libexec/postfix/tlsmgr: bad command startup -- throttling The only way I found which statement was doing it, was to comment/uncomment each TLS parameter one at a time reloading postfix. well. did you mockup the paths to commands? possibly the path /usr/libexec/postfix/tlsmgr is not correct? um, debian nonworking config by default? No. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: possible problem with postfix/local??
satishkumarp2k1: Is the alias table generated dynamically? It is possible that it's not readable (still being written) at the time the lookup happens? Yes, correct. All the alias files are generated using perl scripts, which run periodically. The scripts actually generate temporary alias files (while generating the aliases) and then just use mv command to the actual alias file. Do you still think lookup might fail even in this case?? The rename into place approach is generally safe (except with moves between across file system boundaries, or with DBM files which come in pairs). Renaming a database is definitely safer than overwriting. However, if a user is added then there is a brief time where a some Postfix program may still have a handle to the old database copy that does not have that user. That amount of time is the time needed to handle a mail delivery request. Wietse
Re: In-queue rejections
Sahil Tandon put forth on 12/29/2009 9:08 AM: God himself? Is this a joke or are you working on some creepy, endearing biography? http://en.wikipedia.org/wiki/Analogy According to Jewish and Christian belief, God is the creator of the universe, and is all knowing of all things in the universe. Wietse created Postfix, and is all knowing of all things within Postfix. Via analogy, Wietse is the God of Postfix. I'm quite surprised this required explanation. Maybe this frequent analogy is exclusively an American cultural thing. Michael Jordan has been called the God of basketball, Donald Trump the God of New York real estate (in the 80s anyway). It's frequently used to describe someone who is the top master of a craft, subject, sporting or business endeavor, etc. I believe Genghis Khan has been called the God of war, though I don't know if that was coined by an American or not. -- Stan
Re: Random Source Parameter Error
Dennis Putnam: Hi Wietse, I am running OS X (10.6.2) but beyond that I don't know what This suggests that MacOS /dev/urandom has a broken poll() interface. What other /dev/*random devices do you have? As long as you use a device that does not block, Postfix will be fine. security software might interfere as Apple hides a lot from the admin. However, as I stated in an earlier reply, TLS seems to be working without that parameter. The only thing that gives me pause, is that I get this warning in the log for incoming TLS connections: postfix/tlsmgr[67966]: warning: no entropy source specified with parameter tls_random_source I don't know if that is something I need to worry about or not. It just means that it will take more time before Postfix accumulates enough randomness to make cryptokeys unpredictable. Wietse
Re: Random Source Parameter Error
On Tue, Dec 29, 2009 at 11:19:11AM -0500, Dennis Putnam wrote: Hi Wietse, I am running OS X (10.6.2) but beyond that I don't know what security software might interfere as Apple hides a lot from the admin. However, as I stated in an earlier reply, TLS seems to be working without that parameter. The only thing that gives me pause, is that I get this warning in the log for incoming TLS connections: postfix/tlsmgr[67966]: warning: no entropy source specified with parameter tls_random_source I'll look into this when I get a chance to test Postfix on a 10.6 system. It is possible that /dev/urandom does not support poll(2) with Snow Leopard. Unlike /dev/random, it is a non-blocking device, so arguably no polling is required, the poll() should always succeed immediately of course, failing is anti-social. We may need a new main.cf option to enable blocking reads of the entropy device, or a new MacOSX-specific compile-time flag to trigger read() rather than timed_read() of the entropy device. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Random Source Parameter Error
On Tue, Dec 29, 2009 at 11:34:39AM -0500, Wietse Venema wrote: What other /dev/*random devices do you have? As long as you use a device that does not block, Postfix will be fine. With 10.5 there's just: crw-rw-rw- 1 root wheel8, 0 Dec 29 11:37 /dev/random crw-rw-rw- 1 root wheel8, 1 Oct 30 01:09 /dev/urandom with the former a blocking device presumably... I'll check out 10.6 later today or tomorrow. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: Random Source Parameter Error
Victor Duchovni: On Tue, Dec 29, 2009 at 11:19:11AM -0500, Dennis Putnam wrote: Hi Wietse, I am running OS X (10.6.2) but beyond that I don't know what security software might interfere as Apple hides a lot from the admin. However, as I stated in an earlier reply, TLS seems to be working without that parameter. The only thing that gives me pause, is that I get this warning in the log for incoming TLS connections: postfix/tlsmgr[67966]: warning: no entropy source specified with parameter tls_random_source I'll look into this when I get a chance to test Postfix on a 10.6 system. It is possible that /dev/urandom does not support poll(2) with Snow Leopard. Unlike /dev/random, it is a non-blocking device, so arguably no polling is required, the poll() should always succeed immediately of course, failing is anti-social. We may need a new main.cf option to enable blocking reads of the entropy device, or a new MacOSX-specific compile-time flag to trigger read() rather than timed_read() of the entropy device. Is Postfix is still the default MTA? If so then it is surprising than this /dev/urandom bug was not found during testing. Allowing /dev/*random to block Postfix is not a good idea, because these reads are done by a single tlsmgr process. Wietse
Re: Random Source Parameter Error
Victor Duchovni: On Tue, Dec 29, 2009 at 11:34:39AM -0500, Wietse Venema wrote: What other /dev/*random devices do you have? As long as you use a device that does not block, Postfix will be fine. With 10.5 there's just: crw-rw-rw- 1 root wheel8, 0 Dec 29 11:37 /dev/random crw-rw-rw- 1 root wheel8, 1 Oct 30 01:09 /dev/urandom with the former a blocking device presumably... I'll check out 10.6 later today or tomorrow. Postfix sets a time limit of 10s on random device reads. If /dev/random is less buggy then that could be a workaround. Wietse
Re: Questions on virtual aliases and mailboxes
On Tue, Dec 29, 2009 at 10:15:05AM -0500, Brian Schang wrote: So that's my question: why does a virtual mailbox domain need to be explicitly defined on the LHS of virtual_mailbox_maps, while a virtual alias domain works without the domain defined on the LHS of virtual_alias_maps? Virtual alias rewriting happens for all domains, not just virtual alias domains. However, if you want a virtual alias domain, you must list it in virtual_alias_domains (which defaults to $virtual_alias_maps). Not listing the domain means: - Postfix won't accept mail for the domain from untrusted clients - Postfix won't reject unlisted recipients in that domain. -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: In-queue rejections
On Dec 29, 2009, at 11:29 AM, Stan Hoeppner s...@hardwarefreak.com wrote: Sahil Tandon put forth on 12/29/2009 9:08 AM: God himself? Is this a joke or are you working on some creepy, endearing biography? http://en.wikipedia.org/wiki/Analogy According to Jewish and Christian belief, God is the creator of the universe, and is all knowing of all things in the universe. Wietse created Postfix, and is all knowing of all things within Postfix. Via analogy, Wietse is the God of Postfix. I'm quite surprised this required explanation. Maybe this frequent analogy is exclusively an American cultural thing. Michael Jordan has been called the God of basketball, Donald Trump the God of New York real estate (in the 80s anyway). It's frequently used to describe someone who is the top master of a craft, subject, sporting or business endeavor, etc. I believe Genghis Khan has been called the God of war, though I don't know if that was coined by an American or not. My goodness. Your idolatry (by way of analogy or otherwise) is off topic here, please stop it. And your assumptions about posters' natonality and culture also an epic fail. Finally, please leave the pedantry to the experts! Last post on this thread.
Re: Random Source Parameter Error
On Tue, Dec 29, 2009 at 11:45:57AM -0500, Wietse Venema wrote: Victor Duchovni: On Tue, Dec 29, 2009 at 11:34:39AM -0500, Wietse Venema wrote: What other /dev/*random devices do you have? As long as you use a device that does not block, Postfix will be fine. With 10.5 there's just: crw-rw-rw- 1 root wheel8, 0 Dec 29 11:37 /dev/random crw-rw-rw- 1 root wheel8, 1 Oct 30 01:09 /dev/urandom with the former a blocking device presumably... I'll check out 10.6 later today or tomorrow. Postfix sets a time limit of 10s on random device reads. If /dev/random is less buggy then that could be a workaround. On Linux, I am not a big fan of /dev/random. In addition to the unnecessary latency, its security properties are more questionable than those of a decent PRNG with intermittent seeding via external events. The BSD manpage for random/urandom on MacOSX claims the two are identical (though the device minor number is different), with both running Yarrow. So /dev/random is probably fine, but it may also fail to implement poll(), unless some bozo specifically made /dev/urandom different, by noting its alleged non-blocking semantics, and made it non-pollable... -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: In-queue rejections
Sahil Tandon: On Dec 29, 2009, at 11:29 AM, Stan Hoeppner s...@hardwarefreak.com wrote: Sahil Tandon put forth on 12/29/2009 9:08 AM: God himself? Is this a joke or are you working on some creepy, endearing biography? http://en.wikipedia.org/wiki/Analogy According to Jewish and Christian belief, God is the creator of the universe, and is all knowing of all things in the universe. Wietse created Postfix, and is all knowing of all things within Postfix. Via analogy, Wietse is the God of Postfix. I'm quite surprised this required explanation. Maybe this frequent analogy is exclusively an American cultural thing. Michael Jordan has been called the God of basketball, Donald Trump the God of New York real estate (in the 80s anyway). It's frequently used to describe someone who is the top master of a craft, subject, sporting or business endeavor, etc. I believe Genghis Khan has been called the God of war, though I don't know if that was coined by an American or not. My goodness. Your idolatry (by way of analogy or otherwise) is off topic here, please stop it. And your assumptions about posters' natonality and culture also an epic fail. Finally, please leave the pedantry to the experts! Last post on this thread. We have a cultural confusion. I think Stan's use of God does not imply adolation but rather indicates a special role (in this case with respect to Postfix). In other contexts, God implies super-human properties. Not here. Wietse
Re: address rewriting
On Tue, 2009-12-29 at 01:11 -0500, Victor Duchovni wrote: No, it means that address *normalization* to standard form is done at least three times: - smtpd resolve envelope addresses to (transport, nexthop, standard form) for access checks Why does smptd need (or for what does it use transport/nexthop? Or is this just the way to determine whether it (the system) is final destination or relay for that mail? Don't confuse transformation to normal form with real rewriting. ok ;) But... It seems that exactly this works for the recipient! What I tried was: mydestination = example.com remote.domain Why did you add a remote domain to mydestination? In what sense is it remote after that change? Purely for testing,.. I should have named it here perhaps hosted.domain (of course in a production setup I would not use the local domain address class for hosted domains). I'd have expected that this does not work, and only local users would be accepted as recipients. However, it worked (perhaps I should triple-check it ^^) Your expectation is most peculiar in this case. The remote domains are exactly those that are not listed in one of the not default address classes: http://www.postfix.org/ADDRESS_CLASS_README.html#classes Of course,... I think I've described my question not well enough. What I wonder is: When does recipient checking happen? Probably somewhere during the receiving stage (because we want smtpd to reject unknown recipients). But unlike when it checks the domain of the mail (where e.g. virtual aliases are not taken into account) it seems that when checking the user-part of the address virtual aliases are taken into account. Adding example.com (or remote.domain) to mydestination above should mean that ONLY existing local user@example.com (or @remote.domain or @address literal is accepted, right? But it seems that also non-existent local user@example.com domain is accepted _if_ it is rewritten to some existing local user with virtual_alias_maps (the domains were not part of virtual_alias_domains)! And I do not really understand why ;) Thanks, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Random Source Parameter Error
Victor Duchovni: On Tue, Dec 29, 2009 at 11:44:01AM -0500, Wietse Venema wrote: Is Postfix is still the default MTA? If so then it is surprising than this /dev/urandom bug was not found during testing. On my current 10.5 system, yes Postfix is still the default MTA, but: $ /usr/sbin/postconf -d tls_random_source tls_random_source = So Apple may have worked-around the inconvenient security feature. :-( The first call to RAND_bytes() in OpenSSL will (it seems after a quick read of OpenSSL source code) call RAND_poll() once which reads /dev/urandom, via poll() on Linux systeme and select() on other Unix-like systems... Postfix is already stuck with select() on MacOS for all other I/O event handling, so we could safely remove poll() support from Postfix when building for MacOS. Wietse
Re: Code burn-in: postscreen/verify cache cleanup
Ralf Hildebrandt: * Wietse Venema wie...@porcupine.org: You may want to give a heads-up to the maintainer as I am just about to release this code as a regular experimental release. Cache cleanup will definitely be part of the Postfix 2.7 stable release, so they will have to deal with it in a month or so anyway. I'm running the unpatched version here; it seems to work Dec 29 04:20:17 spike postfix/postscreen[44900]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=134 dropped=19 entries Dec 29 06:19:33 spike postfix/verify[46072]: cache /var/lib/postfix/verify.db full cleanup: retained=1726 dropped=28 entries The initial cleanup: Dec 29 10:16:35 mail postfix/postscreen[12078]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=8460 dropped=274056 entries Dec 29 10:17:13 mail postfix/verify[12105]: cache /var/lib/postfix/verify.db full cleanup: retained=109892 dropped=648105 entries Thanks. Perhaps it makes sense to change verify(8) so that a persistent database becomes the default as it is with postscreen. Wietse
Re: In-queue rejections
Wietse Venema put forth on 12/29/2009 10:56 AM: We have a cultural confusion. I think Stan's use of God does not imply adolation but rather indicates a special role (in this case with respect to Postfix). Correct. The God analogy simply implies creator and supreme authority of the subject, in this case, Postfix, and that one should show some respect to the creator (especially the creator of the *free* software the OP relies upon). Wietse is the creator and supreme authority of Postfix. The OP was obviously unaware of this fact or his prose would have been more civil. Anyway, my apologies for causing a stir with this common analogy (common here in the states anyway). I was merely attempting to apply a little positive cluestick to the OP. -- Stan
Re: In-queue rejections
Wietse Venema wrote: Daniel L. Miller: 5F47320CEC2 4338844 Mon Dec 28 13:12:09 idiotu...@amfes.com (host mail.fireprobymesa.com[65.40.152.138] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) jeff...@fireprobymesa.com That does not seem right. You have soft_bounce turned on in main.cf or master.cf. As usual - you're perfectly correct. Now...WHY did I deliberately turn on soft_bounce...? Must have been something left over from spam filter testing. So...I unreservedly withdraw my question about an e-mail interface for queue management. But...is there any provision for more advanced bounce processing? -- Daniel
Re: In-queue rejections
Daniel L. Miller: Wietse Venema wrote: Daniel L. Miller: 5F47320CEC2 4338844 Mon Dec 28 13:12:09 idiotu...@amfes.com (host mail.fireprobymesa.com[65.40.152.138] said: 550 5.1.1 User unknown (in reply to RCPT TO command)) jeff...@fireprobymesa.com That does not seem right. You have soft_bounce turned on in main.cf or master.cf. As usual - you're perfectly correct. Now...WHY did I deliberately turn on soft_bounce...? Must have been something left over from spam filter testing. So...I unreservedly withdraw my question about an e-mail interface for queue management. But...is there any provision for more advanced bounce processing? I offered a solution that allows you to set up a rule for each typo-ed recipient domain or address, but you dismissed that because you wanted something that requires no configuration. At that point it is no longer a mail server problem but a database problem, so this will have to wait until someone makes a suitable database available. Wietse
Re: Random Source Parameter Error
On Tue, Dec 29, 2009 at 11:35:09AM -0500, Victor Duchovni wrote: I'll look into this when I get a chance to test Postfix on a 10.6 system. It is possible that /dev/urandom does not support poll(2) with Snow Leopard. Unlike /dev/random, it is a non-blocking device, so arguably no polling is required, the poll() should always succeed immediately of course, failing is anti-social. Got the 10.6.2 system up and running mostly. The stock Postfix that comes from Apple has: # postconf -d mail_version tls_random_source mail_version = 2.5.5 tls_random_source = When I build Postfix from Macports, I get a 2.6.2 build, which also defaults to: tls_random_source = however, setting: tls_random_source = dev:/dev/urandom works just fine, no noise in the mail log. Looking at tlsmgr(8) with dtruss shows, Postfix 2.6.2 using select() for timed read. open(/dev/urandom\0, 0x0, 0x0) = 7 0 geteuid(0x100305D1D, 0x100303144, 0x0) = 0 0 getegid(0x100305D1D, 0x100303144, 0x0) = 0 0 geteuid(0x1B, 0x1B, 0x0) = 0 0 setegid(0x1B, 0x1B, 0x0) = 0 0 setgroups(0x1, 0x7FFF5FBFFB5C, 0x0) = 0 0 seteuid(0x1B, 0x7FFF5FBFFB5C, 0x0) = 0 0 stat64(/var/lib/postfix-test\0, 0x7FFF5FBFFA90, 0x74) = 0 0 open(/var/lib/postfix-test/prng_exch\0, 0x202, 0x180) = 8 0 geteuid(0x0, 0x0, 0xFC080) = 27 0 seteuid(0x0, 0x0, 0x0) = 0 0 setegid(0x0, 0x0, 0x0) = 0 0 setgroups(0x1, 0x7FFF5FBFFB5C, 0x0) = 0 0 setgid(0x1B, 0x10030587C, 0x100305890) = 0 0 initgroups(0x6, 0x7FFF5FBFFB30, 0x1B)= 0 0 setuid(0x1B, 0x6, 0x0) = 0 0 select(0x8, 0x7FFF5FBFF940, 0x0, 0x7FFF5FBFF8C0, 0x7FFF5FBFF9C0) = 2 0 read(0x7, \341\26103[E\201\221\215\353\260j\207\017\244\031\v\002\n\354\364\374\206+\201\363\2636\031J\205\355\0, 0x20)= 32 0 The OP's problem is most likely specific to Apple's build of 2.5.5, where timed_read() uses poll() but /dev/urandom does not cooperate... -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: In-queue rejections
Wietse Venema wrote: Daniel L. Miller: Wietse Venema wrote: Daniel L. Miller: So...I unreservedly withdraw my question about an e-mail interface for queue management. But...is there any provision for more advanced bounce processing? I offered a solution that allows you to set up a rule for each typo-ed recipient domain or address, but you dismissed that because you wanted something that requires no configuration. At that point it is no longer a mail server problem but a database problem, so this will have to wait until someone makes a suitable database available. As usual, I'm probably misunderstanding, so let me ask it a different way. I'm not looking to build a list of typos corrections for Postfix to automagically deal with idiot users. I want to provide users with more information to better allow them to understand what they did wrong. Example: 7A44F20CED3 4338053 Mon Dec 28 10:50:59 idiotu...@amfes.com (Host or domain name not found. Name service error for name=fireprotectionbymesa.com type=: Host not found) Seeing this in a bounce message (usually) means something to ME - but my users will just cross their eyes and think OUR system is broken. Instead, I would like a process that would take the above message and translate it to something more user-friendly. Something like: The message you attempted to send could not be delivered. The address you attempted to send to was u...@wrongexample.com. However, the part after the @ sign, wrongexample.com, is not a valid Internet name. Verify your spelling is correct. Otherwise, it is possible there is a problem with the computers at wrongexample.com and you may attempt to send your message again later. I do see that perhaps a table might have to be created for matching the various server responses to my user-friendly messages. But, if you consider this is at all worthwhile - how would it be implemented? Is this something that would require a change to the bounce program? Or is the potential already there - and just changing some existing settings would allow me to pipe the rejection message back through an external filter? -- Daniel
Re: In-queue rejections
Daniel L. Miller: Wietse Venema wrote: Daniel L. Miller: Wietse Venema wrote: Daniel L. Miller: So...I unreservedly withdraw my question about an e-mail interface for queue management. But...is there any provision for more advanced bounce processing? I offered a solution that allows you to set up a rule for each typo-ed recipient domain or address, but you dismissed that because you wanted something that requires no configuration. At that point it is no longer a mail server problem but a database problem, so this will have to wait until someone makes a suitable database available. As usual, I'm probably misunderstanding, so let me ask it a different way. I'm not looking to build a list of typos corrections for Postfix to automagically deal with idiot users. I want to provide users with more information to better allow them to understand what they did wrong. Example: 7A44F20CED3 4338053 Mon Dec 28 10:50:59 idiotu...@amfes.com (Host or domain name not found. Name service error for name=fireprotectionbymesa.com type=: Host not found) Seeing this in a bounce message (usually) means something to ME - but my users will just cross their eyes and think OUR system is broken. Instead, I would like a process that would take the above message and translate it to something more user-friendly. Something like: The message you attempted to send could not be delivered. The address you attempted to send to was u...@wrongexample.com. However, the part after the @ sign, wrongexample.com, is not a valid Internet name. Verify your spelling is correct. Otherwise, it is possible there is a problem with the computers at wrongexample.com and you may attempt to send your message again later. Postfix reports enhanced status codes (5.1.1 means the mailbox does not exist, etc.) in standardized non-delivery notifications. See RFC 3463 for an overview. Mail user agents can translate these standardized status codes into user-friendly text. There are good reasons why these translations should be done in MUAs (primarily, the recipient of the DSN may be in a different language zone than the MTA that sends it). Wietse
Notification emails
It appears the reason that a over-quota notification email is not being received by the sender is because according to the logs Postfix is sending these with a NULL sender. How do I set the sender for notification emails? say postmas...@site.tld...
Re: Notification emails
Michael: It appears the reason that a over-quota notification email is not being received by the sender is because according to the logs Postfix is sending these with a NULL sender. Then the RECEIVER mail configuration is broken. How do I set the sender for notification emails? say postmas...@site.tld... The Internet mail standards specify that delivery status notifications have the null sender address. This is for good reasons, and if someone disagrees, you are welcome to refer them to the standards. Wietse
Re: Notification emails
On 2009-12-30 Michael wrote: It appears the reason that a over-quota notification email is not being received by the sender is because according to the logs Postfix is sending these with a NULL sender. How do I set the sender for notification emails? say postmas...@site.tld... Please read section 3.7 of RFC 2821 to understand why you don't want to do that. The sender is supposed to be able to receive messages with a NULL sender. If these messages are discarded somewhere along the way, then that's the problem that should be fixed. Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
Re: Notification emails
On Wed, 30 Dec 2009 12:41:32 Wietse Venema wrote: The Internet mail standards specify that delivery status notifications have the null sender address. This is for good reasons, and if someone disagrees, you are welcome to refer them to the standards. Wietse Thanks Wietse. Ok. This is what's happening. With Amavis disabled on the sender's reply-address mail server - the following reject message gets through: --- This is the mail system at host DELETED. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system DELETED: delivery failed to mailbox /var/spool/mail/DELETED: error writing message: File too large unnamed Delivery report -- however with Amavis enabled the above message does not turn up in the sender's email box, thus they have no way of knowing the recipient's mailbox is full.
Re: In-queue rejections
Wietse Venema wrote: Daniel L. Miller: Wietse Venema wrote: Postfix reports enhanced status codes (5.1.1 means the mailbox does not exist, etc.) in standardized non-delivery notifications. See RFC 3463 for an overview. Mail user agents can translate these standardized status codes into user-friendly text. There are good reasons why these translations should be done in MUAs (primarily, the recipient of the DSN may be in a different language zone than the MTA that sends it). Getting closer. I may be using the wrong vocabulary - part of my lack of understanding of the SMTP protocol. My understanding is a MUA (for convenience, call it Thunderbird) will talk to a local MTA (Postfix, of course!) to send mail. After authentication and any other local checks, the local MTA accepts responsibility for the message - the MUA disconnects. The local MTA then attempts to send the message to the remote MTA. If successful...unless there's something else I don't know about, nothing further happens between the local MTA and MUA. If unsuccessful, and idiot OP's like me don't have soft_bounce enabled, the MTA will generate a bounce message and send it to the sender's address, and cancel the send. If the above is anywhere near reality - then where is the interaction between MUA and MTA for the bounce message status codes? I'm seeing an SMTP connection for the initial send operation, followed by a message retrieval by the mail reader (which doesn't necessarily have to be the same program that sent the message originally). Is the mail reader supposed to locate the enhanced status code in the message body and translate it? -- Daniel
Re: address rewriting
On Tue, 2009-12-29 at 17:29 -0500, Victor Duchovni wrote: Adding example.com (or remote.domain) to mydestination above should mean that ONLY existing local user@example.com (or @remote.domain or @address literal is accepted, right? No. It means that example.com becomes a local domain. Ok,.. of course,.. but only existing local user@localdomain should be accepted... But it seems that also non-existent local user@example.com domain is accepted _if_ it is rewritten to some existing local user with virtual_alias_maps (the domains were not part of virtual_alias_domains)! And I do not really understand why ;) Recipient validation existence of virtual mappings into account. Virtual and canonical mappings apply to all domains, so it would be a mistake to reject addresses that are rewritten downstream. So the SMTP server performs an existence test on the lookup key. So this basically means: - When checking the domains (relay control) only normalisation is done? - When validating the recipients, normalisation and all other rewritings (canonical and virtual aliases) are taken into account? Is it here where the probe messages are sent? Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Notification emails
- Original Message From: Michael p...@nettrust.co.nz To: postfix-users@postfix.org Sent: Tue, December 29, 2009 6:49:47 PM Subject: Re: Notification emails On Wed, 30 Dec 2009 12:41:32 Wietse Venema wrote: The Internet mail standards specify that delivery status notifications have the null sender address. This is for good reasons, and if someone disagrees, you are welcome to refer them to the standards. Wietse Thanks Wietse. Ok. This is what's happening. With Amavis disabled on the sender's reply-address mail server - the following reject message gets through: --- This is the mail system at host DELETED. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : delivery failed to mailbox /var/spool/mail/DELETED: error writing message: File too large unnamed Delivery report -- The above happens when the file size exceeds the maximum file size set by the receiving server. Has nothing to do with it being over quota. Try sending it with a smaller attachment or no attachment whatsoever. however with Amavis enabled the above message does not turn up in the sender's email box, thus they have no way of knowing the recipient's mailbox is full.
Re: In-queue rejections
Daniel L. Miller: Wietse Venema wrote: Daniel L. Miller: Wietse Venema wrote: Postfix reports enhanced status codes (5.1.1 means the mailbox does not exist, etc.) in standardized non-delivery notifications. See RFC 3463 for an overview. Mail user agents can translate these standardized status codes into user-friendly text. There are good reasons why these translations should be done in MUAs (primarily, the recipient of the DSN may be in a different language zone than the MTA that sends it). Getting closer. I may be using the wrong vocabulary - part of my lack of understanding of the SMTP protocol. Enhanced status codes show up in two places: 1) In SMTP server responses (550 5.1.1 User unknown). If the SMTP client loses this information there is nothing we can do to improve the user's experience. 2) In delivery status notifications. As defined in RFC 3462, these notifications consist of three parts: a) Free text (This is the mail system at foo.example.com). b) Structured text with enhanced status codes etc. c) The headers (and perhaps body) of the undelivered message. RFC 3464 describes the formatting details of 2). Wietse
Re: Code burn-in: postscreen/verify cache cleanup
* Ralf Hildebrandt ralf.hildebra...@charite.de: * Wietse Venema wie...@porcupine.org: Dec 29 04:20:17 spike postfix/postscreen[44900]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=134 dropped=19 entries Dec 29 06:19:33 spike postfix/verify[46072]: cache /var/lib/postfix/verify.db full cleanup: retained=1726 dropped=28 entries The initial cleanup: Dec 29 10:16:35 mail postfix/postscreen[12078]: cache /var/lib/postfix/ps_cache.db full cleanup: retained=8460 dropped=274056 entries Dec 29 10:17:13 mail postfix/verify[12105]: cache /var/lib/postfix/verify.db full cleanup: retained=109892 dropped=648105 entries Not using verify here, for postscreen, the number of entries retained settled itself between 2500 and 2900, the number of dropped entries varies around 300 and 500. I've noticed a vast deterioration of the databases's performance, though. 20091209 only emitted some timing warnings for updates from time to time (database rotated every Saturday as per your recommendation). With the new code, lookup timing warnings are emitted frequently for approximately 30 minutes after every cache cleanup. Guess I need a better database library. Stefan
