Hi, > On Jan 22, 2018, at 8:43 AM, Matus UHLAR - fantomas <uh...@fantomas.sk> wrote: > >> smtpd_helo_required = yes >> smtpd_helo_restrictions = permit_mynetworks, >> reject_unauth_pipelining, >> reject_invalid_helo_hostname, >> reject_non_fqdn_helo_hostname, >> check_helo_access hash:/etc/postfix/helo_acl, >> reject_unknown_helo_hostname, >> permit > > I'd put check_helo_access before reject_invalid_helo_hostname and > reject_non_fqdn_helo_hostname, so I could allow some hosts use HELO string > that would otherwise be rejected. > > You can sometimes get a machine with hardcoded and unconfigurable HELO > string.
Ok. The idea behind this was that the only legitimate server I have seen connecting that: a) has a transient reverse DNS lookup problem and b) sometimes passes that but gives a HELO/EHLO hostname that Postfix 3.1.0 rejects is Outlook.com. So for a client restriction I whitelist a client that has a reverse DNS lookup of: outbound.protection.outlook.com permit I then whitelist the EHLO/HELO hostname with the helo_acl list: outbound.protection.outlook.com permit This works regardless of the Outlook.com server connecting as the names partially match (ie: a real Outlook server might be server-1234.outbound.protection.outlook.com, another might be server-5678.outbound.protection.outlook.com and so forth). Is this not a good idea, though ? Also, the last part where you state “You can sometimes get a machine with hard-corded and un-configurable HELO string”, is that you can sometimes get this from a *legitimate* server ? >> smtpd_sender_restrictions = permit_mynetworks, >> reject_unauth_pipelining, >> reject_non_fqdn_sender, >> check_sender_access hash:/etc/postfix/sender_acl, >> reject_unknown_sender_domain, >> permit > > Here I recommend the opposite - putting reject_unknown_sender_domain before > check_sender_access, unless you have sane reason to accept mail from invalid > domains (maybe one like the above). Ah, right - good catch. >> smtpd_recipient_restrictions = permit_mynetworks, >> permit_auth_destination, >> reject >> >> smtpd_relay_restrictions = permit_mynetworks, >> permit_auth_destination, >> reject > > I believe putting "reject_unauth_destination, permit" is better than > "permit_auth_destination, reject", if you put any kind of restrictions in > the future. > > Also, with "reject_unauth_destination" you can skip the default "permit" Ok. One thing that confused me even though it works - why is permitting an authorized destination (either through permit_auth_destination or via reject_unauth_destination), required for relaying if I want people to be able to deliver to recipients at my domain ? If I remove the permission of authorized destinations and if I host mail for say example.com, I cannot receive mail for whoe...@example.com without the permission of authorized destinations for smtpd_relay_restrictions. I tested this by sending mail to whoe...@example.com and it would reject it without this permission. Thanks again, - J
