Re: Best Suggestion For Blacklisting Senders
On 2010-01-22 Carlos Williams wrote: On Thu, Jan 21, 2010 at 2:43 PM, Brian Evans - Postfix List wrote: This is a client IP not a sender, e. g. 'MAIL FROM: br...@example.com' The IP should go into a file referenced by a check_client_access restriction. I think I still don't have a understanding at how to properly read / understand message headers in order to create good filters in Postfix. I am very sorry for my confusion but can someone please tell me what the difference is between these two IP's I show in the headers. I am guessing one IP is the actual 'senders' IP address in which is initiating SMTP from using a client like Outlook / Thunderbird and the other IP I am guessing is the address of the senders SMTP server which establishes a connection with my Postfix MTA, right? Do I at least have this correct? [...] Received: from civismtp.uas.coop (civismtp.uas.coop [67.212.170.242]) by mail.iamghost.com (Postfix) with ESMTP id C00DB77A862 for car...@iamghost.com; Fri, 22 Jan 2010 05:29:30 -0500 (EST) Received: from wfmc.org (HELO www.wfmc.org) (192.220.23.216) (smtp-auth username editor, mechanism cram-md5) by civismtp.uas.coop (qpsmtpd/0.40) with ESMTPA; Fri, 22 Jan 2010 03:50:52 -0600 [...] There are two (2) 'Received: from' lines which both have two completely different IP's. One has a HELO 'smtp-auth' username (editor) which I assume this line to be the client sending the message, not the MTA, is this correct? No. E-Mail has a so-called store-and-forward architecture, meaning that a mail may pass through several hops, each of which accepts and forwards the mail to the next hop. User-Client - MTA - MTA - MTA - MTA - Recipient mailbox A B C D In every connection (-) the sending hop is the client, and the receiving hop is the server. Of course a user's mail client (or rather Mail User Agent, MUA) is also a client. It depends on the context who is the client in any given situation. HTH Regards Ansgar Wiechers -- Abstractions save us time working, but they don't save us time learning. --Joel Spolsky
smtp auth over ssl for smartrelay configuration
Hello everybody, I got a hole set 20 of Debian systems connected to mobile broadband internet. They are behind a NAT of with dynamic ip's. I want these systems to be able to sent emails to my server for all kind of reasons like monitoring, security updates etcetera. I want to use postfix to authorise to my secured SMTP server to be able to deliver mail. The authorisation should be like the one's used on my MTA's like Mozilla Thunderbird with SMTP authorisation. Configuration option I made up: authuser=usern...@powercraft.nl authpass=password authmethod=plain mailhub=secure.powercraft.nl:465 usessl=true Can somebody show me an example how to setup up a simple outgoing only email configuration that uses SMTP AUTH over SSL? Thanks in advance, Kind regards, Jelle
Re: smtp auth over ssl for smartrelay configuration
Jelle de Jong: Hello everybody, I got a hole set 20 of Debian systems connected to mobile broadband internet. They are behind a NAT of with dynamic ip's. I want these systems to be able to sent emails to my server for all kind of reasons like monitoring, security updates etcetera. I want to use postfix to authorise to my secured SMTP server to be able to deliver mail. The authorisation should be like the one's used on my MTA's like Mozilla Thunderbird with SMTP authorisation. Configuration option I made up: authuser=usern...@powercraft.nl authpass=password authmethod=plain mailhub=secure.powercraft.nl:465 usessl=true Can somebody show me an example how to setup up a simple outgoing only email configuration that uses SMTP AUTH over SSL? Postfix SASL: http://www.postfix.org/SASL_README.html Postfix TLS: http://www.postfix.org/TLS_README.html These are organized in client and server sections, with examples. There is no need to repeat this information on the mailing list. Wietse
Re: Best way to put spam on hold queue?
Jozsef Kadlecsik: Hello, We plan to add the possibility for our users to choose that messages categorized as spam are put on the hold queue instead of the default reject. Thus it'll be possible to release the false positives, which can make life easier for them. Currently I can see two ways to accomplish it, both have got pros and cons. a. Single postfix instance with large enough queue partition. Easier, simpler, however if the queue partition becomes full, the normal traffic is blocked as well. b. Two postfix instances, the first one sends the messages to be held to the second one via a selected transport. (Two policy daemons are required as well.) The first instance handles all the good traffic and diverts the bad one to the second instance, which has the single job to put messages onto its hold queue and release from there. That way the hold queue can be separated and moved to a second partition. Still, if the second instance stops working for whatever reason, the messages to be held will stuck at the first instance. How could one achieve that the held messages are separated from the normal traffic (i.e. hold queue on another partition), but if the messages cannot be held, then those gets rejected instead of queued? Given Postfix's architecture, a loosely-coupled pipeline without global feedback, there is no obvious way to build global feedback into Postfix itself. I suggest that you run an email monitoring system. When the secondary system stops accepting mail for more than some minimum amount of time (allowing enough time for the system to reboot), update the configuration on the primary system. Wietse
Recipient address rejected: Access denied while SASL/TLS enabled
Dear I don't understand why but i think that Postfix did want to send the authentication request in the SMTP protocol. In this case , the client (thunderbird) cannot send authentication parameters trough Internet. When executing saslfinger, there is not information in the -- mechanisms on localhost -- i think that perhaps this is the problem. How can i resolv it Many thanks Output debug log Jan 23 15:09:23 mx1 postfix/smtpd[25192]: START Sender address RESTRICTIONS Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_sasl_authenticated Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_sasl_authenticated status=0 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_mynetworks Jan 23 15:09:23 mx1 postfix/smtpd[25192]: permit_mynetworks: 129.168.201-77.rev.gaoland.net 77.201.168.129 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? 127.0.0.0/8 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? 127.0.0.0/8 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? [:::127.0.0.0]/104 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? [:::127.0.0.0]/104 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? [::1]/128 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? [::1]/128 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? 91.121.48.19 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? 91.121.48.19 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match: 129.168.201-77.rev.gaoland.net: no match Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match: 77.201.168.129: no match Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_mynetworks status=0 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: END Sender address RESTRICTIONS Jan 23 15:09:23 mx1 postfix/smtpd[25192]: START Recipient address RESTRICTIONS Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_sasl_authenticated Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_sasl_authenticated status=0 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_mynetworks Jan 23 15:09:23 mx1 postfix/smtpd[25192]: permit_mynetworks: 129.168.201-77.rev.gaoland.net 77.201.168.129 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? 127.0.0.0/8 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? 127.0.0.0/8 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? [:::127.0.0.0]/104 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? [:::127.0.0.0]/104 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? [::1]/128 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? [::1]/128 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostname: 129.168.201-77.rev.gaoland.net ~? 91.121.48.19 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_hostaddr: 77.201.168.129 ~? 91.121.48.19 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match: 129.168.201-77.rev.gaoland.net: no match Jan 23 15:09:23 mx1 postfix/smtpd[25192]: match_list_match: 77.201.168.129: no match Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=permit_mynetworks status=0 Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=reject Jan 23 15:09:23 mx1 postfix/smtpd[25192]: NOQUEUE: reject: RCPT from 129.168.201-77.rev.gaoland.net[77.201.168.129]: 554 5.7.1 da...@xxx.eu: Recipient address rejected: Access denied; from=dtouz...@xxx.org to=da...@xxx.eu proto=ESMTP helo=[192.168.1.20] Jan 23 15:09:23 mx1 postfix/smtpd[25192]: generic_checks: name=reject status=2 Output of saslfinger, you can see there is no -- mechanisms on localhost -- saslfinger - postfix Cyrus sasl configuration samedi 23 janvier 2010, 15:04:40 (UTC+0100) version: 1.0.4 mode: server-side SMTP AUTH -- basics -- Postfix: 2.5.5 System: Debian GNU/Linux 5.0 \n \l -- smtpd is linked to -- libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0xb7d7c000) -- active SMTP AUTH and TLS parameters for smtpd -- broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_local_domain = $myhostname smtpd_sasl_path = smtpd smtpd_sasl_security_options = noanonymous smtpd_tls_CAfile = /etc/ssl/certs/postfix/ca.csr smtpd_tls_ask_ccert = no smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/postfix/ca.crt smtpd_tls_key_file = /etc/ssl/certs/postfix/ca.key smtpd_tls_received_header = yes smtpd_tls_req_ccert = no smtpd_tls_security_level = none smtpd_tls_session_cache_database = btree:$data_directory/smtpd_tls_cache smtpd_use_tls = yes -- content of /usr/lib/sasl2/smtpd.conf -- pwcheck_method: saslauthd
Re: Best way to put spam on hold queue?
On Sat, 23 Jan 2010, Wietse Venema wrote: Jozsef Kadlecsik: How could one achieve that the held messages are separated from the normal traffic (i.e. hold queue on another partition), but if the messages cannot be held, then those gets rejected instead of queued? Given Postfix's architecture, a loosely-coupled pipeline without global feedback, there is no obvious way to build global feedback into Postfix itself. I suggest that you run an email monitoring system. When the secondary system stops accepting mail for more than some minimum amount of time (allowing enough time for the system to reboot), update the configuration on the primary system. Yes, monitoring is inevitable. And that imply you would prefer the two instances setup :-). Just as a theoretical question, would it fit somehow into Postfix to support the hold queue *alone* in a separated partition? The flow would look like - normal smtpd processing of incoming request - if the action is HOLD and hold queue on a separate partition by config, ask cleanup to forget about the queue entry in incoming and request a new one in the hold queue - if message cannot be queued successfully, report it to the client Of course it might mean too much violation of the Postfix internals. Best regards, Jozsef - E-mail : kad...@blackhole.kfki.hu, kad...@mail.kfki.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
Re: Timeout of SMTP servers
On Jan 23, 2010, at 4:24 PM, Sahil Tandon wrote: On Fri, 22 Jan 2010, Martijn de Munnik wrote: RFC2821 section 4.5.3.2 Timeouts reads An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender. The key word is SHOULD, as opposed to MUST. SHOULD equals MUST unless you have a really good reason. I'm trying to figure out if somebody on the list knows a really good reason. When I try to connect to an one.com mx (mx-cluster1.one.com or mx-cluster2.one.com) I notice they will close the connection after about 3 seconds. Why do they do this? Is anybody else using such short timeouts? That timeout does seem foolishly short, but they might have legitimate reasons that are best explained by ... them! Try pinging their postmaster. -- Sahil Tandon sa...@tandon.net
Re: Best way to put spam on hold queue?
Jozsef Kadlecsik: On Sat, 23 Jan 2010, Wietse Venema wrote: Jozsef Kadlecsik: How could one achieve that the held messages are separated from the normal traffic (i.e. hold queue on another partition), but if the messages cannot be held, then those gets rejected instead of queued? Given Postfix's architecture, a loosely-coupled pipeline without global feedback, there is no obvious way to build global feedback into Postfix itself. I suggest that you run an email monitoring system. When the secondary system stops accepting mail for more than some minimum amount of time (allowing enough time for the system to reboot), update the configuration on the primary system. Yes, monitoring is inevitable. And that imply you would prefer the two instances setup :-). Just as a theoretical question, would it fit somehow into Postfix to support the hold queue *alone* in a separated partition? The architecture requires Postfix can move messages between queues without having to make copies. Wietse
Re: Timeout of SMTP servers
Martijn de Munnik: On Jan 23, 2010, at 4:24 PM, Sahil Tandon wrote: On Fri, 22 Jan 2010, Martijn de Munnik wrote: RFC2821 section 4.5.3.2 Timeouts reads An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender. The key word is SHOULD, as opposed to MUST. SHOULD equals MUST unless you have a really good reason. I'm trying to figure out if somebody on the list knows a really good reason. Ask THEIR postmaster. Wietse
Re: smtp auth over ssl for smartrelay configuration
Victor Duchovni wrote, on 23-01-10 17:48: On Sat, Jan 23, 2010 at 05:31:47PM +0100, Jelle de Jong wrote: postconf -e 'smtp_tls_security_level = encrypt' Is this SMTP client going to send all mail to a small set of TLS enabled relay hosts? Or are you choosing to not be able to send any email to the vast majority of domains whose MX hosts don't offer TLS? The system is a satellite system that is only sending mail to one secure mail server, the mailrelay is only affable for smtp auth over ssl. the hostname of the sender will fail every sane check if it sent to other machines, because it has no fixed ip, and is behind a series of nat's. postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1' Why disable both SSLv2 and TLSv1?! Leave this setting at its default value, or disable just SSLv2. Does your client or server correctly handle SSLv3, but fail to interoperate via TLSv1? Well my server supports SSLv3 just fine, so I thought I disable everything lower, and if better protocols come around postfix will update and will still be able to use the newer stuff since I did not force it to only use SSLv3. Hope that helps some people :) And does not mislead too many. A tutorial needs to not only provide working settings, but also explain the use-case to which they apply and why the settings are the right ones to the use-case at hand. All true, that sad the pointer I gave were not related to above and the documentation handles these points quite well. Best regards, Jelle
Putting $data_directory on a RAM filesystem
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)? I know about RAM not being persistent across reboots, and I understand what happens if the $postscreen_cache_map (or all the contents in $data_directory) are lost. Stefan
Re: Timeout of SMTP servers
On Sat, 23 Jan 2010, Martijn de Munnik wrote: On Jan 23, 2010, at 4:24 PM, Sahil Tandon wrote: On Fri, 22 Jan 2010, Martijn de Munnik wrote: RFC2821 section 4.5.3.2 Timeouts reads An SMTP server SHOULD have a timeout of at least 5 minutes while it is awaiting the next command from the sender. The key word is SHOULD, as opposed to MUST. SHOULD equals MUST unless you have a really good reason. I'm trying to figure out if somebody on the list knows a really good reason. *yawn*. Perhaps you will benefit from repetition: ask their postmaster, as I advised in my initial response and others have since echoed. -- Sahil Tandon sa...@tandon.net
Re: Putting $data_directory on a RAM filesystem
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? -- 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: smtp auth over ssl for smartrelay configuration
Jelle de Jong wrote: Victor Duchovni wrote, on 23-01-10 17:48: On Sat, Jan 23, 2010 at 05:31:47PM +0100, Jelle de Jong wrote: postconf -e 'smtp_tls_security_level = encrypt' Is this SMTP client going to send all mail to a small set of TLS enabled relay hosts? Or are you choosing to not be able to send any email to the vast majority of domains whose MX hosts don't offer TLS? The system is a satellite system that is only sending mail to one secure mail server, the mailrelay is only affable for smtp auth over ssl. the hostname of the sender will fail every sane check if it sent to other machines, because it has no fixed ip, and is behind a series of nat's. postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1' Why disable both SSLv2 and TLSv1?! Leave this setting at its default value, or disable just SSLv2. Does your client or server correctly handle SSLv3, but fail to interoperate via TLSv1? Well my server supports SSLv3 just fine, so I thought I disable everything lower, and if better protocols come around postfix will update and will still be able to use the newer stuff since I did not force it to only use SSLv3. TLSv1 is newer stuff.
Re: Timeout of SMTP servers
On Jan 23, 2010, at 9:17, Martijn de Munnik mart...@youngguns.nl wrote: SHOULD equals MUST unless you have a really good reason. I'm trying to figure out if somebody on the list knows a really good reason. There is no really good reason for a 3 second timeout in a public server. There are really good reason for having a timeout less than 5 minutes though.
Re: smtp auth over ssl for smartrelay configuration
On Sat, Jan 23, 2010 at 05:59:37PM +0100, Jelle de Jong wrote: postconf -e 'smtp_tls_mandatory_protocols = !SSLv2, !TLSv1' Why disable both SSLv2 and TLSv1?! Leave this setting at its default value, or disable just SSLv2. Does your client or server correctly handle SSLv3, but fail to interoperate via TLSv1? Well my server supports SSLv3 just fine, so I thought I disable everything lower, and if better protocols come around postfix will update and will still be able to use the newer stuff since I did not force it to only use SSLv3. The default settings for advanced TLS features were chosen with care. It is unwise to change them unless you are a TLS expert. TLSv 1.0 is SSL 3.1. TLS 1.1 is SSL 3.2, ... There is no plan for TLSv2 at this time, but it would be SSL version 4. Don't change advanced TLS settings until you have read the relevant OpenSSL documentation and/or RFCs and in some cases the OpenSSL source code (sadly OpenSSL documentation is not as complete as the Postfix documentation). -- 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: Putting $data_directory on a RAM filesystem
Stefan Foerster: 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)? Sure, but why do you expect that it will be FASTER? Are you perhaps running a busy mail server off a single disk drive? In that case, splitting the load over multiple drives would make a big difference. Is perhaps your system slow because of swapping? In that case, using tmpfs will make the system swap even more. Instead, even reducing the process count by 20% could result in a big over-all improvement. I haven't seen any attempt at a quantitative analysis of the problem, so I won't speculate further. Wietse
Re: Putting $data_directory on a RAM filesystem
Stefan Foerster put forth on 1/23/2010 11:08 AM: 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)? I know about RAM not being persistent across reboots, and I understand what happens if the $postscreen_cache_map (or all the contents in $data_directory) are lost. If the problem is due to an I/O bottleneck, I'd recommend going SSD instead of RAM disk. Get this Crucial 64GB SATA2 unit and put both the postfix spool and postscreen db files on it: http://www.newegg.com/Product/Product.aspx?Item=N82E16820148318 Or, like Wietse said, first identify the actual cause of the problem. Then if it's I/O related, get an SSD drive. It's a relatively cheap path to massive random I/O throughput. -- Stan
451 4.3.0 Error: queue file write error
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. Is there any patches or hot fixes that actually work? I have Postfix 9.3.0 and the 451 error is still not fixed. Shawn Fee SGF IT Solutions, LLC | IT Manager 813.817.8706 mailto:s...@sgfitsolutions.com s...@sgfitsolutions.com image002.jpg
