Hi,
>>> -o smtpd_recipient_restrictions=permit_mynetworks,reject
>
>> Isn't this effectively what I already have? I must be missing
>> differences somewhere?
>
> You're missing a recipient_restrictions override. Without one, your
> submission connections are subject to dnsbl checks when auth fails.
> This is why you saw that ZEN rejection. You should _never_ check
> submission connections against dnsbls. ZEN contains the PBL, which
> contains consumer dynamic IP ranges.
Yes, understood, and I didn't realize I was doing that.
I've also just heard back from the user, and her laptop was set to
port 25, not 587, which explains why all her email wasn't being
rejected. Only the mail that was sent when she was a road warrior and
not on one of the trusted networks from mynetworks.
Although not using the submission port seems to be the root of the
issue, my submission entry in master.cf is now this:
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 receive_override_options=$submission_overrides
-o syslog_name=postfix/submission
And have added
submission_overrides = no_unknown_recipient_checks,
no_address_mappings, no_header_body_checks
as per rob0's recommendation. Can you confirm this is correct?
>> 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
>
>> 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?
>
> I'm not sure on that one. Someone else will need to chime in.
Should I post something separate for this?
>> I think I'm still going to have to do more research on finding that
>> right default_process value.
>
> There is a problem here. You have found a knob you can turn and get
> something like the result you want. But, this is not the right knob to
> be turning to address your load problem because it simply masks the real
> problem.
Yes, I'm now working on addressing the bulk mailer issue, and have
adjusted the process limit back to the default.
> Thus, the permanent solution is to dramatically slow down the bulk
> mailers. I've given you one method in the previous email that should do
> exactly that, instantly, while keeping default_process_limit=100.
Yes, that is what I've been trying to do all along!
Thanks again,
Alex
