On 3/6/2012 2:25 PM, /dev/rob0 wrote:
> On Tue, Mar 06, 2012 at 01:30:59PM -0600, Stan Hoeppner wrote:
>> On 3/6/2012 11:03 AM, Alex wrote:
>>
>>> --master.cf--
>>> submission inet n - n - - smtpd
>>> -o smtpd_tls_security_level=encrypt
>>> -o smtpd_sasl_auth_enable=yes
>>> -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>>
>> -o smtpd_recipient_restrictions=
>
> This will not work; smtpd_recipient_restrictions is required. See my
> earlier post for a workable solution.
Yeah, I forgot you have to specify at least one. Should have checked my
own config. I was responding to your earlier post--I wouldn't think it
should require anything that complex in main.cf just to set recipient
restrictions for the submission daemon. I don't recall seeing such a
setup mentioned here before anyway. FWIW I don't use auth for
submission, but do have a submission service for internal users
(external access is via webmail).
10125 inet n - - - - smtpd
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o receive_override_options=no_unknown_recipient_checks,\
no_address_mappings,no_header_body_checks
> http://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions
>
>> -o smtpd_sender_restrictions=
>> -o smtpd_helo_restrictions=
>>
>>> -o milter_macro_daemon_name=ORIGINATING
>>
>> BTW, adding the above lines will fix your current problem. They
>
> Not if/when the client fails to authenticate, which given the
> evidence presented, is the only conclusion I can see. (Another
> possibility: incomplete or inaccurate evidence was presented.)
Ahh good point. If auth occurred then the dnsbl check shouldn't have
triggered. I made the mistake of taking the OP's report at face value
and assumed the problem was the dnsbl check in the submission service.
>> Rob, see the recent thread titled "Delay before initial 220
>> greeting". There's more in play in this OP's case WRT dnsbl
>> queries. In his case it might be better to increase the 2s timeout
>> (if possible) to prevent additional smtpds from spawning.
>
> I saw that thread, but didn't have time to comment on it. I still
> believe that the relatively minor cost of a redundant DNSBL lookup is
> worthwhile. It's not going to cause any additional smtpd, and in the
> vast majority of cases, it will take very little extra time or CPU.
He had to increase default_process_limit to 300 so clients wouldn't
delay. 300 smtpds is excessive, and expensive. His pushing all dnsbl
checks into Postscreen apparently substantially decreased the number of
smtpds he needed--exactly what it's supposed to do.
If dns times out during postscreen and the response comes in before the
smtpd dnsbl check, he's still got excessive smtpd processes spawning
only to kill connections, which is counter intuitive here. Your
"layered" defense is sound for most systems. In this case it would be
better to increase the 2s timeout so postscreen is able to do its job
rather than to spawn more smtpds to accomplish the same.
> In the event of DNS SERVFAIL responses or timeouts, it can add some
> more time and stress, but that suggests a problem with the resolver
> and/or the DNSBL. I take the risk anyway.
In the OP's case it's none of the above. It was apparently simply a
connection load issue and using dnsbl checks within smtpd.
--
Stan
