Re: Disable outbound smtp pipelining?
* Curtis postfixu...@isparks.com: It seems we are running into an increased number of hosts that have broken smtp pipelining. We are able to resolve delivery issues to these hosts using the solution that Wieste recommended a couple weeks ago: http://www.mail-archive.com/postfix-users@postfix.org/msg44135.html However, I'm not sure I fully understand why this fixes the problem for outbound email. On outbound email, Postfix is acting as the client and therefore one might think that smtpd_discard_ehlo_keyword_address_maps would not have any affect, This links lists smtp_discard_ehlo_keyword_address_maps (no d) not smtpd_discard_ehlo_keyword_address_maps -- 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
client-side authentication broken?
Hi, I recently upgraded a machine from Postfix 2.8 to 2.9. The machine uses, amongst other things, a custom transport to facilitate masking outgoing email addresses and sending with SMTP-AUTH. In main.cf, this looks like follows: mtp_sasl_auth_enable = yes smtp_sender_dependent_authentication = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_security_level = encrypt smtp_sasl_security_options = noanonymous In master.cf I now have this in attempt to fix this problem: globalout unix - - - - - smtp -v -v -o smtp_generic_maps=hash:/etc/postfix/global_rewrite -o smtp_sasl_auth_enable=yes -o smtp_sender_dependent_authentication=yes -o smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd -o smtp_tls_security_level=encrypt -o smtp_sasl_security_options=noanonymous where globalout is the mail transport used for off-site mails. For some reason, that stopped working: I can't see an authentication attempt on the server side, only a plain TLS connection and then an attempt to push out the email. I'd really like to get this back into working order... suggestions are welcome! TIA! Kind regards, --Toni++
Re: Sending mail to custom transport and second server
- Original Message - From: Jeroen Geilman jer...@adaptr.nl To: postfix-users@postfix.org Sent: Tuesday, 5 June, 2012 7:51:47 PM Subject: Re: Sending mail to custom transport and second server recipient_bcc_maps = hash:/etc/postfix/backup_domains, with the following content: @example.netcatch...@second.postfix.box Depending on your specific setup, there may be much better solutions, but this is what you asked for verbatim. Actually, this is not really what I meant. This BCCs everything to one e-mail address. What I would like, is to have a transport with two nexthops, so to speak. I need the primary server to deliver to its zarafa transport as well as relay to the secondary server. The secondary server then knows to which address it was sent and places the X-Original-To and Delivered-To.
Re: client-side authentication broken?
On Jun 6, 2012, at 13:16, Toni Mueller wrote: I recently upgraded a machine from Postfix 2.8 to 2.9. The machine uses, amongst other things, a custom transport to facilitate masking outgoing email addresses and sending with SMTP-AUTH. In main.cf, this looks like follows: mtp_sasl_auth_enable = yes Is the above a typo in your configuration, or a copy-paste error? Because it should have an 's' in front of it? Cya, Jona -- smtp_sender_dependent_authentication = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_tls_security_level = encrypt smtp_sasl_security_options = noanonymous In master.cf I now have this in attempt to fix this problem: globalout unix - - - - - smtp -v -v -o smtp_generic_maps=hash:/etc/postfix/global_rewrite -o smtp_sasl_auth_enable=yes -o smtp_sender_dependent_authentication=yes -o smtp_sasl_password_maps=hash:/etc/postfix/sasl_passwd -o smtp_tls_security_level=encrypt -o smtp_sasl_security_options=noanonymous where globalout is the mail transport used for off-site mails. For some reason, that stopped working: I can't see an authentication attempt on the server side, only a plain TLS connection and then an attempt to push out the email. I'd really like to get this back into working order... suggestions are welcome! TIA! Kind regards, --Toni++
Re: Disable outbound smtp pipelining?
Curtis: smtp_discard_ehlo_keywords = pipelining,silent-discard (Again, this time without the d.) Aside from a little extra bandwidth, would this cause outbound deliveries to go horrendously slower on a busy mail server? The issue is NOT bandwidth (i.e. the width of a pipe). It's latency (i.e. the distance between pipe endpoints). You can increase the former, but you can't break the speed-of-light limit. Pipelining reduces the number of TCP round-trip times, At a minimum there will be 5 round-trip times (SYN-SYNACK, ACK-220, EHLO-EHLOREPLY, DATA-DATAREPLY, ENDOFDATA-ENDOFDATAREPLY; the SMTP client does not wait for final handshake completion). Disabling pipelining adds one round-trip time for each MAIL FROM and for each RCPT TO command, from 5 to 7 or more. Your SMTP server may spend 40% more time delivering mail, depending on the number of messages per destination (which reduces impact of DNS lookups), and on the number of recipients per message. Postfix has bug workarounds for CISCO PIX that are enabled automatically when mail has been queued for 500s ore more. Maybe some of the optimizations such as command pipelining could also be made time-dependent. Wietse
Re: Disable outbound smtp pipelining?
On 6/6/2012 8:45 AM, Wietse Venema wrote: Curtis: smtp_discard_ehlo_keywords = pipelining,silent-discard (Again, this time without the d.) Aside from a little extra bandwidth, would this cause outbound deliveries to go horrendously slower on a busy mail server? The issue is NOT bandwidth (i.e. the width of a pipe). It's latency Yeah, I realized that the bandwidth impact would be minimal. (Someone else noted in another thread a slight increase of bandwidth due to the extra TCP round-trips.) (i.e. the distance between pipe endpoints). You can increase the former, but you can't break the speed-of-light limit. Pipelining reduces the number of TCP round-trip times, At a minimum there will be 5 round-trip times (SYN-SYNACK, ACK-220, EHLO-EHLOREPLY, DATA-DATAREPLY, ENDOFDATA-ENDOFDATAREPLY; the SMTP client does not wait for final handshake completion). Disabling pipelining adds one round-trip time for each MAIL FROM and for each RCPT TO command, from 5 to 7 or more. Your SMTP server may spend 40% more time delivering mail, depending on the number of messages per destination (which reduces impact of DNS lookups), and on the number of recipients per message. Yeah, I figured it would be a pretty significant slow down for hosts that support it... I just wasn't sure what percentage of hosts support pipelining. If only 10% of hosts were using it in the first place, the 40% extra delivery time lost on those hosts might be managable... but, if you're saying that the majority of hosts do have pipelining enabled (it makes sense that they would), then a 40% slow down would probably be too expensive. Postfix has bug workarounds for CISCO PIX that are enabled automatically when mail has been queued for 500s ore more. Maybe some of the optimizations such as command pipelining could also be made time-dependent. That would be awesome. I will stay tuned for that. In the mean time, it sounds like we'll have to stick with the smtp_discard_ehlo_keyword_address_maps solution. We'll just have to set up something to monitor the logs and automatically add problem hosts. I love how there's almost always multiple ways to solve a problem with Postfix. Postfix rocks! :-) Curtis Wietse
Different smtpd_client_restrictions policies for different recipient domains ?
Scratching my head on whether this is possible: I suppose I want to do something like a database 'join' in my Postfix setup. e.g. enforce this check_client_access rule if and only if the recipient is in one of the following domains... This has arisen because we use MXLogic to filter inbound email, but only for a subset of the domains we're hosting. MXLogic works by pointing the domain MX record at their servers, which then relay/proxy to our Postfix. Spammers figure out how to bypass the filtering by delivering directly to the Postfix server (presumably they spot that mail.foo.com points to a machine that accepts connections on port 25 and delivery for foo.com). The way to thwart this filter bypass traffic is to deny local delivery to clients that are not on MXLogic's subnets. This is easy to do with a check_client_access directive and a cidr table. But if there are some domains hosted that are not subject to MXLogic filtering (their spam filtering is done MUA-side), a global check_client_access rule won't work because it will deny local delivery to legitimate MTA traffic for those domains. Hence the desire to make the subnet restriction domain-specific. What's the best way to implement this ? I think restriction classes are the way to go , but I'm not 100% sure. Any pointers appreciated. Thanks.
Re: Different smtpd_client_restrictions policies for different recipient domains ?
On Wed, Jun 06, 2012 at 09:15:55AM -0600, David Boreham wrote: [How to apply a restriction at some connections only?] What's the best way to implement this ? I think restriction classes are the way to go , but I'm not 100% sure. They are exactly the way to go. See here: http://www.postfix.org/RESTRICTION_CLASS_README.html Dennis
Re: Sending mail to custom transport and second server
Jeroen Geilman: @example.netcatch...@second.postfix.box Depending on your specific setup, there may be much better solutions, but this is what you asked for verbatim. Wiebe Cazemier: Actually, this is not really what I meant. This BCCs everything to one e-mail address. What I would like, is to have a transport with two nexthops, so to speak. I need the primary server to deliver to its zarafa transport as well as relay to the secondary server. The secondary server then knows to which address it was sent and places the X-Original-To and Delivered-To. That functionality is provided by the pcre-based sender_bcc_maps solution - it makes one secondary delivery for each recipient. I guess by now we have covered all options available in existing Postfix releases. Wietse
Re: mynetworks support for ipv6 link local (fe80) hosts
Derek Atkins: Wietse Venema wie...@porcupine.org writes: For the record: mynetworks has always supported net/mask notation. Of course, but that wasn't what I was talking about, and it never was. I was talking about permit_mynetworks working properly with an ipv6 link local address specified in mynetworks, and *that* wasn't working due the extraneous %eth0 in the address from the Linux AddrToString functions. You stated that (permit)mynetworks should support link-local suffixes (they never did, and to this date thet don't). Instead, when I learned that such suffixes crept into Postfix via non-Postfix library routines, I added code to strip them. Wietse
Re: Disable outbound smtp pipelining?
Curtis: Yeah, I figured it would be a pretty significant slow down for hosts that support it... I just wasn't sure what percentage of hosts support pipelining. If only 10% of hosts were using it in the first place, the 40% extra delivery time lost on those hosts might be managable... but, if you're saying that the majority of hosts do have pipelining enabled (it makes sense that they would), then a 40% slow down would probably be too expensive. I have no statistics for ESMTP PIPELINING deployment. Many major MTA implementation support this, but unfortunately some security firewall implementors still make basic mistakes, and that is probably what we are looking at. Wietse
Re: client-side authentication broken?
Hi, On Wed, Jun 06, 2012 at 03:43:21PM +0200, DTNX Postmaster wrote: On Jun 6, 2012, at 13:16, Toni Mueller wrote: In main.cf, this looks like follows: mtp_sasl_auth_enable = yes Is the above a typo in your configuration, or a copy-paste error? Because it should have an 's' in front of it? thanks for pointing this out. It's a copypaste error. The file really has the 's' where it belongs. Kind regards, --Toni++
Re: Disable outbound smtp pipelining?
On Wed, Jun 06, 2012 at 03:24:41PM -0400, Wietse Venema wrote: Curtis: Yeah, I figured it would be a pretty significant slow down for hosts that support it... I just wasn't sure what percentage of hosts support pipelining. If only 10% of hosts were using it in the first place, the 40% extra delivery time lost on those hosts might be managable... but, if you're saying that the majority of hosts do have pipelining enabled (it makes sense that they would), then a 40% slow down would probably be too expensive. I have no statistics for ESMTP PIPELINING deployment. Many major MTA implementation support this, but unfortunately some security firewall implementors still make basic mistakes, and that is probably what we are looking at. Wietse Hi Wietse, I really like your idea about a time-based fallback to a no-pipelining send similar to the Cisco PIX work-around. Regards, Ken
Thunderbird and Postfix
Hi everyone! I'm new to this list and the reason why I'm writing is because I found out one thing I think is worrying enough to share it with you I've got my Postfix configured with virtual users, integrated with Dovecot. Everything's working fine, no (known) configuration issues. I was mainly investigating on my Mozilla Thunderbird, concretely the Identities option. I tried to add an 'identity' (with a fictional login), just to try what would happen and surprisingly the mail was sent out without any problem - using the configuration of the 'real' account: Jun 6 21:23:35 mail postfix/smtpd[13009]: 3035F1C: client=unknown[192.168.0.10], sasl_method=PLAIN, sasl_username=nico...@devels.es Jun 6 21:23:35 mail postfix/cleanup[13017]: 3035F1C: message-id=4fcfbc49.60...@devels.es Jun 6 21:23:35 mail postfix/qmgr[1766]: 3035F1C: from=fictio...@devels.es, size=651, nrcpt=1 (queue active) Jun 6 21:23:35 mail postfix/smtpd[13009]: disconnect from unknown[192.168.0.10] Jun 6 21:23:37 mail postfix/pickup[12624]: 28C801012C0: uid=5002 from=fictio...@devels.es Jun 6 21:23:37 mail postfix/cleanup[13017]: 28C801012C0: message-id=4fcfbc49.60...@devels.es Jun 6 21:23:37 mail postfix/pipe[13019]: 3035F1C: to=nico...@devels.es, relay=spamassassin, delay=2.1, delays=0.25/0.05/0/1.8, dsn=2.0.0, status=sent (delivered via spamassassin service) Jun 6 21:23:37 mail postfix/qmgr[1766]: 3035F1C: removed My question is: How 'safe' is this? Is there any way to restrict creating identities for users unless the administrator allows to do so? I really would be worried if ANY user would create ANY identities and use them the way he wants... Any ideas appreciated! Thanks! Nicolás
Re: Thunderbird and Postfix
* Nicolás nico...@devels.es: I'm new to this list and the reason why I'm writing is because I found out one thing I think is worrying enough to share it with you I've got my Postfix configured with virtual users, integrated with Dovecot. Everything's working fine, no (known) configuration issues. I was mainly investigating on my Mozilla Thunderbird, concretely the Identities option. I tried to add an 'identity' (with a fictional login), just to try what would happen and surprisingly the mail was sent out without any problem - using the configuration of the 'real' account: Jun 6 21:23:35 mail postfix/smtpd[13009]: 3035F1C: client=unknown[192.168.0.10], sasl_method=PLAIN, sasl_username=nico...@devels.es Jun 6 21:23:35 mail postfix/cleanup[13017]: 3035F1C: message-id=4fcfbc49.60...@devels.es Jun 6 21:23:35 mail postfix/qmgr[1766]: 3035F1C: from=fictio...@devels.es, size=651, nrcpt=1 (queue active) Jun 6 21:23:35 mail postfix/smtpd[13009]: disconnect from unknown[192.168.0.10] Jun 6 21:23:37 mail postfix/pickup[12624]: 28C801012C0: uid=5002 from=fictio...@devels.es Jun 6 21:23:37 mail postfix/cleanup[13017]: 28C801012C0: message-id=4fcfbc49.60...@devels.es Jun 6 21:23:37 mail postfix/pipe[13019]: 3035F1C: to=nico...@devels.es, relay=spamassassin, delay=2.1, delays=0.25/0.05/0/1.8, dsn=2.0.0, status=sent (delivered via spamassassin service) Jun 6 21:23:37 mail postfix/qmgr[1766]: 3035F1C: removed My question is: How 'safe' is this? Is there any way to restrict creating identities for users unless the administrator allows to do so? I really would be worried if ANY user would create ANY identities and use them the way he wants... Any ideas appreciated! SASL in Postfix authenticates identities. It is up to Postfix to authorize a known identity to do something. Currently Postfix can do two things for authenticated identities: 1. Permit identity to relay 2. Permit identity to use one or more envelope senders You have only configured use case 1. Read into smtpd_sender_login_maps to setup and configure use case 2 also. p@rick Thanks! Nicolás -- All technical questions asked privately will be automatically answered on the list and archived for public access unless privacy is explicitely required and justified. saslfinger (debugging SMTP AUTH): http://postfix.state-of-mind.de/patrick.koetter/saslfinger/
Re: Thunderbird and Postfix
El 06/06/2012 22:25, Patrick Ben Koetter escribió: * Nicolásnico...@devels.es: I'm new to this list and the reason why I'm writing is because I found out one thing I think is worrying enough to share it with you I've got my Postfix configured with virtual users, integrated with Dovecot. Everything's working fine, no (known) configuration issues. I was mainly investigating on my Mozilla Thunderbird, concretely the Identities option. I tried to add an 'identity' (with a fictional login), just to try what would happen and surprisingly the mail was sent out without any problem - using the configuration of the 'real' account: Jun 6 21:23:35 mail postfix/smtpd[13009]: 3035F1C: client=unknown[192.168.0.10], sasl_method=PLAIN, sasl_username=nico...@devels.es Jun 6 21:23:35 mail postfix/cleanup[13017]: 3035F1C: message-id=4fcfbc49.60...@devels.es Jun 6 21:23:35 mail postfix/qmgr[1766]: 3035F1C: from=fictio...@devels.es, size=651, nrcpt=1 (queue active) Jun 6 21:23:35 mail postfix/smtpd[13009]: disconnect from unknown[192.168.0.10] Jun 6 21:23:37 mail postfix/pickup[12624]: 28C801012C0: uid=5002 from=fictio...@devels.es Jun 6 21:23:37 mail postfix/cleanup[13017]: 28C801012C0: message-id=4fcfbc49.60...@devels.es Jun 6 21:23:37 mail postfix/pipe[13019]: 3035F1C: to=nico...@devels.es, relay=spamassassin, delay=2.1, delays=0.25/0.05/0/1.8, dsn=2.0.0, status=sent (delivered via spamassassin service) Jun 6 21:23:37 mail postfix/qmgr[1766]: 3035F1C: removed My question is: How 'safe' is this? Is there any way to restrict creating identities for users unless the administrator allows to do so? I really would be worried if ANY user would create ANY identities and use them the way he wants... Any ideas appreciated! SASL in Postfix authenticates identities. It is up to Postfix to authorize a known identity to do something. Currently Postfix can do two things for authenticated identities: 1. Permit identity to relay 2. Permit identity to use one or more envelope senders You have only configured use case 1. Read into smtpd_sender_login_maps to setup and configure use case 2 also. p@rick Thanks! Nicolás Thank you very much, Patrick. Now it works the way I described :-)) Nicolás
Re: Thunderbird and Postfix
Den 2012-06-06 23:05, Nicolás skrev: Jun 6 21:23:35 mail postfix/smtpd[13009]: 3035F1C: client=unknown[192.168.0.10], sasl_method=PLAIN, sasl_username=nico...@devels.es if sasl username is auth'ed there is no way to make sure From: does match it, but it will still be password checked with the password in dovecot login right ?, only thing postfix can do more is to ask for the password if sender is local, mostly when sender and recipient is equal (spammers try this route) From: is part of the body in mail sending so it can be filtered with header checks after sasl auth is passed :) but this filter must not being apply to incomming emails that returns from maillists, so its a bit unsecure to make a header filter for this
