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 :)
