block sender/receiver pairs
Hi, I need to block certain combinations of sender/receiver on a postfix MTA. What would be the best way? Cheers, Stefan
Re: block sender/receiver pairs
On 2018-08-27 Stefan Sticht wrote: > I need to block certain combinations of sender/receiver on a postfix > MTA. What would be the best way? Not sure this is the best way, but I'm using restriction classes for things like that. In main.cf: 8< smtpd_restriction_classes = rc_foo rc_foo = check_sender_access hash:/etc/postfix/foo_sender_access smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination ... check_recipient_access hash:/etc/postfix/recipient_access ... >8 In recipient_access: 8< f...@example.org rc_foo >8 In foo_sender_access: 8< b...@example.com REJECT Mail not accepted. some...@example.net REJECT Mail not accepted. >8 Regards Ansgar Wiechers -- "Abstractions save us time working, but they don't save us time learning." --Joel Spolsky
Re: block sender/receiver pairs
Stefan Sticht: > Hi, > > > I need to block certain combinations of sender/receiver on a postfix > MTA. What would be the best way? www.postfwd.org Wietse
Re: How does smtp_destination_concurrency_limit and smtp_destination_rate_delay relate?
On Sun, Aug 26, 2018 at 2:15 PM, Wietse Venema wrote: > > Matus UHLAR - fantomas: > > >Rodrigo Severo - F?brica: > > >> I think that this info - the delay between deliveries is per > > >> connection and not per, or only, per domain - should be stated > > >> clearly in the documentation. > > > > On 26.08.18 11:08, Wietse Venema wrote: > > >Absolutely not. I promise that each delivery to that destination > > >(recipient or domain) will be followed by the per-destination > > >transport_destination_rate_delay. > > > > so, does transport_destination_concurrency_limit not apply when > > transport_destination_rate_delay is >0 ? > > There can be no concurrency. > > With rate delay, there is an N second delay between the completion > of delivery 1 to the destination, and the start of delivery 2 to > that same destination. > > From this it follows that delivery 2 does not start before the rate > delay expires, that delivery 2 does not start before delivery 1 has > completed, and that there is no overlap in time between delivery > 1, 2, 3, 4, 5, 6, 7, 8, and so on, to that same destination. > > You can replace 'email' with 'car', and 'destinion' with 'bridge'. > > Imagine counting cars that pass over a bridge. Imagine that car 1 > starts crossing the bridge, and that some time later it arrives at > the other side. Then there is an N second delay before car 2 starts > crossing that same bridge. > > From this it follows that car 2 does not start crossing the bridge > before the delay has expired, that car 2 does not start crossing > the bridge before car 1 has arrived at the other side, and that > there is no overlap in time that cars 1, 2, 3, 4, 5, 6, 7, 8, and > so on, are crossing that same bridge. To use your analogy, my doubt is: if a bridge is a destination, increasing transport_destination_concurrency_limit won't create new lanes on this same bridge? Increasing transport_destination_concurrency_limit won't make more cars pass at the same time on this same bridge? My doubt is, is I set transport_destination_concurrency_limit = 2 or transport_destination_concurrency_limit = 3 the flow is the same? Having set transport_destination_rate_delay > 0, the transport_destination_concurrency_limit > 1 setting is ignored. Is that it? Regards, Rodrigo Severo
Re: Reject mails coming from mailservers whos reverse DNS resolution match a certain pattern
Hello Matus, > for blocking .artegic.net you don't need to use pcre. > simple hash table containing ".artegic.net" would be faster. I see. Thanks a lot. Cheers, Thomas
Re: How does smtp_destination_concurrency_limit and smtp_destination_rate_delay relate?
Rodrigo Severo - F?brica: > On Sun, Aug 26, 2018 at 2:15 PM, Wietse Venema wrote: > > > > Matus UHLAR - fantomas: > > > >Rodrigo Severo - F?brica: > > > >> I think that this info - the delay between deliveries is per > > > >> connection and not per, or only, per domain - should be stated > > > >> clearly in the documentation. > > > > > > On 26.08.18 11:08, Wietse Venema wrote: > > > >Absolutely not. I promise that each delivery to that destination > > > >(recipient or domain) will be followed by the per-destination > > > >transport_destination_rate_delay. > > > > > > so, does transport_destination_concurrency_limit not apply when > > > transport_destination_rate_delay is >0 ? > > > > There can be no concurrency. > > > > With rate delay, there is an N second delay between the completion > > of delivery 1 to the destination, and the start of delivery 2 to > > that same destination. > > > > From this it follows that delivery 2 does not start before the rate > > delay expires, that delivery 2 does not start before delivery 1 has > > completed, and that there is no overlap in time between delivery > > 1, 2, 3, 4, 5, 6, 7, 8, and so on, to that same destination. > > > > You can replace 'email' with 'car', and 'destinion' with 'bridge'. > > > > Imagine counting cars that pass over a bridge. Imagine that car 1 > > starts crossing the bridge, and that some time later it arrives at > > the other side. Then there is an N second delay before car 2 starts > > crossing that same bridge. > > > > From this it follows that car 2 does not start crossing the bridge > > before the delay has expired, that car 2 does not start crossing > > the bridge before car 1 has arrived at the other side, and that > > there is no overlap in time that cars 1, 2, 3, 4, 5, 6, 7, 8, and > > so on, are crossing that same bridge. > > To use your analogy, my doubt is: if a bridge is a destination, > increasing transport_destination_concurrency_limit won't create new > lanes on this same bridge? Increasing > transport_destination_concurrency_limit won't make more cars pass at > the same time on this same bridge? Let me repeat the text from above: there is no overlap in time that cars 1, 2, 3, 4, 5, 6, 7, 8, and so on, are crossing that same bridge. To state the obviuos, there can be no more than one car on the bridge. Wietse
Re: How does smtp_destination_concurrency_limit and smtp_destination_rate_delay relate?
On Mon, Aug 27, 2018 at 10:53 AM, Wietse Venema wrote: > Rodrigo Severo - F?brica: >> On Sun, Aug 26, 2018 at 2:15 PM, Wietse Venema wrote: >> > >> > Matus UHLAR - fantomas: >> > > >Rodrigo Severo - F?brica: >> > > >> I think that this info - the delay between deliveries is per >> > > >> connection and not per, or only, per domain - should be stated >> > > >> clearly in the documentation. >> > > >> > > On 26.08.18 11:08, Wietse Venema wrote: >> > > >Absolutely not. I promise that each delivery to that destination >> > > >(recipient or domain) will be followed by the per-destination >> > > >transport_destination_rate_delay. >> > > >> > > so, does transport_destination_concurrency_limit not apply when >> > > transport_destination_rate_delay is >0 ? >> > >> > There can be no concurrency. >> > >> > With rate delay, there is an N second delay between the completion >> > of delivery 1 to the destination, and the start of delivery 2 to >> > that same destination. >> > >> > From this it follows that delivery 2 does not start before the rate >> > delay expires, that delivery 2 does not start before delivery 1 has >> > completed, and that there is no overlap in time between delivery >> > 1, 2, 3, 4, 5, 6, 7, 8, and so on, to that same destination. >> > >> > You can replace 'email' with 'car', and 'destinion' with 'bridge'. >> > >> > Imagine counting cars that pass over a bridge. Imagine that car 1 >> > starts crossing the bridge, and that some time later it arrives at >> > the other side. Then there is an N second delay before car 2 starts >> > crossing that same bridge. >> > >> > From this it follows that car 2 does not start crossing the bridge >> > before the delay has expired, that car 2 does not start crossing >> > the bridge before car 1 has arrived at the other side, and that >> > there is no overlap in time that cars 1, 2, 3, 4, 5, 6, 7, 8, and >> > so on, are crossing that same bridge. >> >> To use your analogy, my doubt is: if a bridge is a destination, >> increasing transport_destination_concurrency_limit won't create new >> lanes on this same bridge? Increasing >> transport_destination_concurrency_limit won't make more cars pass at >> the same time on this same bridge? > > Let me repeat the text from above: there is no overlap in time that > cars 1, 2, 3, 4, 5, 6, 7, 8, and so on, are crossing that same > bridge. > > To state the obviuos, there can be no more than one car on the bridge. Ok, so setting transport_destination_rate_delay > 0 disables transport_destination_concurrency_limit (or fixes it at 1). I believe this info could, and should, be stated clearly on the documentation. Thanks for your help, patience and support. Regards, Rodrigo Severo
Re: rewrite/masquerade configuration
I'm in the process of making your suggested changes and testing. But not sure how these changes will address the two users I need to stay local. John -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: rewrite/masquerade configuration
john: > I'm in the process of making your suggested changes and testing. But not sure > how these changes will address the two users I need to stay local. There's a README for that: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#some_local I might add here: do not add the domain name to virtual_alias_domains, That would screw up everyone elses email. Wietse
