Hi,

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

Isn't this effectively what I already have? I must be missing
differences somewhere?

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 milter_macro_daemon_name=ORIGINATING
  -o syslog_name=postfix/submission

127.0.0.1:10025 inet n    -       n       -       -     smtpd
    -o content_filter=
    -o smtpd_delay_reject=no
    -o smtpd_client_restrictions=permit_mynetworks,reject
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o smtpd_data_restrictions=reject_unauth_pipelining
    -o smtpd_end_of_data_restrictions=
    -o smtpd_restriction_classes=
    -o mynetworks=127.0.0.0/8
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
    -o smtpd_client_connection_count_limit=0
    -o smtpd_client_connection_rate_limit=0
    -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
    -o local_header_rewrite_clients=

Just to be clear, I'm missing no_address_mappings in the
receive_override_options in order to prevent the duplicated always_bcc
mail, correct?

>>>     -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.

You're saying here that the reject_rbl_client at the end of the
smtpd_recipient_restrictions would be skipped because it would be
auth'd by permit_sasl_authenticated, correct?

>> 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.

I think I'm still going to have to do more research on finding that
right default_process value.

Thanks,
Alex

Reply via email to