On 23 Dec 2015, at 13:53, Alex wrote: [...]
Okay, I understand. So if the list wasn't also included in smtpd_sender_restrictions, would it have been rejected there, due to the reject_unknown_sender_domain at the end?
Yes.
How can I get around the duplication?
If you don't duplicate rejection rules then you don't need to duplicate map rules to exempt special cases from them.
One of the reasons I separated the restrictions was to avoid the problem of too permissive access.
I can see why: if your check_sender_access whitelist is in smtpd_recipient_restrictions, it whitelists against every rule following it in smtpd_recipient_restrictions, based on an arbitrarily forgeable sender domain. Using a magically bogus sender domain would become a free relay pass.
Should I just expect to duplicate the check_*_access using the same lists to solve this?
No. You only need to duplicate whitelisting if you duplicate rejection, and there is a risk of opening loopholes if you put whitelisting maps for client/helo/sender rejections into smtpd_recipient_restrictions. So: remove reject_unknown_sender_domain from smtpd_recipient_restrictions, leave smtpd_sender_restrictions intact as-is.
General rule: If you want to use a reject_* rule but also need a whitelist exempting special cases from that rule, put the rejection rule immediately after its whitelist map in the earliest legal rejection list for that rejection rule, as far down as possible.
If it would be best to combine the restrictions, can you suggest how I might do that?
Don't try to use a single unified restriction list in smtpd_recipient_restrictions if you use maps based on client, helo, or sender values to exempt specific violators only from reject_* rules that apply to the same values. You need to be very careful about using any maps that act as whitelists in smtpd_recipient_restrictions; you can order rules there to get complexity that can't be set up elsewhere, but it is risky.
