Re: Case sensitive local user accounts
Randy Ramsdell skrev den 2013-01-08 00:15: What is the configuration forces postfix to honor what is found in virtual_alias_maps ? e.g. support@$domain.com LocalAccount virtual_alias_maps does not support localaccount if you like to use localaccount from outside, then send it to some other domain that is local only local in virtualalias supp...@example.org localuser@$mydestination.example.org then it will be delivered to unix user localuser keep in mind that example.org must not be listed in mydestination but only in virtual_domains_maps if its just for domains listed in mydestination use alias_maps with supports pipes, with is not supported in virtual
Re: destination_rate_delay and connection_reuse_time_limit
Hi Viktor, I've added this into my main.cf: slow_destination_concurrency_failed_cohort_limit = 5 But I noticed that even after a failure, postfix keeps trying to deliver to the destination. Question: how can I stop postfix from trying to deliver emails after few failures? I mean, if it is trying to deliver to xyz.com and it fails 5 times, should postfix keep trying to deliver or is there any way that we can stop delivering for some time? I thought this could be done using _destination_concurrency_failed_cohort_limit. Am I doing something wrong? After this adjustments I'm still having trouble to deliver emails to this specific destination. This is the error I get: said: 450 4.7.1 You've exceeded your sending limit to this domain. (in reply to end of DATA command)) I'm really trying to slow down the delivery speed in order to respect the destination's policies. I just can't figure out how to fix this issue. I've also sent more than 20 emails to network's administrator and they just won't answer. Reading on the internet I found out that there are a lot of people having the same problem with this specific provider. We send about 50k emails/day to 20k domains hosted on this provider that are being blocked. Any help would be very appreciated. Thanks in advance. Att. -- Rafael Azevedo | IAGENTE Fone: 51 3086.0262 MSN: raf...@hotmail.com Visite: www.iagente.com.br Em 07/01/2013, às 15:57, Viktor Dukhovni escreveu: > slow_destination_concurrency_failed_cohort_limit
Re: destination_rate_delay and connection_reuse_time_limit
Rafael Azevedo - IAGENTE: [ Charset ISO-8859-1 unsupported, converting... ] > Hi Viktor, > > I've added this into my main.cf: > > slow_destination_concurrency_failed_cohort_limit = 5 This stops deliveries after 5 COHORT failures. > I mean, if it is trying to deliver to xyz.com and it fails 5 times, Yes, but you configured Postfix to stop after 5 COHORT failures. For more information about COHORT failures and other parameters: http://www.postfix.org/SCHEDULER_README.html Wietse
Re: destination_rate_delay and connection_reuse_time_limit
Wietse Venema: > Rafael Azevedo - IAGENTE: > > I've added this into my main.cf: > > > > slow_destination_concurrency_failed_cohort_limit = 5 > > This stops deliveries after 5 COHORT failures. > > > I mean, if it is trying to deliver to xyz.com and it fails 5 times, > > Yes, but you configured Postfix to stop after 5 COHORT failures. > > For more information about COHORT failures and other parameters: > > http://www.postfix.org/SCHEDULER_README.html In short, Postfix ONLY adjusts concurrency after connect/handshake failure, NEVER EVER for a 4XX reply to RCPT TO. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
Rafael Azevedo - IAGENTE: > Hi Witsie, > > Is there anyway we can adjust Postfix to stop delivering after a > 4XX reply? Postfix will stop delivering after TCP or SMTP handshake failure. Postfix WILL NOT stop delivering due to 4xx reply AFTER the SMTP protocol handshake. Postfix is not a tool to work around receiver policy restrictions. If you want to send more than a few email messages, then it is your responsibility to make the necessary arrangements with receivers. Over and out. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
On Tue, Jan 08, 2013 at 10:47:08AM -0200, Rafael Azevedo - IAGENTE wrote: > I've added this into my main.cf: > > slow_destination_concurrency_failed_cohort_limit = 5 This is fine, since you set the concurrency limit to 1, it is intended to avoid shutting down deliveries after a single connection failure. As Wietse points out this does not stop deliveries when individual recipients are rejected, that is not evidence of the site being down. > Question: how can I stop postfix from trying to deliver emails > after few failures? It is not possible to aumatically throttle deliveries based on 4XX replies to RCPT TO. This is not a useful signal that Postfix is sending "too fast", nor is there any good way to dynamically determine the correct rate. Sites that impose indiscriminate (assuming you're sending legitimate email, not spam) rate controls are breaking the email infrastructure. Sadly, the work-around is to snowshoe---deploy more servers to split the load over a larger number of IP addresses. > I mean, if it is trying to deliver to xyz.com and it fails 5 > times, should postfix keep trying to deliver or is there any way > that we can stop delivering for some time? Only if xyz.com is down, not if it is merely tempfailing RCPT TO. > This is the error I get: > said: 450 4.7.1 You've exceeded your sending limit to this domain. > (in reply to end of DATA command)) Since presumably at this point your connection rate is not high (connections are being re-used), it seems that they're imposing a message rate cap as well as a connection rate cap. Send them less email. > I'm really trying to slow down the delivery speed in order to > respect the destination's policies. I just can't figure out how to > fix this issue. > > We send about 50k emails/day to 20k domains hosted on this provider > that are being blocked. The output rate cannot on average fall below the input rate. The input rate is approximately 1/sec (there are 86400 seconds in a day). Thus the slowest you can send is with a rate delay" of 1s. If that's not slow enough, you're out of luck, and have to buy more servers (possibly deploying them on separate networks). The suggestion to turn off rate delays was based on an assumption that they told you to avoid connecting too often and wanted all the mail over a single connection (you wanted connection re-use), but connection re-use works best when there is no rate delay. A rate delay of 1s is still compatible with connection re-use, and is the largest you can specify and still send more than 43.2k messages a day. It may be simplest to outsource your traffic to an existing large bulk email operator. -- Viktor.
Re: Case sensitive local user accounts
On Tue, Jan 08, 2013 at 11:05:20AM +0100, Benny Pedersen wrote: > Randy Ramsdell skrev den 2013-01-08 00:15: > >What is the configuration forces postfix to honor what is found in > >virtual_alias_maps ? > > > >e.g. > > > >support@$domain.com LocalAccount > > virtual_alias_maps does not support localaccount This is a non-sequitur. The virtual alias table is an address rewriting table. It performs the requested rewrite. Virtual aliases apply to ALL recipient addresses regardless of the address class of the input address, and can rewrite to a target recipient address in any address class. -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
Thank you Witsie. We have a huge mail volume thats why I'm trying to figure out a better way to deal with it. Many providers have their own restrictions. We do work in compliance with most of them, but there are a few that just won't help at all, so its easy to tell me to make the necessary arrangements when they don't even have a support or abuse dept to get involved. So since the problem is in my hands, I must find out a way to deal with it. Trying to slow down delivery speed is one way to get through. I truly believe that postfix is the best MTA ever, but you might agree with me that when the receiver start blocking the sender, its worthless to keep trying to deliver. The safest way is to stop delivering to these servers and try again later. I just can't believe that postfix doesn't have a way to deal with it. It would make postfix much more efficient in delivery terms. Anyway, thanks for your time and all the help. It was for sure very appreciated. Any help here would also be appreciated. Thanks in advance. Att. -- Rafael Azevedo | IAGENTE Fone: 51 3086.0262 MSN: raf...@hotmail.com Visite: www.iagente.com.br Em 08/01/2013, às 12:09, Wietse Venema escreveu: > Rafael Azevedo - IAGENTE: >> Hi Witsie, >> >> Is there anyway we can adjust Postfix to stop delivering after a >> 4XX reply? > > Postfix will stop delivering after TCP or SMTP handshake failure. > Postfix WILL NOT stop delivering due to 4xx reply AFTER the SMTP > protocol handshake. > > Postfix is not a tool to work around receiver policy restrictions. > If you want to send more than a few email messages, then it is your > responsibility to make the necessary arrangements with receivers. > > Over and out. > > Wietse > >
Re: destination_rate_delay and connection_reuse_time_limit
Rafael Azevedo - IAGENTE: > I truly believe that postfix is the best MTA ever, but you might > agree with me that when the receiver start blocking the sender, > its worthless to keep trying to deliver. 1) Postfix will back off when the TCP or SMTP handshake fails. This is a clear signal that a site is unavailable. 2) Postfix will not back off after [54]XX in the middle of a session. IN THE GENERAL CASE this does not mean that the receiver is blocking the sender, and backing off would be the wrong strategy. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
But Witsei, would you agree with me that error 4XX is (in general cases) a temporary error? Why keep trying when we have a clear signal of a temporary error? Also, if we had a temporary error control (number of deferred messages by recipient), it would be easy to identify when postfix should stop trying at least for a while. Att. -- Rafael Azevedo | IAGENTE Fone: 51 3086.0262 MSN: raf...@hotmail.com Visite: www.iagente.com.br Em 08/01/2013, às 13:34, Wietse Venema escreveu: > Rafael Azevedo - IAGENTE: >> I truly believe that postfix is the best MTA ever, but you might >> agree with me that when the receiver start blocking the sender, >> its worthless to keep trying to deliver. > > 1) Postfix will back off when the TCP or SMTP handshake fails. This > is a clear signal that a site is unavailable. > > 2) Postfix will not back off after [54]XX in the middle of a session. > IN THE GENERAL CASE this does not mean that the receiver is blocking > the sender, and backing off would be the wrong strategy. > > Wietse
Re: destination_rate_delay and connection_reuse_time_limit
On Tue, Jan 08, 2013 at 01:59:14PM -0200, Rafael Azevedo - IAGENTE wrote: > But Witse, would you agree with me that error 4XX is (in general > cases) a temporary error? It is a temporary error for *that* recipient. It is not a global indication that the site is temporary unreachable. Nor is there any indication how long one should wait, nor that waiting will make things any better. Generally, delaying deliver *increases* congestion, since more mail arrives in the mean-time, and once delivery resumes the volume is even higher. > Why keep trying when we have a clear signal of a temporary error? Postfix does not "keep trying", it defers the message in question and moves on to the next one. Your mental model of email queue management is too naive. This is a very difficult problem, and there is no simple answer. > Also, if we had a temporary error control (number of deferred > messages by recipient), it would be easy to identify when postfix > should stop trying at least for a while. Given an arrival rate of ~50k msgs/day, you need to send at least 1 msg/sec to avoid growing an infinitely large queue. This is basic arithmetic. Gowing slower does not work, your queue grows without bound. Let the recipients know that if they want to continue to receive your email they should choose a new provider that is willing to work with legitimate senders to resolve mail delivery issues. Then stop sending them email. -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
Rafael Azevedo - IAGENTE: > Why keep trying when we have a clear signal of a temporary error? As Victor noted Postfix does not keep trying the SAME delivery. Instead, Postfix tries to deliver a DIFFERENT message. It would be incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site just because FIVE recipients were unavailable. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
Em 08/01/2013, às 14:21, Wietse Venema escreveu: > Rafael Azevedo - IAGENTE: >> Why keep trying when we have a clear signal of a temporary error? > > As Victor noted Postfix does not keep trying the SAME delivery. Yes you're right and I know that. But it keeps trying for another recipients in the same domain. Lets just say Yahoo starts blocking because of unusual traffic. Yahoo will keep telling "me" to try again later. In the mean time, new emails to be sent arrives and we never get the change to get unblocked. So postfix gets the next yahoo recipient and try to deliver without considering that yahoo does not want us to keep trying for a while. This is just an example. We don't have problem delivering to Yahoo, but to smaller providers. > > Instead, Postfix tries to deliver a DIFFERENT message. It would be > incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site > just because FIVE recipients were unavailable. Thats why it would be interesting to have a way to configure that. Lets say we have 100 deferred messages in sequence. Why keep trying? This way we loose time and processing, and have no way to improve reputation since we don't stop bugging them after they tell us to stop for a while. > > Wietse Anyway, it doesn't seem to be possible to do this. Thanks guys. Rafael.
Re: destination_rate_delay and connection_reuse_time_limit
Att. -- Rafael Azevedo | IAGENTE Fone: 51 3086.0262 MSN: raf...@hotmail.com Visite: www.iagente.com.br Em 08/01/2013, às 14:07, Viktor Dukhovni escreveu: > On Tue, Jan 08, 2013 at 01:59:14PM -0200, Rafael Azevedo - IAGENTE wrote: > >> But Witse, would you agree with me that error 4XX is (in general >> cases) a temporary error? > > It is a temporary error for *that* recipient. It is not a global > indication that the site is temporary unreachable. Nor is there > any indication how long one should wait, nor that waiting will make > things any better. Yes you're right. There is no indication of how long we should wait, thats why it would be very nice to have a parameter to determinate that (just like maximal_queue_lifetime) > > Generally, delaying deliver *increases* congestion, since more mail > arrives in the mean-time, and once delivery resumes the volume is > even higher. Thats exactly the problem. We have what I call as "mxcluster", which is a box with hundreds of postfix running, splitting the traffic between them. It helps but its not solving the major problem. > >> Why keep trying when we have a clear signal of a temporary error? > > Postfix does not "keep trying", it defers the message in question > and moves on to the next one. Your mental model of email queue > management is too naive. > > This is a very difficult problem, and there is no simple answer. Yes it tries the next message. But what about when it is to the same domain and also happens to get deferred? > >> Also, if we had a temporary error control (number of deferred >> messages by recipient), it would be easy to identify when postfix >> should stop trying at least for a while. > > Given an arrival rate of ~50k msgs/day, you need to send at least > 1 msg/sec to avoid growing an infinitely large queue. This is basic > arithmetic. Gowing slower does not work, your queue grows without > bound. Thats why we have multiple instances of postfix running, to split the traffic among them. > Let the recipients know that if they want to continue to receive > your email they should choose a new provider that is willing to > work with legitimate senders to resolve mail delivery issues. Then > stop sending them email. Yes and no. Some SMTPs get higher volumes of mail, but not the entire traffic centralized in only one smtp. > > -- > Viktor. Rafael
Re: destination_rate_delay and connection_reuse_time_limit
On 08/01/2013 16:38, Rafael Azevedo - IAGENTE wrote: Em 08/01/2013, às 14:21, Wietse Venema escreveu: Rafael Azevedo - IAGENTE: Why keep trying when we have a clear signal of a temporary error? As Victor noted Postfix does not keep trying the SAME delivery. Yes you're right and I know that. But it keeps trying for another recipients in the same domain. Which is absolutely the correct behaviour. One of the most common reasons for a temporary delivery failure is a full mailbox. Or, where the remote server is acting as a store-and-forward, a temporary inability to verify the validity of the destination address. I'd be very annoyed if I didn't get an email I was expecting because someone else on my system had forgotten to empty their mailbox, or because another customer of my upstream server had an outage and wasn't able to verify recipients. Mark -- Please take a short survey about the Leveson Report: http://meyu.eu/ak
Integration of content filter in master.cf
I'm a little unsure about best practice here, hence the question.
Running /usr/sbin/spamd from the SpamAssassin package to scan mail, I've
integrated it into /etc/postfix/master.cf with the following
lines
---
smtp inet n - n - - smtpd -o
content_filter=spamassassin
...
spamassassin unix - n n - - pipe
flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
-e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
---
And then in /etc/postfix/main.cf there's added the line
---
spamassassin_destination_recipient_limit = 1
---
However, this scans both incoming and outgoing mail, but for outgoing I
plan on using rate-limiting to avoid spamming the net (to much), in
case an account gets hacked.
So I searched the web, and constructed this alternative to use in
master.cf
---
26 inet n - n - - smtpd -o content_filter=spamassassin
smtp inet n - n - - smtpd
---
Using iptables, all incoming connections to port 25 could then be
directed to port 26. The server only have one ip-address.
The question then is, is this a practical solution, or can it be done
smarter, for example with less work and without using iptables, or
maybe some other way entirely?
Re: destination_rate_delay and connection_reuse_time_limit
Rafael Azevedo - IAGENTE: > > Instead, Postfix tries to deliver a DIFFERENT message. It would be > > incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site > > just because FIVE recipients were unavailable. > > Thats why it would be interesting to have a way to configure that. Configurable, perhaps. But it would a mistake to make this the default strategy. That would make Postfix vulnerable to a trivial denial of service attack where one bad recipient can block all mail for all other recipients at that same site. Imagine if I could block all mail for gmail.com in this manner. If I understand correctly, your proposal is to treat all 4xx and 5xx delivery errors the same as a failure to connect error. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
Am 08.01.2013 17:44, schrieb Mark Goodge: > On 08/01/2013 16:38, Rafael Azevedo - IAGENTE wrote: >> Em 08/01/2013, às 14:21, Wietse Venema >> escreveu: >> >>> Rafael Azevedo - IAGENTE: Why keep trying when we have a clear signal of a temporary error? >>> >>> As Victor noted Postfix does not keep trying the SAME delivery. >> >> Yes you're right and I know that. But it keeps trying for another >> recipients in the same domain. > > Which is absolutely the correct behaviour. > > One of the most common reasons for a temporary delivery failure is a full > mailbox. Or, where the remote server is > acting as a store-and-forward, a temporary inability to verify the validity > of the destination address. > > I'd be very annoyed if I didn't get an email I was expecting because someone > else on my system had forgotten to > empty their mailbox, or because another customer of my upstream server had an > outage and wasn't able to verify > recipients. yes that is all right for any "normal" mail but if you send out a newsletter you have likely a lot of users to big ISP's, Telekom Austria even rejects temporary for whitelisted senders since every smart admin spilts newsletter-relays from the normal business mail a configuration option would help while not hurt your case signature.asc Description: OpenPGP digital signature
Re: destination_rate_delay and connection_reuse_time_limit
Am 08.01.2013 17:48, schrieb Wietse Venema: > Rafael Azevedo - IAGENTE: >>> Instead, Postfix tries to deliver a DIFFERENT message. It would be >>> incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site >>> just because FIVE recipients were unavailable. >> >> Thats why it would be interesting to have a way to configure that. > > Configurable, perhaps. But it would a mistake to make this the > default strategy. > > That would make Postfix vulnerable to a trivial denial of service > attack where one bad recipient can block all mail for all other > recipients at that same site. > > Imagine if I could block all mail for gmail.com in this manner. > > If I understand correctly, your proposal is to treat all 4xx and > 5xx delivery errors the same as a failure to connect error. as i understand his proposal is if deliver to a configureable amount of RCPT's with the same destination server delay also the following targets with the same destination x minutes instead trigger another 100,200,300 4xx errors because the destination does not like mail from your IP for some time signature.asc Description: OpenPGP digital signature
Re: destination_rate_delay and connection_reuse_time_limit
> > One of the most common reasons for a temporary delivery failure is a full > mailbox. Or, where the remote server is acting as a store-and-forward, a > temporary inability to verify the validity of the destination address. I dont agree with that. Connection time out is the most common reason for temporary failure (in my case). > > I'd be very annoyed if I didn't get an email I was expecting because someone > else on my system had forgotten to empty their mailbox, or because another > customer of my upstream server had an outage and wasn't able to verify > recipients. Mark, I don't think that postfix should stop sending to that domain for ever or that it should send the email back to the sender. I just think that postfix could have a way to hold the mail queue for a specific time based on specific and consecutive errors. Lets say for example, 100 errors in sequence to the same destination domain. Why keep trying if we're unable to deliver to that domain at the time? > > Mark > -- > Please take a short survey about the Leveson Report: http://meyu.eu/ak Rafael
Re: destination_rate_delay and connection_reuse_time_limit
> Configurable, perhaps. But it would a mistake to make this the > default strategy. > > That would make Postfix vulnerable to a trivial denial of service > attack where one bad recipient can block all mail for all other > recipients at that same site. Not if it could me parametrized. As I said, what if we get 100 errors in sequence? Keep trying to deliver another 10k emails knowing that you're not allowed to send email at this time is more like a DoS attack. We're consuming server's resource when we shouldn't connect to them at all. > > Imagine if I could block all mail for gmail.com in this manner. > > If I understand correctly, your proposal is to treat all 4xx and > 5xx delivery errors the same as a failure to connect error. No thats not what I meant. What I said is that would be nice to have a way to configure specific errors to put the queue on hold for those destinations which we're unable to connect at the time. > > Wietse Rafael
Re: destination_rate_delay and connection_reuse_time_limit
Yes Reindl, you got the point. I just want to wait for a while before retrying to send email to the same destination. > Am 08.01.2013 17:48, schrieb Wietse Venema: >> Rafael Azevedo - IAGENTE: Instead, Postfix tries to deliver a DIFFERENT message. It would be incorrect IN THE GENERAL CASE to postpone ALL deliveries to a site just because FIVE recipients were unavailable. >>> >>> Thats why it would be interesting to have a way to configure that. >> >> Configurable, perhaps. But it would a mistake to make this the >> default strategy. >> >> That would make Postfix vulnerable to a trivial denial of service >> attack where one bad recipient can block all mail for all other >> recipients at that same site. >> >> Imagine if I could block all mail for gmail.com in this manner. >> >> If I understand correctly, your proposal is to treat all 4xx and >> 5xx delivery errors the same as a failure to connect error. > > as i understand his proposal is if deliver to a configureable > amount of RCPT's with the same destination server delay also > the following targets with the same destination x minutes > instead trigger another 100,200,300 4xx errors because the > destination does not like mail from your IP for some time >
Re: destination_rate_delay and connection_reuse_time_limit
On Tue, Jan 08, 2013 at 03:04:37PM -0200, Rafael Azevedo - IAGENTE wrote: > > Configurable, perhaps. But it would a mistake to make this the > > default strategy. > > > > That would make Postfix vulnerable to a trivial denial of service > > attack where one bad recipient can block all mail for all other > > recipients at that same site. > > Not if it could me parametrized. As I said, what if we get 100 errors > in sequence? Keep trying to deliver another 10k emails knowing that > you're not allowed to send email at this time is more like a DoS > attack. We're consuming server's resource when we shouldn't connect to > them at all. > > > > > Imagine if I could block all mail for gmail.com in this manner. > > > > If I understand correctly, your proposal is to treat all 4xx and > > 5xx delivery errors the same as a failure to connect error. > > No thats not what I meant. What I said is that would be nice to have > a way to configure specific errors to put the queue on hold for those > destinations which we're unable to connect at the time. Could you not just watch your logs and count temporary errors for each destination? The script could then reconfigure your mailtertable to point that domain to a hold transport (or even another box which is configured to send messages very slowly). After some amount of time passes, change back to the normal SMTP transport. I've never needed to do any such thing. But, I believe that would be possible without depending on changes to Postfix, which may not be not happen. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org
Re: destination_rate_delay and connection_reuse_time_limit
Rafael Azevedo - IAGENTE: > > > > Configurable, perhaps. But it would a mistake to make this the > > default strategy. > > > > That would make Postfix vulnerable to a trivial denial of service > > attack where one bad recipient can block all mail for all other > > recipients at that same site. > > Not if it could me parametrized. As I said, what if we get 100 > errors in sequence? Big deal. Now I can block all mail for gmail.com by getting 100 email messages into your queue. I could add an option to treat this in the same manner as "failure to connect" errors (i.e. temporarily skip all further delivery to this site). However, this must not be the default strategy, because this would hurt the far majority of Postfix sites which is not a bulk email sender. Currently, Postfix error processing distinguishes between (hard versus soft) errors, and between errors (during versus after) the initial protocol handshake. I don't have time to develop more detailed error processing strategies, especially not since this is of no benefit to the majority of the installed base. Wietse
Re: Integration of content filter in master.cf
On 1/8/2013 10:47 AM, Titanus Eramius wrote:
> I'm a little unsure about best practice here, hence the question.
>
> Running /usr/sbin/spamd from the SpamAssassin package to scan mail, I've
> integrated it into /etc/postfix/master.cf with the following
> lines
> ---
> smtp inet n - n - - smtpd -o
> content_filter=spamassassin
> ...
> spamassassin unix - n n - - pipe
>flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
> -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
> ---
>
> And then in /etc/postfix/main.cf there's added the line
> ---
> spamassassin_destination_recipient_limit = 1
> ---
>
> However, this scans both incoming and outgoing mail, but for outgoing I
> plan on using rate-limiting to avoid spamming the net (to much), in
> case an account gets hacked.
>
> So I searched the web, and constructed this alternative to use in
> master.cf
> ---
> 26 inet n - n - - smtpd -o content_filter=spamassassin
> smtp inet n - n - - smtpd
> ---
>
> Using iptables, all incoming connections to port 25 could then be
> directed to port 26. The server only have one ip-address.
>
> The question then is, is this a practical solution, or can it be done
> smarter, for example with less work and without using iptables, or
> maybe some other way entirely?
>
Using iptables to separate traffic is a reasonable solution.
Probably a good idea to add a comment to master.cf documenting what
you've done.
The more typical way to do this is for local mail to use the
submission port 587. Sometimes folks redirect port 25 on the local
network to 587 as a migration aid.
-- Noel Jones
Re: destination_rate_delay and connection_reuse_time_limit
Am 08.01.2013 19:08, schrieb Wietse Venema: > Rafael Azevedo - IAGENTE: >> >> >>> Configurable, perhaps. But it would a mistake to make this the >>> default strategy. >>> >>> That would make Postfix vulnerable to a trivial denial of service >>> attack where one bad recipient can block all mail for all other >>> recipients at that same site. >> >> Not if it could me parametrized. As I said, what if we get 100 >> errors in sequence? > > Big deal. Now I can block all mail for gmail.com by getting 100 > email messages into your queue how comes? how do you get gmail.com answer to any delivery from you with 4xx? if it is becasue the 100 messages you are already done because they reject still your messages and if the otehr side has some greylisting-like rules to reject messages from you as long there are not at least 5 minutes without anotehr connection it is even easier to block you with the current behavior by sending one message per minute after the treshhold is reached the first time because you will never go under the 5 minutes signature.asc Description: OpenPGP digital signature
Re: destination_rate_delay and connection_reuse_time_limit
On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote: > I could add an option to treat this in the same manner as "failure > to connect" errors (i.e. temporarily skip all further delivery to > this site). However, this must not be the default strategy, because > this would hurt the far majority of Postfix sites which is not a > bulk email sender. Such a feedback mechanism is a sure-fire recipe for congestive collapse: - A brief spike in traffic above the steady input rate cases the message-rate to trigger rate limits at the remote destination. - Postfix throttles to the destination for many minutes. - A lot of additional mail arrives while the destination is throttled. - When the queue is unthrottled, the message rate will immediately spike above the remote limit. And the queue is throttled. - Lather, rinse, repeat The *only* way to deal with rate limits, is to avoid traffic spikes, which is only possible if you also avoid traffic troughs, and send at a *steady* rate that is *below* the remote limit, but above the input rate. When the steady-state input rate is above the remote limit, no scheduler strategy can avoid congestive collapse. For remote sites that enforce indiscriminate rate limits (for all senders, not just those who have a history of reported spam), the only strategy is to: - Send below the rate that triggers the rate-limit - Buy more machines, and hope that rate limits are per sending IP, not per sending domain. (showshoe). - In some cases, the rate limits are reputation dependent, and it takes time to "build" a good reputation. In that case one needs to ramp traffic to the domain over time, by generating less mail intially, and building volume over time. This is done outside of the MTA, in the mail generating engine. Thinking that delaying sending is a good idea is dead wrong. The optimal strategy is to always send as fast as possible and no faster! -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
Reindl Harald: > > Big deal. Now I can block all mail for gmail.com by getting 100 > > email messages into your queue > > how comes? > how do you get gmail.com answer to any delivery from you with 4xx? He wants to temporarily suspend delivery when site has 5 consecutive delivery errors without distinguishing between SMTP protocol stages (such an "ignore protocol stage" switch could be added to Postfix). To implement a trivial DOS, I need 5 consecutive messages in his mail queue, plus a handful accounts that don't accept mail. I have no idea where he got the 100 from - that number was not part of his original problem description. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
Am 08.01.2013 20:16, schrieb Wietse Venema: > Reindl Harald: >>> Big deal. Now I can block all mail for gmail.com by getting 100 >>> email messages into your queue >> >> how comes? >> how do you get gmail.com answer to any delivery from you with 4xx? > > He wants to temporarily suspend delivery when site has 5 consecutive > delivery errors without distinguishing between SMTP protocol stages > (such an "ignore protocol stage" switch could be added to Postfix). > > To implement a trivial DOS, I need 5 consecutive messages in his > mail queue, plus a handful accounts that don't accept mail. > > I have no idea where he got the 100 from - that number was not part > of his original problem description the 100 was out in the game by yourself :-) however, it would make sense to delay the next try to as example @aon.at after 10,20,30 4xx errors while send out a newsletter and re-start try to deliver this messages 5,10,15 minutes later on the other hand: if you do not see snse here and are not willing to spend time in this idea -> postfix is your baby and still one of the greatest pieces of software i was allowed to use in many years and we will not die if you reject the feature wish signature.asc Description: OpenPGP digital signature
Re: Integration of content filter in master.cf
On Jan 8, 2013, at 19:39, Noel Jones wrote: > On 1/8/2013 10:47 AM, Titanus Eramius wrote: >> I'm a little unsure about best practice here, hence the question. >> >> Running /usr/sbin/spamd from the SpamAssassin package to scan mail, I've >> integrated it into /etc/postfix/master.cf with the following >> lines [snip] >> The question then is, is this a practical solution, or can it be done >> smarter, for example with less work and without using iptables, or >> maybe some other way entirely? > > Using iptables to separate traffic is a reasonable solution. > Probably a good idea to add a comment to master.cf documenting what > you've done. > > The more typical way to do this is for local mail to use the > submission port 587. Sometimes folks redirect port 25 on the local > network to 587 as a migration aid. This. Using the submission port is highly recommended, as it avoids all kinds of trouble, such as access providers blocking port 25. It also allows you to tailor each service to its specific needs; postscreen on 25, required authentication plus TLS and rate limiting on 587, and so on. HTH, Jona
Re: destination_rate_delay and connection_reuse_time_limit
Viktor Dukhovni: > On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote: > > > I could add an option to treat this in the same manner as "failure > > to connect" errors (i.e. temporarily skip all further delivery to > > this site). However, this must not be the default strategy, because > > this would hurt the far majority of Postfix sites which is not a > > bulk email sender. > > Such a feedback mechanism is a sure-fire recipe for congestive > collapse: That depends on their average mail input rate. As long as they can push out the mail from one input burst before the next input burst happens, then it may be OK that the output flow stutters sometimes. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote: > Viktor Dukhovni: > > On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote: > > > > > I could add an option to treat this in the same manner as "failure > > > to connect" errors (i.e. temporarily skip all further delivery to > > > this site). However, this must not be the default strategy, because > > > this would hurt the far majority of Postfix sites which is not a > > > bulk email sender. > > > > Such a feedback mechanism is a sure-fire recipe for congestive > > collapse: > > That depends on their average mail input rate. As long as they can > push out the mail from one input burst before the next input burst > happens, then it may be OK that the output flow stutters sometimes. This is most unlikely. The sample size before the remote side clamps down is likely small, so the effective throughput per throttle interval will be very low. If Postfix backs off initially for 5 minutes, it will fully drain the active queue to deferred, then get a handfull of messages through, then backoff for 10 minutes (doubling each time up to the maximal_backoff_time). This won't push out 50k messages/day. The optimal strategy is too send each message as quickly as possible, but not faster than the remote rate limit, i.e. tune the rate delay. Perhaps we need to measure the rate delay in tenths of seconds for a bit more flexibility. One can imagine adding a feedback mechanism to the rate delay (with fractional positive/negative feedback), but getting a stable algorithm out of this is far from easy. Throttling the active queue is not an answer. With rate limits, one wants to slow down, not stop, but throttling is not "slowing down". Barring a clean "slow down" signal, and a stable feedback mechanism, the only strategy is manually tuned rate delays, and spreading the load over multiple sending IPs (Postfix instances don't help if they share a single IP). -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
Am 08.01.2013 20:51, schrieb Viktor Dukhovni: > On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote: > >> Viktor Dukhovni: >>> On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote: >>> I could add an option to treat this in the same manner as "failure to connect" errors (i.e. temporarily skip all further delivery to this site). However, this must not be the default strategy, because this would hurt the far majority of Postfix sites which is not a bulk email sender. >>> >>> Such a feedback mechanism is a sure-fire recipe for congestive >>> collapse: >> >> That depends on their average mail input rate. As long as they can >> push out the mail from one input burst before the next input burst >> happens, then it may be OK that the output flow stutters sometimes. > > This is most unlikely. The sample size before the remote side clamps > down is likely small, so the effective throughput per throttle > interval will be very low. > > If Postfix backs off initially for 5 minutes, it will fully drain > the active queue to deferred, then get a handfull of messages > through, then backoff for 10 minutes (doubling each time up to the > maximal_backoff_time). This won't push out 50k messages/day you missed the PER DESTINATION * not "initially" * not globally * after CONFIGUREABLE temporary messages to the same destination on a dedicated MTA for newsletters it would even improve in many cass the amount of messages per day and your whole rputation of the ip-address you are sending from on a NORMAL mailserver with human senders it would make no sense thats why such thing must not be default but would be nice to have signature.asc Description: OpenPGP digital signature
Re: destination_rate_delay and connection_reuse_time_limit
Viktor Dukhovni: > On Tue, Jan 08, 2013 at 02:39:17PM -0500, Wietse Venema wrote: > > Viktor Dukhovni: > > > On Tue, Jan 08, 2013 at 01:08:21PM -0500, Wietse Venema wrote: > > > > > > > I could add an option to treat this in the same manner as "failure > > > > to connect" errors (i.e. temporarily skip all further delivery to > > > > this site). However, this must not be the default strategy, because > > > > this would hurt the far majority of Postfix sites which is not a > > > > bulk email sender. > > > > > > Such a feedback mechanism is a sure-fire recipe for congestive > > > collapse: Given that sites will tempfail a delivery attempt to signal a "stay away" condition, it makes sense to provide an option for bulkmailers to treat those responses accordingly. That does not mean that this option will be sufficient to solve all mail delivery problems. Some parts will require human intervention. The "stay away" condition is similar to "failure to connect", except that one might want to use different timers. With "failure to connect" the timer choice depends more on sender preferences, while with "failure to deliver" the timer choice would depend more on the destination. Coming to the issue of receiver's limits: when receivers slam hard on the brakes, I don't see how Postfix could automatically tune the delivery rate (as a fictitious example, suppose that a transgression results in a 30-minute penalty during which no mail will be accepted from the client IP address). My conclusion is that Postfix can continue to provide basic policies that avoid worst-case failure modes, but the choice of the settings that control those policies is better left to the operator. If the receiver slams on the brakes, then Postfix can suspend deliveries, but the sender operator will have to adjust the sending rate. Wietse
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones
:
> On 1/8/2013 10:47 AM, Titanus Eramius wrote:
> > I'm a little unsure about best practice here, hence the question.
> >
> > Running /usr/sbin/spamd from the SpamAssassin package to scan mail,
> > I've integrated it into /etc/postfix/master.cf with the following
> > lines
> > ---
> > smtp inet n - n - - smtpd -o
> > content_filter=spamassassin
> > ...
> > spamassassin unix - n n - - pipe
> >flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
> > -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
> > ---
> >
> > And then in /etc/postfix/main.cf there's added the line
> > ---
> > spamassassin_destination_recipient_limit = 1
> > ---
> >
> > However, this scans both incoming and outgoing mail, but for
> > outgoing I plan on using rate-limiting to avoid spamming the net
> > (to much), in case an account gets hacked.
> >
> > So I searched the web, and constructed this alternative to use in
> > master.cf
> > ---
> > 26 inet n - n - - smtpd -o
> > content_filter=spamassassin smtp inet n - n - - smtpd
> > ---
> >
> > Using iptables, all incoming connections to port 25 could then be
> > directed to port 26. The server only have one ip-address.
> >
> > The question then is, is this a practical solution, or can it be
> > done smarter, for example with less work and without using
> > iptables, or maybe some other way entirely?
> >
>
> Using iptables to separate traffic is a reasonable solution.
> Probably a good idea to add a comment to master.cf documenting what
> you've done.
>
> The more typical way to do this is for local mail to use the
> submission port 587. Sometimes folks redirect port 25 on the local
> network to 587 as a migration aid.
>
>
>
> -- Noel Jones
OK, but using submission more or less removes the problem with
SpamAssassin. Thank you for the pointer, I'll be sure to use 587
for relaying from the users.
This raises the question (or at least I think it do), if it's
possible to "force" the users onto 587 by denying relay access to 25?
RFC: postconf user interface
This note discusses some user-interface issues with upcoming postconf(1) features that will be used to manage the content of master.cf files. User-interface consistency is important, especially for people who work a lot with Postfix: fewer things to remember means fewer mistakes to make (it's also important for implementors, because it leads to similar code for similar operations and opportunities to use code that already exists, meaning fewer mistakes to make). In particular, it would be desirable that postconf(1) uses similar command syntax for similar operations on main.cf and master.cf. First I will review a few commands that already exist, and then I'll introduce some commands that are likely to be implemented. The first two examples are already implemented: postconf -M inet Show all TCP services in master.cf postconf -M inet.submission Show the submission-over-TCP service in master.cf Next, a few examples that are likely to be implemented: postconf -M# service-type ... postconf -M# service-type.service-name ... postconf -MX service-type ... postconf -MX service-type.service-name ... Delete (or comment) out the specified services. These commands are analogous to "postconf -# parameter(s)" (comment out main.cf parameter settings) and "postconf -X parameter(s)" (remove main.cf parameter settings). Therefore they should have similar syntax. I don't expect that these commands will be used much, but they will make the postconf command more consistent. I am contemplating a new class of master.cf operations that operate column-wise. These currently have no main.cf equivalent. postconf -Mu chroot=n inet unix fifo pass Update the "chroot" column to "n" for all services. postconf -Mu type=unix fifo Update all "fifo" services so that they use UNIX-domain sockets. This is more laptop-friendly as it avoids MTIME updates. Obviously, this command is powerful but it can also inflict a great deal of damage. And finally, a more complicated example: postconf -Me 'text of complete master.cf entry' Replace the specified master.cf service or add a new service. Each postconf(1) command-line argument contains the text of a complete master.cf entry. The new entry is line-wrapped as with "postconf -Mf". This command syntax is consistent with existing "postconf -e" commands, where each postconf(1) command-line argument contains the text of a complete main.cf entry. However, the syntax differs from "postconf -M" commands that can target multiple services, such as "postconf -M inet" or "postconf -Mu chroot=n inet". There, a service is better specified as service-type or service-type.service-name. Considering the difference between specifying the complete content of a master.cf entry versus a patterm that can select multiple master.cf entries, it makes sense to have this difference in command syntax. Wietse
Re: Integration of content filter in master.cf
Tue, 8 Jan 2013 20:29:30 +0100 skrev DTNX Postmaster : ... > > The more typical way to do this is for local mail to use the > > submission port 587. Sometimes folks redirect port 25 on the local > > network to 587 as a migration aid. > > > This. Using the submission port is highly recommended, as it avoids > all kinds of trouble, such as access providers blocking port 25. > > It also allows you to tailor each service to its specific needs; > postscreen on 25, required authentication plus TLS and rate limiting > on 587, and so on. > > HTH, > Jona > Thank you for the pointer on submission, I'll be sure to make use of it. But it raises a question (like i wrote in the reply to Noel), and that is (as far as i know) that I need to ensure the use of 587 so users can't "go around" rate limiting on 587 by using 25 for relaying. Would such a thing be possible to do?
Re: destination_rate_delay and connection_reuse_time_limit
Am 08.01.2013 21:40, schrieb Wietse Venema: > My conclusion is that Postfix can continue to provide basic policies > that avoid worst-case failure modes, but the choice of the settings > that control those policies is better left to the operator. If the > receiver slams on the brakes, then Postfix can suspend deliveries, > but the sender operator will have to adjust the sending rate. exactly this is the point thank you for your understanding and thoughts! signature.asc Description: OpenPGP digital signature
Re: Integration of content filter in master.cf
Am 08.01.2013 21:48, schrieb Titanus Eramius: > This raises the question (or at least I think it do), if it's > possible to "force" the users onto 587 by denying relay access to 25? it's more a human problem than a technically to force a large amount of users to change their for a long time wrong usage of port 25 submission inet n - n - 50 smtpd -o smtpd_client_connection_count_limit=15 -o smtpd_client_connection_rate_limit=80 -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o max_idle=1h -o max_use=500 remove "permit_sasl_authenticated" at the same time from main.cf and you should be more or less done, but as said. how to explain all users that thheir config is wrong since the first day they are using it signature.asc Description: OpenPGP digital signature
Re: Integration of content filter in master.cf
Am 08.01.2013 22:03, schrieb Titanus Eramius: > But it raises a question (like i wrote in the reply to Noel), and that > is (as far as i know) that I need to ensure the use of 587 so users > can't "go around" rate limiting on 587 by using 25 for relaying. > > Would such a thing be possible to do? smtpinet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=5 submission inet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=500 -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject signature.asc Description: OpenPGP digital signature
Re: RFC: postconf user interface
* Wietse Venema : > This note discusses some user-interface issues with upcoming > postconf(1) features that will be used to manage the content of > master.cf files. > > User-interface consistency is important, especially for people who > work a lot with Postfix: fewer things to remember means fewer > mistakes to make (it's also important for implementors, because it > leads to similar code for similar operations and opportunities to > use code that already exists, meaning fewer mistakes to make). > > In particular, it would be desirable that postconf(1) uses similar > command syntax for similar operations on main.cf and master.cf. > > First I will review a few commands that already exist, and then > I'll introduce some commands that are likely to be implemented. > > The first two examples are already implemented: > > postconf -M inet > Show all TCP services in master.cf > > postconf -M inet.submission > Show the submission-over-TCP service in master.cf > > Next, a few examples that are likely to be implemented: > > postconf -M# service-type ... > postconf -M# service-type.service-name ... > > postconf -MX service-type ... > postconf -MX service-type.service-name ... > > Delete (or comment) out the specified services. Would it make sense - differing from main.cf behaviour - to revert comments in master.cf? > These commands are analogous to "postconf -# parameter(s)" (comment > out main.cf parameter settings) and "postconf -X parameter(s)" > (remove main.cf parameter settings). Therefore they should have > similar syntax. I don't expect that these commands will be used > much, but they will make the postconf command more consistent. We've done a few web interfaces to configure Postfix. Having postconf edit master.cf would make such tasks easier. > I am contemplating a new class of master.cf operations that operate > column-wise. These currently have no main.cf equivalent. > > postconf -Mu chroot=n inet unix fifo pass > > Update the "chroot" column to "n" for all services. Would the new class also allow to edit a _single_ service e.g.: postconf -Mu chroot=n inet.submission > postconf -Mu type=unix fifo > > Update all "fifo" services so that they use UNIX-domain > sockets. This is more laptop-friendly as it avoids MTIME > updates. > > Obviously, this command is powerful but it can also inflict a great > deal of damage. Should postconf be able/offer to make backup copies before it acts a request out? > And finally, a more complicated example: > > postconf -Me 'text of complete master.cf entry' > > Replace the specified master.cf service or add a new service. > Each postconf(1) command-line argument contains the text > of a complete master.cf entry. The new entry is line-wrapped > as with "postconf -Mf". > > This command syntax is consistent with existing "postconf -e" > commands, where each postconf(1) command-line argument contains the > text of a complete main.cf entry. In postconf(1) you wrote "-e Edit the main.cf configuration file, and update parameter settings ..." I haven't thought this through - you probably have: Wouldn't it be more consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as proposed for master.cf? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: RFC: postconf user interface
how does one get off this list? My attempts have all been blocked by majordomo. Even Weitse's personal filter blocked my email /-: - Original Message - From: "Patrick Ben Koetter" To: Sent: Tuesday, January 08, 2013 4:38 PM Subject: Re: RFC: postconf user interface * Wietse Venema : This note discusses some user-interface issues with upcoming postconf(1) features that will be used to manage the content of master.cf files. User-interface consistency is important, especially for people who work a lot with Postfix: fewer things to remember means fewer mistakes to make (it's also important for implementors, because it leads to similar code for similar operations and opportunities to use code that already exists, meaning fewer mistakes to make). In particular, it would be desirable that postconf(1) uses similar command syntax for similar operations on main.cf and master.cf. First I will review a few commands that already exist, and then I'll introduce some commands that are likely to be implemented. The first two examples are already implemented: postconf -M inet Show all TCP services in master.cf postconf -M inet.submission Show the submission-over-TCP service in master.cf Next, a few examples that are likely to be implemented: postconf -M# service-type ... postconf -M# service-type.service-name ... postconf -MX service-type ... postconf -MX service-type.service-name ... Delete (or comment) out the specified services. Would it make sense - differing from main.cf behaviour - to revert comments in master.cf? These commands are analogous to "postconf -# parameter(s)" (comment out main.cf parameter settings) and "postconf -X parameter(s)" (remove main.cf parameter settings). Therefore they should have similar syntax. I don't expect that these commands will be used much, but they will make the postconf command more consistent. We've done a few web interfaces to configure Postfix. Having postconf edit master.cf would make such tasks easier. I am contemplating a new class of master.cf operations that operate column-wise. These currently have no main.cf equivalent. postconf -Mu chroot=n inet unix fifo pass Update the "chroot" column to "n" for all services. Would the new class also allow to edit a _single_ service e.g.: postconf -Mu chroot=n inet.submission postconf -Mu type=unix fifo Update all "fifo" services so that they use UNIX-domain sockets. This is more laptop-friendly as it avoids MTIME updates. Obviously, this command is powerful but it can also inflict a great deal of damage. Should postconf be able/offer to make backup copies before it acts a request out? And finally, a more complicated example: postconf -Me 'text of complete master.cf entry' Replace the specified master.cf service or add a new service. Each postconf(1) command-line argument contains the text of a complete master.cf entry. The new entry is line-wrapped as with "postconf -Mf". This command syntax is consistent with existing "postconf -e" commands, where each postconf(1) command-line argument contains the text of a complete main.cf entry. In postconf(1) you wrote "-e Edit the main.cf configuration file, and update parameter settings ..." I haven't thought this through - you probably have: Wouldn't it be more consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as proposed for master.cf? p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 22:06:26 +0100 skrev Reindl Harald : > > > Am 08.01.2013 21:48, schrieb Titanus Eramius: > > This raises the question (or at least I think it do), if it's > > possible to "force" the users onto 587 by denying relay access to > > 25? > > it's more a human problem than a technically to force a large amount > of users to change their for a long time wrong usage of port 25 > > submission inet n - n - 50 smtpd > -o smtpd_client_connection_count_limit=15 -o > smtpd_client_connection_rate_limit=80 -o smtpd_sasl_auth_enable=yes > -o smtpd_delay_reject=yes -o > smtpd_client_restrictions=permit_sasl_authenticated,reject -o > max_idle=1h -o max_use=500 > > remove "permit_sasl_authenticated" at the same time from main.cf and > you should be more or less done, but as said. how to explain all > users that thheir config is wrong since the first day they are using > it > Thankfully I still have a few months before I start to have actual costumers, so this is my one chance to avoid some of the common problems. But I suspect you might be right with 587 anyway, because at least this client (Claws Mail) uses 25 as the standard port when sending through POP. Thank you for the example to deactivate client relaying through 25. I think this solves my problem, so thanks again for the replies.
Re: Integration of content filter in master.cf
On 1/8/2013 2:48 PM, Titanus Eramius wrote: > Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones >> Using iptables to separate traffic is a reasonable solution. >> Probably a good idea to add a comment to master.cf documenting what >> you've done. >> >> The more typical way to do this is for local mail to use the >> submission port 587. Sometimes folks redirect port 25 on the local >> network to 587 as a migration aid. >> > > OK, but using submission more or less removes the problem with > SpamAssassin. Thank you for the pointer, I'll be sure to use 587 > for relaying from the users. > > This raises the question (or at least I think it do), if it's > possible to "force" the users onto 587 by denying relay access to 25? > It's certainly possible to prevent relaying via port 25, and many sites do so. The choice is a local policy decision; do what fits your needs best. Typically this is done by giving submission and port 25 different settings via master.cf -o ... overrides. A quick incomplete example: # main.cf mynetworks = 127.0.0.1 submission_mynetworks = 127.0.0.1, 192.168.0.0/16 smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination ... anti-spam controls ... submission_smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject # master.cf submission inet n - n - - smtpd -o syslog_name=postfix/submission -o mynetworks=$submission_mynetworks -o smtpd_recipient_restrictions=$submission_smtpd_recipient_restrictions ... more -o overrides ... Common variations are to require sasl AUTH on the submission port by removing permit_mynetworks, and to require TLS with AUTH by using "-o smtpd_tls_auth_only=yes". -- Noel Jones
Re: RFC: postconf user interface
Patrick Ben Koetter: > > Next, a few examples that are likely to be implemented: > > > > postconf -M# service-type ... > > postconf -M# service-type.service-name ... > > > > postconf -MX service-type ... > > postconf -MX service-type.service-name ... > > > > Delete (or comment) out the specified services. > > Would it make sense - differing from main.cf behaviour - to revert > comments in master.cf? In both cases, I don't understand how that would work. > > I am contemplating a new class of master.cf operations that operate > > column-wise. These currently have no main.cf equivalent. > > > > postconf -Mu chroot=n inet unix fifo pass > > > > Update the "chroot" column to "n" for all services. > > Would the new class also allow to edit a _single_ service e.g.: > > postconf -Mu chroot=n inet.submission Of course. A pattern can match one entry or more. > Should postconf be able/offer to make backup copies before it acts a request > out? Should it with main.cf? Should we enourage the use of version control? > > And finally, a more complicated example: > > > > postconf -Me 'text of complete master.cf entry' > > > > Replace the specified master.cf service or add a new service. > > Each postconf(1) command-line argument contains the text > > of a complete master.cf entry. The new entry is line-wrapped > > as with "postconf -Mf". > > > > This command syntax is consistent with existing "postconf -e" > > commands, where each postconf(1) command-line argument contains the > > text of a complete main.cf entry. > > In postconf(1) you wrote "-e Edit the main.cf configuration file, and update > parameter settings ..." The text is too vague and needs to be updated. What happens in reality is "replace or add main.cf entry, using the complete entry given on the postconf command line". If there is a command to implement THAT FUNCTION for master.cf (add or replace entry, using the complete entry given on the postconf command line) then it should use the same -e option. > I haven't thought this through - you probably have: Wouldn't it be more > consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as > proposed for master.cf? "u" replaces a field in master.cf. It has no main.cf equivalent (replace a word in the middle of a line?) therefore should not use an option letter that is used for main.cf. Wietse
To unsubscribe...
On 1/8/2013 3:46 PM, vi...@vheuser.com wrote: > how does one get off this list? > My attempts have all been blocked by majordomo. > Even Weitse's personal filter blocked my email /-: From: http://www.postfix.org/lists.html To stop list mail, send mail to majord...@postfix.org with content (not subject) one or more of the following commands: unsubscribe postfix-announce * unsubscribe postfix-users unsubscribe postfix-users-digest unsubscribe postfix-devel * Denotes the list to which you are currently subscribed. -- Stan
Re: Integration of content filter in master.cf
Tue, 08 Jan 2013 15:54:41 -0600 skrev Noel Jones : ... > > This raises the question (or at least I think it do), if it's > > possible to "force" the users onto 587 by denying relay access to > > 25? > > > > It's certainly possible to prevent relaying via port 25, and many > sites do so. > > The choice is a local policy decision; do what fits your needs best. > > Typically this is done by giving submission and port 25 different > settings via master.cf -o ... overrides. > > A quick incomplete example: > > # main.cf > mynetworks = 127.0.0.1 > submission_mynetworks = 127.0.0.1, 192.168.0.0/16 > smtpd_recipient_restrictions = > permit_mynetworks > reject_unauth_destination > ... anti-spam controls ... > submission_smtpd_recipient_restrictions = > permit_mynetworks > permit_sasl_authenticated > reject > > # master.cf > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o mynetworks=$submission_mynetworks > -o > smtpd_recipient_restrictions=$submission_smtpd_recipient_restrictions > ... more -o overrides ... > > > Common variations are to require sasl AUTH on the submission port by > removing permit_mynetworks, and to require TLS with AUTH by using > "-o smtpd_tls_auth_only=yes". > > > -- Noel Jones Thank you for the additional information, it's very helpful in the understanding of Postfix. I've had some trouble seeing the difference between -o overrides in main.cf and master.cf, but this really helps.
Re: Integration of content filter in master.cf
On 1/8/2013 4:11 PM, Titanus Eramius wrote: > I've had some trouble seeing the difference > between -o overrides in main.cf and master.cf, but this really helps. > main.cf parameters are used by all postfix services (but not all parameters apply to all services). Individual services defined in master.cf can override main.cf settings with -o ... options. http://www.postfix.org/postconf.5.html http://www.postfix.org/master.5.html -- Noel Jones
Re: RFC: postconf user interface
Le 08/01/2013 22:00, Wietse Venema a écrit : > This note discusses some user-interface issues with upcoming > postconf(1) features that will be used to manage the content of > master.cf files. > > User-interface consistency is important, especially for people who > work a lot with Postfix: fewer things to remember means fewer > mistakes to make (it's also important for implementors, because it > leads to similar code for similar operations and opportunities to > use code that already exists, meaning fewer mistakes to make). > > In particular, it would be desirable that postconf(1) uses similar > command syntax for similar operations on main.cf and master.cf. > > First I will review a few commands that already exist, and then > I'll introduce some commands that are likely to be implemented. > > The first two examples are already implemented: > > postconf -M inet > Show all TCP services in master.cf > > postconf -M inet.submission > Show the submission-over-TCP service in master.cf > > Next, a few examples that are likely to be implemented: > > postconf -M# service-type ... > postconf -M# service-type.service-name ... > > postconf -MX service-type ... > postconf -MX service-type.service-name ... > > Delete (or comment) out the specified services. > > These commands are analogous to "postconf -# parameter(s)" (comment > out main.cf parameter settings) and "postconf -X parameter(s)" > (remove main.cf parameter settings). Therefore they should have > similar syntax. I don't expect that these commands will be used > much, but they will make the postconf command more consistent. > > I am contemplating a new class of master.cf operations that operate > column-wise. These currently have no main.cf equivalent. > > postconf -Mu chroot=n inet unix fifo pass I like the "mib" syntax of main.cf. so I'd prefer something like postconf -e service.submission.chroot=n (or false|no|whatever) and then, I would love to have that in main.cf. more precisely, it would be nice to control master.cf things from main.cf: service.submission.disable = (true|false) so I could disable a service without removing it (the old pattern: active vs undefined) service.submission.chroot = false and then a service.all.chroot = false would disable all chrooting, which would be helpful when we suspect that a problem is due to a chroot. service.submission.class = smtpd service.submission.address = 0.0.0.0 service.submission.port = 587 service.submission.name = submission with this, we would have submission_recipient_restrictions = mumble dee service.submission.logname = postmumble/submission service.submission.options = joe=jim foo=bar ... this would add -o joe=jim etc. for all but "well known options". if you go that road, then at one time, master.cf would become a "service definition" file. > > Update the "chroot" column to "n" for all services. > > postconf -Mu type=unix fifo > > Update all "fifo" services so that they use UNIX-domain > sockets. This is more laptop-friendly as it avoids MTIME > updates. > > Obviously, this command is powerful but it can also inflict a great > deal of damage. > > And finally, a more complicated example: > > postconf -Me 'text of complete master.cf entry' > > Replace the specified master.cf service or add a new service. > Each postconf(1) command-line argument contains the text > of a complete master.cf entry. The new entry is line-wrapped > as with "postconf -Mf". > > This command syntax is consistent with existing "postconf -e" > commands, where each postconf(1) command-line argument contains the > text of a complete main.cf entry. > > However, the syntax differs from "postconf -M" commands that can > target multiple services, such as "postconf -M inet" or "postconf > -Mu chroot=n inet". There, a service is better specified as > service-type or service-type.service-name. > > Considering the difference between specifying the complete content > of a master.cf entry versus a patterm that can select multiple > master.cf entries, it makes sense to have this difference in command > syntax. > > Wietse
Re: RFC: postconf user interface
Le 08/01/2013 23:06, Wietse Venema a écrit : > Patrick Ben Koetter: > [snip] >> Should postconf be able/offer to make backup copies before it acts a request >> out? > Should it with main.cf? Should we enourage the use of version control? given that people use different version control systems, I wouldn't make that part of postfix. also, I am working on a web UI, where the whole conf would be in a db (dumped to config files of course!). in which case, the version control part amounts to a few columns (who did what when...) and a rollback is not a lot more than an sql query. (I actually can do all that "for me", but I find it hard to support all the possible configurations that postfix supports). >>> And finally, a more complicated example: >>> >>> postconf -Me 'text of complete master.cf entry' >>> >>> Replace the specified master.cf service or add a new service. >>> Each postconf(1) command-line argument contains the text >>> of a complete master.cf entry. The new entry is line-wrapped >>> as with "postconf -Mf". >>> >>> This command syntax is consistent with existing "postconf -e" >>> commands, where each postconf(1) command-line argument contains the >>> text of a complete main.cf entry. >> In postconf(1) you wrote "-e Edit the main.cf configuration file, and >> update >> parameter settings ..." > The text is too vague and needs to be updated. What happens in > reality is "replace or add main.cf entry, using the complete entry > given on the postconf command line". > > If there is a command to implement THAT FUNCTION for master.cf (add > or replace entry, using the complete entry given on the postconf > command line) then it should use the same -e option. > >> I haven't thought this through - you probably have: Wouldn't it be more >> consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' as >> proposed for master.cf? > "u" replaces a field in master.cf. It has no main.cf equivalent > (replace a word in the middle of a line?) therefore should not use > an option letter that is used for main.cf. > > Wietse
Re: Integration of content filter in master.cf
Le 08/01/2013 21:48, Titanus Eramius a écrit :
> Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones
> :
>
>> On 1/8/2013 10:47 AM, Titanus Eramius wrote:
>>> I'm a little unsure about best practice here, hence the question.
>>>
>>> Running /usr/sbin/spamd from the SpamAssassin package to scan mail,
>>> I've integrated it into /etc/postfix/master.cf with the following
>>> lines
>>> ---
>>> smtp inet n - n - - smtpd -o
>>> content_filter=spamassassin
>>> ...
>>> spamassassin unix - n n - - pipe
>>>flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
>>> -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
>>> ---
>>>
>>> And then in /etc/postfix/main.cf there's added the line
>>> ---
>>> spamassassin_destination_recipient_limit = 1
>>> ---
>>>
>>> However, this scans both incoming and outgoing mail, but for
>>> outgoing I plan on using rate-limiting to avoid spamming the net
>>> (to much), in case an account gets hacked.
>>>
>>> So I searched the web, and constructed this alternative to use in
>>> master.cf
>>> ---
>>> 26 inet n - n - - smtpd -o
>>> content_filter=spamassassin smtp inet n - n - - smtpd
>>> ---
>>>
>>> Using iptables, all incoming connections to port 25 could then be
>>> directed to port 26. The server only have one ip-address.
>>>
>>> The question then is, is this a practical solution, or can it be
>>> done smarter, for example with less work and without using
>>> iptables, or maybe some other way entirely?
>>>
>> Using iptables to separate traffic is a reasonable solution.
>> Probably a good idea to add a comment to master.cf documenting what
>> you've done.
>>
>> The more typical way to do this is for local mail to use the
>> submission port 587. Sometimes folks redirect port 25 on the local
>> network to 587 as a migration aid.
>>
>>
>>
>> -- Noel Jones
> OK, but using submission more or less removes the problem with
> SpamAssassin. Thank you for the pointer, I'll be sure to use 587
> for relaying from the users.
>
> This raises the question (or at least I think it do), if it's
> possible to "force" the users onto 587 by denying relay access to 25?
fix the problem at the source: force the client to do the work:
use different services for different uses:
[MX service]
port: 25
example DNS name: mx01.example.com
=> no relay
virus and spam filtering...
[submission service]
example DNS name: smtp01.example.com
port 587. if this is hard, port 25 with a specific IP is ok.
SASL auth. when not desirable, IP based access control (thoug this may
be implemented outside of postfix, such as on a firewall)
virus filtering
rate limit and custom checks as needed.
[reverse MX]
example DNS name: mailrelay01.example.com
in small setups, this could be the same service as the submission one.
in larger setups, make this dedicated. it'll take the complexity of mail
routing and "caching" (retry).
...
Re: RFC: postconf user interface
mouss: > > I am contemplating a new class of master.cf operations that operate > > column-wise. These currently have no main.cf equivalent. > > > > postconf -Mu chroot=n inet unix fifo pass > > I like the "mib" syntax of main.cf. so I'd prefer something like > postconf -e service.submission.chroot=n (or false|no|whatever) > and then, I would love to have that in main.cf. A problem is that your syntax is ambiguous: a service name may contain ".", the same character that you propose to use as the separator between service name and column name (in fact any non-space character is permitted though '/' might be a problem). > service.submission.class = smtpd > service.submission.address = 0.0.0.0 > service.submission.port = 587 > service.submission.name = submission I want to complete the support for the existing configuration file formats, before I start to consider semantical changes. Wietse
Re: RFC: postconf user interface
* Wietse Venema : > Patrick Ben Koetter: > > > Next, a few examples that are likely to be implemented: > > > > > > postconf -M# service-type ... > > > postconf -M# service-type.service-name ... > > > > > > postconf -MX service-type ... > > > postconf -MX service-type.service-name ... > > > > > > Delete (or comment) out the specified services. > > > > Would it make sense - differing from main.cf behaviour - to revert > > comments in master.cf? > > In both cases, I don't understand how that would work. Neither do I. Here's the problem I'd like to solve: The submission service is commented out by default. Nowadays I enable it very often when I install Postfix. Issuing a command that removes/reverts the comments from e.g. the submission service sounds just like a feature that would solve my problem. Thus the investigation if it made sense to revert comments in master.cf. On a sidenote: At the moment "postconf -M ..." doesn't seem to list service types that are commented out. Unless I haven't missed a way it would probably make sense to list them if comments were to be reverted. > > > I am contemplating a new class of master.cf operations that operate > > > column-wise. These currently have no main.cf equivalent. > > > > > > postconf -Mu chroot=n inet unix fifo pass > > > > > > Update the "chroot" column to "n" for all services. > > > > Would the new class also allow to edit a _single_ service e.g.: > > > > postconf -Mu chroot=n inet.submission > > Of course. A pattern can match one entry or more. > > > Should postconf be able/offer to make backup copies before it acts a request > > out? > > Should it with main.cf? Should we enourage the use of version control? Somehow I fear that we will see more users having ruined their master.cf than others having done the same to main.cf. Resurrecting a master.cf seems to be more hard because of its higher inner complexity (columns etc.). I think the documentation should encourage the use of version control. The rest may remain every admins personal responsibility. > > > And finally, a more complicated example: > > > > > > postconf -Me 'text of complete master.cf entry' > > > > > > Replace the specified master.cf service or add a new service. > > > Each postconf(1) command-line argument contains the text > > > of a complete master.cf entry. The new entry is line-wrapped > > > as with "postconf -Mf". > > > > > > This command syntax is consistent with existing "postconf -e" > > > commands, where each postconf(1) command-line argument contains the > > > text of a complete main.cf entry. > > > > In postconf(1) you wrote "-e Edit the main.cf configuration file, and > > update > > parameter settings ..." > > The text is too vague and needs to be updated. What happens in > reality is "replace or add main.cf entry, using the complete entry > given on the postconf command line". > > If there is a command to implement THAT FUNCTION for master.cf (add > or replace entry, using the complete entry given on the postconf > command line) then it should use the same -e option. > > > I haven't thought this through - you probably have: Wouldn't it be more > > consistent to use only 'e' (as already for main.cf) instead of 'u' and 'e' > > as > > proposed for master.cf? > > "u" replaces a field in master.cf. It has no main.cf equivalent > (replace a word in the middle of a line?) therefore should not use > an option letter that is used for main.cf. Got it. Thanks p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
RBLs, submission port, and permit_sasl_authenticated
So, with the breakout in Postfix 2.10 for smtpd_relay_restrictions and smtpd_recipient_restrictions, I seem to have goofed in relation to RBLs and the submission port. Right now, we have RBLs added to smtpd_recipient_restrictions. In smtpd_relay_restrictions, I have permit_sasl_authenticated. Unfortunately, this means remote (generally mobile) email sent via the submission port is being blocked by RBLs because of their originating IP, regardless of the fact that the emails are authenticated. Should I have RBLs in smtpd_relay_restrictions instead? Or should I have moved permit_sasl_authenticated into smtpd_recipient_restrictions? Or something else entirely? Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration
Re: RBLs, submission port, and permit_sasl_authenticated
* Quanah Gibson-Mount : > So, with the breakout in Postfix 2.10 for smtpd_relay_restrictions > and smtpd_recipient_restrictions, I seem to have goofed in relation > to RBLs and the submission port. > > Right now, we have RBLs added to smtpd_recipient_restrictions. In > smtpd_relay_restrictions, I have permit_sasl_authenticated. > > Unfortunately, this means remote (generally mobile) email sent via > the submission port is being blocked by RBLs because of their > originating IP, regardless of the fact that the emails are > authenticated. > > Should I have RBLs in smtpd_relay_restrictions instead? Or should I > have moved permit_sasl_authenticated into > smtpd_recipient_restrictions? Or something else entirely? MTA to MTA traffic on 25 MUA to MTA traffic on 587 25: Check for transportability Fight Spam using e.g. RBL Enforce other policies Accept 587: Check for transportability Accept If you need to reconfigure MUAs, use automx to make reconfiguration easier for Outlook, Thunderbird and other MUAs. p@rick -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Joerg Heidrich
domain name to cert/key file mapping
Hello, is there any way to set certificate / key file name depending on domain name? I mean something similar to this Exim feature: http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTtlssni ...or this Dovecot feature: http://wiki2.dovecot.org/SSL/DovecotConfiguration#Multiple_SSL_certificates I guess in Postfix it would be something like smtpd_tls_cert_map / ...key_map, but I haven't found any such option. If such feature is not supported yet, is it planned? Regards
Re: domain name to cert/key file mapping
Piotr Paw?ow: > is there any way to set certificate / key file name depending on domain > name? Postfix does not yet implement SNI (RFC 3546). All implemented RFCs are documented. > I guess in Postfix it would be something like smtpd_tls_cert_map > / ...key_map, but I haven't found any such option. If such feature > is not supported yet, is it planned? The developer cycles are limited. Wietse
Re: destination_rate_delay and connection_reuse_time_limit
On Tue, Jan 08, 2013 at 10:02:31PM +0100, Reindl Harald wrote: > Am 08.01.2013 21:40, schrieb Wietse Venema: > > My conclusion is that Postfix can continue to provide basic policies > > that avoid worst-case failure modes, but the choice of the settings > > that control those policies is better left to the operator. If the > > receiver slams on the brakes, then Postfix can suspend deliveries, > > but the sender operator will have to adjust the sending rate. > > exactly this is the point > > thank you for your understanding and thoughts! Suspending delivery and punting all messages from the active queue for the designated nexthop is not a winning strategy. In this state mail delivery to the destination is in most cases unlikely to recover without manual intervention. I would posit that neither Reindl nor the OP, or that many others really understand what they are asking for. If they understood, they would stop asking for it. When faced with a destination that imposes tight rate limits you must pre-configure your MTA to always stay under the limits. Nothing good happens when the Postfix output rate under load exceeds the remote limit whether you throttle the queue repeatedly or not. The best that one can hope for is for Postfix to dynamically apply a rate delay that is guaranteed to be slow enough to get under the limit, and then gradually reduce it. Throttling the destination (moving all active mail to deferred) is a pre-programmed MTA outage, I'd not want to operate any system that behaves that way, and neither should you, whether you know it or not. -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
Am 09.01.2013 02:57, schrieb Viktor Dukhovni: > On Tue, Jan 08, 2013 at 10:02:31PM +0100, Reindl Harald wrote: > >> Am 08.01.2013 21:40, schrieb Wietse Venema: >>> My conclusion is that Postfix can continue to provide basic policies >>> that avoid worst-case failure modes, but the choice of the settings >>> that control those policies is better left to the operator. If the >>> receiver slams on the brakes, then Postfix can suspend deliveries, >>> but the sender operator will have to adjust the sending rate. >> >> exactly this is the point >> >> thank you for your understanding and thoughts! > > Suspending delivery and punting all messages from the active queue > for the designated nexthop is not a winning strategy. In this state > mail delivery to the destination is in most cases unlikely to > recover without manual intervention. it is in the usecase of a DEDICATED newsletter relay why should it not recover? the request was "after 20 temp fails to the same destination retry the next delivers to THIS destination FIVE MINUTES later" > I would posit that neither Reindl nor the OP, or that many others > really understand what they are asking for. If they understood, > they would stop asking for it. i would posit you do not understand the usecase > When faced with a destination that imposes tight rate limits you > must pre-configure your MTA to always stay under the limits. Nothing > good happens when the Postfix output rate under load exceeds the > remote limit whether you throttle the queue repeatedly or not smtp_destination_recipient_limit = 15 smtp_initial_destination_concurrency = 2 smtp_destination_concurrency_limit= 2 smtp_destination_concurrency_failed_cohort_limit = 5 smtp_destination_rate_delay = 1 so what should one do more? the sending machine is whitelisted at the ISP but the whitelisting does not affect rate-limits and yes we do not care if a newsletter has reached every RCPT two hours later but we do care for reputation and not exceed rate limits of large ISP's signature.asc Description: OpenPGP digital signature
Re: RFC: postconf user interface
On Tue, Jan 08, 2013 at 04:00:34PM -0500, Wietse Venema wrote: > > However, the syntax differs from "postconf -M" commands that can > target multiple services, such as "postconf -M inet" or "postconf > -Mu chroot=n inet". There, a service is better specified as > service-type or service-type.service-name. > > Considering the difference between specifying the complete content > of a master.cf entry versus a patterm that can select multiple > master.cf entries, it makes sense to have this difference in command > syntax. I almost no issues with any of the proposed interfaces. The new "-Me" syntax is natural. The -Mu syntax also makes sense for all the standard columns. The only part that is tricky is the "command + args" column, where users arguably may want to add/delete "-o" flags, but in general the various "-o" flags one may want to add are not necessarily othogonal, and it is not always safe to add such a setting while unware of its context. So perhaps when changing the command, one should be forced to use "-Me", but this is not completely obvious. Perhaps one should be add to insert or delete a "-o" setting, but this would likely require yet another cinterface (-Mo?) and is likely not worth the complexity. -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
On Wed, Jan 09, 2013 at 03:06:58AM +0100, Reindl Harald wrote: > > Suspending delivery and punting all messages from the active queue > > for the designated nexthop is not a winning strategy. In this state > > mail delivery to the destination is in most cases unlikely to > > recover without manual intervention. > > it is in the usecase of a DEDICATED newsletter relay > why should it not recover? > > the request was "after 20 temp fails to the same destination > retry the next delivers to THIS destination FIVE MINUTES later" That's not what happens when a destination is throttled, all mail there is deferred, and is retried some indefinite time later that is at least 5 minutes but perhaps a lot longer, and at great I/O cost, with expontial backoff for each message based on time in the queue, ... To understand what one is asking for, one needs to understand the scheduler (qmgr) architecture. Otherwise, one is just babbling nonsense (no offense intended). > > I would posit that neither Reindl nor the OP, or that many others > > really understand what they are asking for. If they understood, > > they would stop asking for it. > > i would posit you do not understand the usecase How likely do you think that is? Of course I understand the use case, in fact better than the users who are asking for it. > and yes we do not care if a newsletter has reached every RCPT > two hours later but we do care for reputation and not exceed > rate limits of large ISP's Throttling the destination (which means moving all pending messages for the destinatin to deferred, where they age exponentially, while more mail builds up...) is not the answer to your problem. 1. Get whitelisted without limits, send at the arrival rate. 2. Get whitelisted at above the arrival rate, set rate delay to avoid exceeding the rate. 3. Don't waste time with unresponsive mailbox providers, tell their customers their mailbox provider is not supported. 4. Snowshoe. Pick the first one that is viable for you. -- Viktor.
Re: domain name to cert/key file mapping
On Tue, Jan 08, 2013 at 07:58:38PM -0500, Wietse Venema wrote: > > is there any way to set certificate / key file name depending on domain > > name? This problem is much harder for SMTP that HTTP, since the MTA does not know with certainty which acceptable certificate a receiving site is likely to have. It might have a certificate for the recipient domain, or for the gateway name. SNI only works well when the protocol clearly specifies the expected SSL peer. This is not the case with SMTP, given MX record indirection and the logical separation of the transport and application end-points (gateway vs. domain). Thus and for other reasons it is very unlikely that Postfix will support SNI with SMTP any time soon. -- Viktor.
Re: destination_rate_delay and connection_reuse_time_limit
Am 09.01.2013 03:17, schrieb Viktor Dukhovni: >> the request was "after 20 temp fails to the same destination >> retry the next delivers to THIS destination FIVE MINUTES later" > > That's not what happens when a destination is throttled, all mail > there is deferred, and is retried some indefinite time later that > is at least 5 minutes but perhaps a lot longer, and at great I/O > cost, with expontial backoff for each message based on time in the > queue, ... > > To understand what one is asking for, one needs to understand the > scheduler (qmgr) architecture. Otherwise, one is just babbling > nonsense (no offense intended). and the request was if the behavior can be controlled in the future and not was the behavior currently is > Throttling the destination (which means moving all pending messages > for the destinatin to deferred, where they age exponentially, while > more mail builds up...) is not the answer to your problem. sorry, but you really NOT understand the usecase "while more mail builds up" NO there is NO MORE MAIL built up * DEDICATED NEWSLETTER MACHINE * means large amount of mails one or two times a week > 1. Get whitelisted without limits, send at the arrival rate no option > 2. Get whitelisted at above the arrival rate, set rate delay to > avoid exceeding the rate you missed smtp_destination_recipient_limit= 15 smtp_initial_destination_concurrency= 2 smtp_destination_concurrency_limit = 2 smtp_destination_concurrency_failed_cohort_limit= 10 smtp_destination_rate_delay = 1 > 3. Don't waste time with unresponsive mailbox providers, tell their > customers their mailbox provider is not supported. reailty check: you propose to tell my customers that they should tell their customers anything because the mailadmin would like to get rid of the permamently "try again later" messages in his maillog this will not happen in the real world signature.asc Description: OpenPGP digital signature
Re: RFC: postconf user interface
On 1/8/2013 5:26 PM, Patrick Ben Koetter wrote:
> * Wietse Venema :
>> Patrick Ben Koetter:
Next, a few examples that are likely to be implemented:
postconf -M# service-type ...
postconf -M# service-type.service-name ...
postconf -MX service-type ...
postconf -MX service-type.service-name ...
Delete (or comment) out the specified services.
>>>
>>> Would it make sense - differing from main.cf behaviour - to revert
>>> comments in master.cf?
>>
>> In both cases, I don't understand how that would work.
>
> Neither do I.
>
> Here's the problem I'd like to solve: The submission service is commented out
> by default. Nowadays I enable it very often when I install Postfix. Issuing a
> command that removes/reverts the comments from e.g. the submission service
> sounds just like a feature that would solve my problem. Thus the investigation
> if it made sense to revert comments in master.cf.
I don't think "uncomment" is particularly useful. Just ignore
commented entries; add a new entry with the desired settings. That
way you don't have to worry about multiple matching comments with
the same name.
>
> On a sidenote: At the moment "postconf -M ..." doesn't seem to list service
> types that are commented out. Unless I haven't missed a way it would probably
> make sense to list them if comments were to be reverted.
I think comments should be ignored by the automated tools.
And yes, the docs should strongly encourage the user to back up *.cf
before mucking around with them. I can imagine postconf saving the
unmodified file to eg. ./rescue/master.cf-{date+time}.
-- Noel Jones
Re: RBLs, submission port, and permit_sasl_authenticated
On 1/8/2013 5:38 PM, Quanah Gibson-Mount wrote:
> So, with the breakout in Postfix 2.10 for smtpd_relay_restrictions
> and smtpd_recipient_restrictions, I seem to have goofed in relation
> to RBLs and the submission port.
>
> Right now, we have RBLs added to smtpd_recipient_restrictions. In
> smtpd_relay_restrictions, I have permit_sasl_authenticated.
I suggest explicitly specify all the smtpd_{client, helo, sender,
recipient, relay, data, end_of_data}_restrictions in the master.cf
submission service definition to prevent surprises -- most of these
would be set to empty.
That way there won't be any RBLs anywhere on the submission port,
regardless of what happens in main.cf.
If email is submitted on port 25, you would need to add
permit_sasl_authenticated to every used smtpd_*_restrictions.
-- Noel Jones
