Paul Bruce
20 years ago
Hi,
I just wanted to clarify one thing about how the smtpd_helo_restrictions
worked.
The front line for me against spam is encapsulated in the following
settings - this works fairly well....
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access,
reject_rbl_client relays.ordb.org
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
hash:/etc/postfix/helo_access, reject_unknown_hostname
smtpd_delay_reject = yes
unknown_virtual_alias_reject_code = 550
disable_vrfy_command = yes
However, some badly configured real smtp servers around the place have been
caught out - this is no real issue for me, because I simply tell them (in
the nicest possible way) that the people setting up their mail servers must
be a bunch of mugs because even my home mail sitting on my kitchen bench
gets through this maze.
One of these mugs needed an explanation and I happily went about explaning
what my mail server does at the frontline to prevent spaming. Tonight I've
been doing some more confiuration and more testing (uno.. the "one more
compile" type of thing) However during my testing I came out with an amazing
realisation - what I thought was happening was not happening.
This is what I thought was happening
1) My server requires HELO, were the remote machine kindly sends it name
2) my server already knows the IP address of the remote machine talking to
it
3) My server resolves the name given to it in the HELO request at step 1
4) if the resolved IP does not equal the known ip in step 2, then the helo
fails and transmission does not continue.
Sweet, That seemed like a really sensible and fail safe setup.
But I discovered (through testing - or insufficient reading, or more
possibly insufficient intelligence) that the real case is
1) My server requires HELO,
2) my server already knows the IP address of the remote machine talking to
it
3) My server resolves the name given to it in the HELO request at step 1
4) My server doesn't give two hoots whether the IPs equal, just so long as
the helo resolves to an ip, it is happy.
That seems a little silly to me, and all my helo reading doesn't seem to
help me.
I'm missing something here and if someone could point me in the right
direction I'd be greatly appreciative.
Thanks
Paul
I just wanted to clarify one thing about how the smtpd_helo_restrictions
worked.
The front line for me against spam is encapsulated in the following
settings - this works fairly well....
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access,
reject_rbl_client relays.ordb.org
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, check_helo_access
hash:/etc/postfix/helo_access, reject_unknown_hostname
smtpd_delay_reject = yes
unknown_virtual_alias_reject_code = 550
disable_vrfy_command = yes
However, some badly configured real smtp servers around the place have been
caught out - this is no real issue for me, because I simply tell them (in
the nicest possible way) that the people setting up their mail servers must
be a bunch of mugs because even my home mail sitting on my kitchen bench
gets through this maze.
One of these mugs needed an explanation and I happily went about explaning
what my mail server does at the frontline to prevent spaming. Tonight I've
been doing some more confiuration and more testing (uno.. the "one more
compile" type of thing) However during my testing I came out with an amazing
realisation - what I thought was happening was not happening.
This is what I thought was happening
1) My server requires HELO, were the remote machine kindly sends it name
2) my server already knows the IP address of the remote machine talking to
it
3) My server resolves the name given to it in the HELO request at step 1
4) if the resolved IP does not equal the known ip in step 2, then the helo
fails and transmission does not continue.
Sweet, That seemed like a really sensible and fail safe setup.
But I discovered (through testing - or insufficient reading, or more
possibly insufficient intelligence) that the real case is
1) My server requires HELO,
2) my server already knows the IP address of the remote machine talking to
it
3) My server resolves the name given to it in the HELO request at step 1
4) My server doesn't give two hoots whether the IPs equal, just so long as
the helo resolves to an ip, it is happy.
That seems a little silly to me, and all my helo reading doesn't seem to
help me.
I'm missing something here and if someone could point me in the right
direction I'd be greatly appreciative.
Thanks
Paul