On 21.01.18 00:56, J Doe wrote:
I have a basic SMTP server set up with what I believe to be good smtpd_*_
restrictions, but I was wondering if anyone could provide any insight on
how to improve them or if I have been redundant in the restrictions. Even
with reading the man pages, I find some of the restrictions tricky.
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.
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).
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"
On 21.01.18 14:35, Noel Jones wrote:
smtpd_client_restrictions = permit_mynetworks,
reject_unauth_pipelining,
check_client_access hash:/etc/postfix/client_acl,
reject_unknown_client_hostname,
permit
reject_unknown_client_hostname is likely to reject legit mail. Use
with caution.
Consider instead using reject_unknown_reverse_client_hostname, which
rejects clients with no PTR record. This is similar to what many
large providers do and is fairly low risk.
I think that reject_unknown_reverse_client_hostname is not a good idea -
having fake/invalid PTR record is imho worse than than no PTR record.
check_client_access before it (either one) is proper way to configure local
whitelists.
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
reject_unknown_helo_hostname is likely to reject legit mail. Use
with caution.
I believe the same as above applies.
On 21.01.18 17:44, li...@lazygranch.com wrote:
Doing some reading on the PTR record, I believe I've have been doing my
MX record incorrectly. The reverse DNS can only point to one domain
name.
incorrect - IP can have multiple PTR records, although it's not recommended.
- single PTR is more safe, because you need only care about one reverse
(and forward) DNS record.
If you are hosting multiple domains on one server, all MX records
should point to the domain name that has the PTR record.
Incorrect.
The only case multiple MX should point to the same hostname is when using
SSL/TLS certificate, and in such case all MX records should point to hostname
in the certificate - not to the contents of PTR record.
Note that using SSL/TLS between servers is not widespread and I don't know
of client rejecting delivery to server with mismatched certificate
simply said:
The PTR record has NOTHING in common with MX records.
I have already encountered cases, where people were doing stupid things to
fullfill this "requirement". This is one of things nice to have, but other
things may be more important than this one.
As an aside, note the superfluous "permit" shows up in many guides
online, but not all of them. I experimented dropping the extra permit
and things worked, but put them back in anyway out of paranoia. I'm
going to drop them now.
the "permit" is default (implicit) for most (if not all) of the directives.
As its description says:
permit
Permit the request. This restriction is useful at the end of a
restriction list, to make the default policy explicit.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows found: (R)emove, (E)rase, (D)elete
