Re: no reject in smtpd_recipient_restrictions?
On 4/7/2011 1:50 PM, Gábor Lénárt wrote: On Thu, Apr 07, 2011 at 02:40:09PM -0400, Victor Duchovni wrote: For submission: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject Then feel free to implement other checks in the sender restrictions if that's easier to understand. That's OK, but I have different level of HELO checks for SASL and "IP" authenticated users. For sasl authenticated there are no checks (MUAs are not famous to send meaningful HELO/EHLO names as I can say at least) but MTAs which are allowed to relay through this server have more stricter rules, that's why I am implemented it that way. Authorized is authorized; don't put an authorized IP through extra hoops just to see if they can configure a mail server properly. And I wanted to do this as early as possible (so at sender), to match to the old system. But never mind, I am starting to feel that it's useless to think this much, and simplier and more managable config is a nicer solution anyway. Thanks for your answers again! Start with a simple, conventional configuration. Don't pre-optimize yourself into an unmanageable installation. -- Noel Jones
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 02:40:09PM -0400, Victor Duchovni wrote: > On Thu, Apr 07, 2011 at 08:27:01PM +0200, G?bor L?n?rt wrote: > > > I don't want to check if rcpt domain is mine (I have no "own" domains on > > this MTA). I want to accept everything if sender is authenticated, since > > it's a mail submit MTA, users can submit mails through it. > > > > I don't need reject_unauth_destination, since every destination is valid :) > > [ok, for sure non-existing or non-fqdn domain is not, also I have an SQL > > based bann list for "bad ones" both for senders and rcpts as you can see > > later with the banned_* sql tables) > > For submission: > > smtpd_recipient_restrictions = > permit_mynetworks, > permit_sasl_authenticated, > reject > > Then feel free to implement other checks in the sender restrictions if > that's easier to understand. That's OK, but I have different level of HELO checks for SASL and "IP" authenticated users. For sasl authenticated there are no checks (MUAs are not famous to send meaningful HELO/EHLO names as I can say at least) but MTAs which are allowed to relay through this server have more stricter rules, that's why I am implemented it that way. And I wanted to do this as early as possible (so at sender), to match to the old system. But never mind, I am starting to feel that it's useless to think this much, and simplier and more managable config is a nicer solution anyway. Thanks for your answers again!
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 12:42:49PM -0500, Noel Jones wrote: > On 4/7/2011 11:00 AM, Gábor Lénárt wrote: > >On Thu, Apr 07, 2011 at 10:40:28AM -0500, Noel Jones wrote: > >[...] > >>Use instead: > >>smtpd_recipient_restrictions = > >> permit_sasl_authenticated, > >> reject > >> > >>The overhead is negligible -- just check an internal status flag, > >>about the same as your fake table lookup -- and may save you from an > >>embarrassing accident. > > > >Yes, I have the same idea, however I need not only sasl authenticated users > >to accept but some others too, "authenticated" by their IPs, and it involves > >ldap, mysql and cidr tables too, since I have different systems (not my > >choice!) to need to check. If I already check those at sender restricitons, > >I guess it's safe to say that everything is OK. At the other hand, to be > >"really safe and not so ugly" I would need to do these again at recipient > >restrictions, which would need some measurable overhead anyway. Or maybe > >not, and I am just too nervous about those "overhead" and "resources" :) > > > >thanks for you answer, > > > >- Gábor > > > Please ignore my previous answer -- you didn't supply complete > information rendering my advice incorrect. > > Repeat your checks in smtpd_recipient_restrictions -- or even > better, move them. The cidr table access time will be negligible if > it contains less than a few thousand lines, and you should be using > proxy:ldap:... for your all your ldap lookups, which will improve > performance and scalability. See the the proxymap documentation > http://www.postfix.org/proxymap.8.html Hehe, cool, I've just read its README file before I've seen your mail :) Current mail submission server is a very old Sun messaging server btw, nad why I need to find a solution is because of its age, performance problems, and similar issues. What I thought that I would like to make a replacement using postfix which functionalities of the old one as close as possible. I've played with telnet'ing it and I've find out that it always make decisions the earliest possible state of the SMTP communication. That was the thing which made me think to try to make something with postfix which can do this, without any error delaying, or using "later" restriction to decide than the earliest possible for a given rule. > > Using "smtpd_delay_reject = no" is not recommended. Don't do that > unless you have a full understanding of the implications and are > willing to suffer the consequences. Can you tell me, what the problem is with smtpd_delay_reject? other than not having "nice" log (maybe I have no sender/rcpt pairs on log in case of some rejection since I reject before rcpt info is there). Also I've read postfix's excellent documentation before I've posted my question here, it talks about "broken MTAs may don't like rejected commands before RCPT TO". I am aware of that, but our current solution which is to be replaced behaves like this too, so I can't say there will be problems which were not in the past at least :) > And pay attention to what Viktor and Wietse tell you. Of course! Please do not think that I want to argue (as I've mentioned) that postfix is "bad" because it needs reject or something in some restrictions (that was the part when used the "static:OK, reject" sequence to "trick it"). Also of course I know that you know about postfix much more. Also I know that my solution is hmm "not so nice" (ok, ugly). These are not questions, I am just curious that my theory has any serious problems other than these ugliness, too complex statements etc (which are true). Now I'm playing with a nicer solution also with took your opinions, just still I am interested if my knowledge on postfix configuration was OK at all or not :)
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 08:27:01PM +0200, G?bor L?n?rt wrote: > I don't want to check if rcpt domain is mine (I have no "own" domains on > this MTA). I want to accept everything if sender is authenticated, since > it's a mail submit MTA, users can submit mails through it. > > I don't need reject_unauth_destination, since every destination is valid :) > [ok, for sure non-existing or non-fqdn domain is not, also I have an SQL > based bann list for "bad ones" both for senders and rcpts as you can see > later with the banned_* sql tables) For submission: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject Then feel free to implement other checks in the sender restrictions if that's easier to understand. -- Viktor.
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 12:56:41PM -0400, Victor Duchovni wrote: > On Thu, Apr 07, 2011 at 06:42:22PM +0200, G?bor L?n?rt wrote: > > > On Thu, Apr 07, 2011 at 12:20:51PM -0400, Victor Duchovni wrote: > > > On Thu, Apr 07, 2011 at 05:57:24PM +0200, G?bor L?n?rt wrote: > > > > > > > > Instead, Postfix requires that you have one or more of (reject, > > > > > reject_unauth_destination, etc.) SOMEWHERE in > > > > > sender_recipient_restrictions. > > > > > > > > I have the needed rejects at the sender, but not at the recipient, > > > > because I > > > > have the idea that if I reject "unwanted" things at the sender, I am > > > > safe > > > > not to do the same restrictions at the recipient restrictions. > > > > > > You are confused. The above is simply wrong. Either the timing is > > > identical for both checks, and you gain nothing, or critical data (the > > > recipient domain) is missing at sender stage (if smtpd_delay_reject=no, > > > which is not recommended). > > > > I meant that I rejected everything at the sender restrictions which are > > based on information available at sender or maybe even earlier. Of course, > > information like recipient based things can't be rejected at the sender, > > it's done at the recipient. > > That's not how it works. Either you can't validate that the recipient domain > is yours and you are not relaying, because the check is at "MAIL FROM:" > (smtpd_delay_reject = no, which is not recommended), or else, you can make I don't want to check if rcpt domain is mine (I have no "own" domains on this MTA). I want to accept everything if sender is authenticated, since it's a mail submit MTA, users can submit mails through it. Anyway it works now, I've tested,But I am also sure that I will modify this according your (plural "your") recommendations, since I don't want to make something "very ugly". > the check in the sender-restrictions, but "reject_unath_destination" really > belongs in the "recipient" checks, and your configuration is unnecessarily > twisted. Just move all the checks to the recipient restrictions. I don't need reject_unauth_destination, since every destination is valid :) [ok, for sure non-existing or non-fqdn domain is not, also I have an SQL based bann list for "bad ones" both for senders and rcpts as you can see later with the banned_* sql tables) > > > Ok, I've tried to do what I want (it seems to work ... but hmmm), the > > important part: > > > > smtpd_sender_restrictions = > > reject_unauth_pipelining, > > reject_non_fqdn_sender, > > reject_unknown_sender_domain, > > check_sender_access pcre:/etc/postfix/check_address_syntax.pcre, > > check_sender_access mysql:/etc/postfix/banned_senders.sql, > > check_sender_mx_access cidr:/etc/postfix/mx_access.cidr, > > permit_sasl_authenticated, > > reject_invalid_helo_hostname, > > reject_non_fqdn_helo_hostname, > > reject_unknown_helo_hostname, > > check_client_access cidr:/etc/postfix/ip_based_relay.cidr, > > check_client_access ldap:/etc/postfix/ip_based_relay.ldap, > > reject > > smtpd_recipient_restrictions = > > reject_unauth_pipelining, > > reject_non_fqdn_recipient, > > reject_unknown_recipient_domain, > > check_recipient_access pcre:/etc/postfix/check_address_syntax.pcre, > > check_recipient_access mysql:/etc/postfix/banned_rcpts.sql, > > check_recipient_mx_access cidr:/etc/postfix/mx_access.cidr, > > check_recipient_access static:OK, > > reject > > This is a broken open relay. Which domains are yours? Where is the Sorry, I can't see your point here. Why would it be open relay? Only authenticated users can send mails (as you can see in my config, "permit_sasl_authenticated" then if not authenticated, it will be rejected at the end of sender restrictions, _if_ ip_based_relay ldap or cidr table does not contain an OK result when the sender is permitted to send) Open relay - as far as I know - means that _anybody_ can send through it for any rcpts. For sure a mail submission MTA is not far from it :) only the major difference that client MTA/MUA have to authenticate itself somehow, like with ESMTP auth, or it's allowed by its IP. Or have you seen something wrong about the config above which makes it open relay really? I've tested this, users who does not smtp authenticate, and have no IP based access set in my ip_based_relay cidr and ldap tables got "rejected" so I can't see how it can be open relay, but please tell me if I am wrong somewhere, it's better to know than not :) > reject_unauth_destination check? I have no domains. This is a mail submit system as I've told. So I "have to accept" any recipients if the sender authenticated himself either with SMTP authentication or his IP is allowed to relay. This MTA has no local, virtual users, also mydestination is empty ... Anyway, meanwhile I've tested my theory, and it worke
Re: no reject in smtpd_recipient_restrictions?
On 4/7/2011 11:00 AM, Gábor Lénárt wrote: On Thu, Apr 07, 2011 at 10:40:28AM -0500, Noel Jones wrote: [...] Use instead: smtpd_recipient_restrictions = permit_sasl_authenticated, reject The overhead is negligible -- just check an internal status flag, about the same as your fake table lookup -- and may save you from an embarrassing accident. Yes, I have the same idea, however I need not only sasl authenticated users to accept but some others too, "authenticated" by their IPs, and it involves ldap, mysql and cidr tables too, since I have different systems (not my choice!) to need to check. If I already check those at sender restricitons, I guess it's safe to say that everything is OK. At the other hand, to be "really safe and not so ugly" I would need to do these again at recipient restrictions, which would need some measurable overhead anyway. Or maybe not, and I am just too nervous about those "overhead" and "resources" :) thanks for you answer, - Gábor Please ignore my previous answer -- you didn't supply complete information rendering my advice incorrect. Repeat your checks in smtpd_recipient_restrictions -- or even better, move them. The cidr table access time will be negligible if it contains less than a few thousand lines, and you should be using proxy:ldap:... for your all your ldap lookups, which will improve performance and scalability. See the the proxymap documentation http://www.postfix.org/proxymap.8.html Using "smtpd_delay_reject = no" is not recommended. Don't do that unless you have a full understanding of the implications and are willing to suffer the consequences. And pay attention to what Viktor and Wietse tell you. -- Noel Jones
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 06:42:22PM +0200, G?bor L?n?rt wrote: > On Thu, Apr 07, 2011 at 12:20:51PM -0400, Victor Duchovni wrote: > > On Thu, Apr 07, 2011 at 05:57:24PM +0200, G?bor L?n?rt wrote: > > > > > > Instead, Postfix requires that you have one or more of (reject, > > > > reject_unauth_destination, etc.) SOMEWHERE in > > > > sender_recipient_restrictions. > > > > > > I have the needed rejects at the sender, but not at the recipient, > > > because I > > > have the idea that if I reject "unwanted" things at the sender, I am safe > > > not to do the same restrictions at the recipient restrictions. > > > > You are confused. The above is simply wrong. Either the timing is > > identical for both checks, and you gain nothing, or critical data (the > > recipient domain) is missing at sender stage (if smtpd_delay_reject=no, > > which is not recommended). > > I meant that I rejected everything at the sender restrictions which are > based on information available at sender or maybe even earlier. Of course, > information like recipient based things can't be rejected at the sender, > it's done at the recipient. That's not how it works. Either you can't validate that the recipient domain is yours and you are not relaying, because the check is at "MAIL FROM:" (smtpd_delay_reject = no, which is not recommended), or else, you can make the check in the sender-restrictions, but "reject_unath_destination" really belongs in the "recipient" checks, and your configuration is unnecessarily twisted. Just move all the checks to the recipient restrictions. > Ok, I've tried to do what I want (it seems to work ... but hmmm), the > important part: > > smtpd_sender_restrictions = > reject_unauth_pipelining, > reject_non_fqdn_sender, > reject_unknown_sender_domain, > check_sender_access pcre:/etc/postfix/check_address_syntax.pcre, > check_sender_access mysql:/etc/postfix/banned_senders.sql, > check_sender_mx_access cidr:/etc/postfix/mx_access.cidr, > permit_sasl_authenticated, > reject_invalid_helo_hostname, > reject_non_fqdn_helo_hostname, > reject_unknown_helo_hostname, > check_client_access cidr:/etc/postfix/ip_based_relay.cidr, > check_client_access ldap:/etc/postfix/ip_based_relay.ldap, > reject > smtpd_recipient_restrictions = > reject_unauth_pipelining, > reject_non_fqdn_recipient, > reject_unknown_recipient_domain, > check_recipient_access pcre:/etc/postfix/check_address_syntax.pcre, > check_recipient_access mysql:/etc/postfix/banned_rcpts.sql, > check_recipient_mx_access cidr:/etc/postfix/mx_access.cidr, > check_recipient_access static:OK, > reject This is a broken open relay. Which domains are yours? Where is the reject_unauth_destination check? -- Viktor.
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 12:20:51PM -0400, Victor Duchovni wrote: > On Thu, Apr 07, 2011 at 05:57:24PM +0200, G?bor L?n?rt wrote: > > > > Instead, Postfix requires that you have one or more of (reject, > > > reject_unauth_destination, etc.) SOMEWHERE in > > > sender_recipient_restrictions. > > > > I have the needed rejects at the sender, but not at the recipient, because I > > have the idea that if I reject "unwanted" things at the sender, I am safe > > not to do the same restrictions at the recipient restrictions. > > You are confused. The above is simply wrong. Either the timing is > identical for both checks, and you gain nothing, or critical data (the > recipient domain) is missing at sender stage (if smtpd_delay_reject=no, > which is not recommended). I meant that I rejected everything at the sender restrictions which are based on information available at sender or maybe even earlier. Of course, information like recipient based things can't be rejected at the sender, it's done at the recipient. Ok, I've tried to do what I want (it seems to work ... but hmmm), the important part: smtpd_sender_restrictions = reject_unauth_pipelining, reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_access pcre:/etc/postfix/check_address_syntax.pcre, check_sender_access mysql:/etc/postfix/banned_senders.sql, check_sender_mx_access cidr:/etc/postfix/mx_access.cidr, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, check_client_access cidr:/etc/postfix/ip_based_relay.cidr, check_client_access ldap:/etc/postfix/ip_based_relay.ldap, reject smtpd_recipient_restrictions = reject_unauth_pipelining, reject_non_fqdn_recipient, reject_unknown_recipient_domain, check_recipient_access pcre:/etc/postfix/check_address_syntax.pcre, check_recipient_access mysql:/etc/postfix/banned_rcpts.sql, check_recipient_mx_access cidr:/etc/postfix/mx_access.cidr, check_recipient_access static:OK, reject Here, I want a setup which rejects things as soon as possible (of course recipient based things can't be rejected as the sender), I would have sasl authenticated users and also some others who can go given by their IPs: for those, stricted helo checks are needed too. What I meant, that if I want to be "not so ugly, I should have these instead of that ugly static:OK and reject, at the end of smtpd_recipient_restrictions too: permit_sasl_authenticated, check_client_access cidr:/etc/postfix/ip_based_relay.cidr, check_client_access ldap:/etc/postfix/ip_based_relay.ldap, reject So I basically duplicate these steps then which is already done in smtpd_sender_restrictions too. Or maybe, I should not be so nervous (as I've mentioned) and do those checks _only_ at smtpd_recipient_restrictions so I don't need to worry about this issue, however then my goal (which can be odd, anyway) fails that I want to reject things as soon as possible (to be honest, the previous system acts this way, and to minimalize noticable changes I wanted to do a postfix based solution which acts as close as possible to the old solution, so users won't notice too much changes). And I am also wondering why there is "smtpd_sender_restrictions" exits in postfix when very checks could be done later too because sender etc based checks are possible at smtpd_recipient_restrictions too, and also smtpd_delay_reject=no is not recommended, as you told But I believe all of you, maybe I should not complicate things which can cause problems for other admins later, or maybe newer postfix releases in the future etc etc etc. Thanks to all for the opinions about the issue! > > The whole > > issue is because I want to reject things as soon as possible (heavy > > traffic), > > Premature optimization is the root of all evil. that seems to be true :)
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 05:57:24PM +0200, G?bor L?n?rt wrote: > > Instead, Postfix requires that you have one or more of (reject, > > reject_unauth_destination, etc.) SOMEWHERE in > > sender_recipient_restrictions. > > I have the needed rejects at the sender, but not at the recipient, because I > have the idea that if I reject "unwanted" things at the sender, I am safe > not to do the same restrictions at the recipient restrictions. You are confused. The above is simply wrong. Either the timing is identical for both checks, and you gain nothing, or critical data (the recipient domain) is missing at sender stage (if smtpd_delay_reject=no, which is not recommended). > The whole > issue is because I want to reject things as soon as possible (heavy > traffic), Premature optimization is the root of all evil. -- Viktor.
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 10:40:28AM -0500, Noel Jones wrote: [...] > Use instead: > smtpd_recipient_restrictions = > permit_sasl_authenticated, > reject > > The overhead is negligible -- just check an internal status flag, > about the same as your fake table lookup -- and may save you from an > embarrassing accident. Yes, I have the same idea, however I need not only sasl authenticated users to accept but some others too, "authenticated" by their IPs, and it involves ldap, mysql and cidr tables too, since I have different systems (not my choice!) to need to check. If I already check those at sender restricitons, I guess it's safe to say that everything is OK. At the other hand, to be "really safe and not so ugly" I would need to do these again at recipient restrictions, which would need some measurable overhead anyway. Or maybe not, and I am just too nervous about those "overhead" and "resources" :) thanks for you answer, - Gábor
Re: no reject in smtpd_recipient_restrictions?
On Thu, Apr 07, 2011 at 11:43:55AM -0400, Wietse Venema wrote: > G�bor L�n�rt: > > Hi, > > > > I have the idea to simply put "permit" at the end of > > smtpd_recipient_restrictions. No, I don't want open relay :) but I do all > > the checks to make it secure in sender_recipient_restrictions. Postfix > > nicely wants to change my mind about this idea. So my question that: > > You have not understood what Postfix requires. > > Postfix does not care what you put AT THE END of > sender_recipient_restrictions. > > Instead, Postfix requires that you have one or more of (reject, > reject_unauth_destination, etc.) SOMEWHERE in > sender_recipient_restrictions. I have the needed rejects at the sender, but not at the recipient, because I have the idea that if I reject "unwanted" things at the sender, I am safe not to do the same restrictions at the recipient restrictions. The whole issue is because I want to reject things as soon as possible (heavy traffic), so I would accept sasl authenticated users at sender restrictions, also some clients by IP and yes, then reject for the rest. But why I need to do this again at recipient restriction, when I've already did at sender? As far as I can guess, you can't do RCPT TO before giving valid and accepted MAIL FROM, so my theory is safe, but I am not 100% sure. Anyway what I can do to be "not so tricky" to do the same checks (permit_sasl_authenticated and by IP too) again in recipient restrictions _too_, but then I do the same checks at sender and recipient (or even more if I have more recipients) which involves ldap, mysql and a cidr table lookup too (as I have different data sources I need to check). Surely, I don't want to argue with you, I am only curious that my solution is secure at all to use, I can do my theory (I think) if I use static:OK, reject at recipient to make postfix feel nice about my restrictions, but it's ugly and maybe not secure either? thanks!
Re: no reject in smtpd_recipient_restrictions?
G?bor L?n?rt: > Hi, > > I have the idea to simply put "permit" at the end of > smtpd_recipient_restrictions. No, I don't want open relay :) but I do all > the checks to make it secure in sender_recipient_restrictions. Postfix > nicely wants to change my mind about this idea. So my question that: You have not understood what Postfix requires. Postfix does not care what you put AT THE END of sender_recipient_restrictions. Instead, Postfix requires that you have one or more of (reject, reject_unauth_destination, etc.) SOMEWHERE in sender_recipient_restrictions. Wietse
Re: no reject in smtpd_recipient_restrictions?
On 4/7/2011 10:29 AM, Gábor Lénárt wrote: Hi, I have the idea to simply put "permit" at the end of smtpd_recipient_restrictions. No, I don't want open relay :) but I do all the checks to make it secure in sender_recipient_restrictions. Postfix nicely wants to change my mind about this idea. So my question that: is it safe to do what I want to do, _IF_ I am sure I did every possible checks&rejects in sender_recipient_restrictions (or before)? I plan to use permit_sasl_authenticated and reject in sender_recipient_restrictions. Or should I repeat that step in sender_recipient_restrictions too then? I'm using smtpd_delay_reject = no if it counts. Just I have the idea that using permit_sasl_authenticated (and also some other checks like IP based relay given by ldap map) here too makes overhead: why should I do the same steps (and at every RCPT TO: given!) again what I've already done at a previous stage of SMTP protocol? It's a mail submit server. I can't provide exact configuration since I am about doing it right now, just I am curious about your opinion on this issue. I may use "check_recipient_access static:OK, reject" at the end of smtpd_recipient_restrictions to trick postfix do not complain that I don't want to use reject at the end of smtpd_recipient_restrictions :) Thanks a lot in advance, - Gábor Use instead: smtpd_recipient_restrictions = permit_sasl_authenticated, reject The overhead is negligible -- just check an internal status flag, about the same as your fake table lookup -- and may save you from an embarrassing accident. -- Noel Jones
