Bug 38292 - check HELO string against reverse DNS entry
check HELO string against reverse DNS entry
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Mail
UCS 4.0
Other Linux
: P5 normal (vote)
: UCS 4.0-2-errata
Assigned To: Daniel Tröder
Sönke Schwardt-Krummrich
:
Depends on:
Blocks: 38948
  Show dependency treegraph
 
Reported: 2015-04-17 14:17 CEST by Sönke Schwardt-Krummrich
Modified: 2015-07-28 15:50 CEST (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sönke Schwardt-Krummrich univentionstaff 2015-04-17 14:17:43 CEST
Postfix should check the HELO string against the reverse DNS entry.
The feature should be configurable via a UCR variable.
Comment 1 Daniel Tröder univentionstaff 2015-05-04 19:50:21 CEST
Created UCR variables 
* mail/postfix/smtpd/restrictions/sender/require_reverse_dns and
* mail/postfix/smtpd/restrictions/sender/require_forward-confirmed_reverse_dns
for weaker and stricter rDNS checking respectively.
They enable the Postfix options
* reject_unknown_reverse_client_hostname (http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname) and
* reject_unknown_client_hostname (http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname).
Both UCR variables are booleans and unset by default.

Commit: r60366
Package: mail/univention-mail-postfix
YAML: 2015-04-16-univention-mail-postfix.yaml
Comment 2 Sönke Schwardt-Krummrich univentionstaff 2015-05-06 18:00:27 CEST
We should discuss this patch:
- I do not like variable names that do not match with the postfix option name
  (confuses users)
- injecting recipient restrictions at a fixed position is IMHO a bad idea, 
  because the order might change and in projects the ids 60 and 61 may be already 
  in use or inappropriate.
- postfix delays the evaluation of sender, client, ... restrictions just before 
  DATA to prevent problems with broken SMTP clients. All rules in sender, client 
  and ... restrictions may also be used in recipient restrictions. So why not add 
  all rules to recipient restrictions as this would extremely simplify the 
  ruleset.
Comment 3 Daniel Tröder univentionstaff 2015-05-06 18:31:19 CEST
- IMO the postfix variable names are just bad (non-descriptive), but I share the thought about confusing UCRV names and will rename them; is also more consistent.
- They could also be appended at the end. It's just that the Postfix documentation [1] said to put the after reject_unauth_destination, which is currently at 50. I propose to rewrite the template code to make those UCRV always appear directly after reject_unauth_destination, independently of its order number (and after others, if they occupy that position already).
- Delayed evaluation is on, but the evaluation of restrictions still happens in the correct order. There can be problems [1] with the wrong order, although these two options can do no harm.

[1] http://www.postfix.org/SMTPD_ACCESS_README.html#danger
Comment 4 Daniel Tröder univentionstaff 2015-05-07 12:42:35 CEST
For 4.0-2 all changes were reverted in 60516.
Comment 5 Daniel Tröder univentionstaff 2015-07-14 17:58:20 CEST
Commit 62110 introduces the UCRVs
* mail/postfix/smtpd/restrictions/sender/reject_unknown_client_hostname
* mail/postfix/smtpd/restrictions/sender/reject_unknown_reverse_client_hostname

They are added to smtpd_recipient_restrictions after reject_unauth_destination (position is calculated dynamically).
Comment 6 Daniel Tröder univentionstaff 2015-07-23 15:39:51 CEST
YAML: 2015-07-17-univention-mail-postfix.yaml (r62372)
Comment 7 Daniel Tröder univentionstaff 2015-07-23 16:30:47 CEST
Commit 62377 modified the smtp_restrictions sorting code to be safer (with numbers >99).
YAML with new build number in 62379.
Comment 8 Sönke Schwardt-Krummrich univentionstaff 2015-07-27 12:51:19 CEST
OK: YAML
OK: code change
OK: functional test
Comment 9 Janek Walkenhorst univentionstaff 2015-07-28 15:50:31 CEST
<http://errata.univention.de/ucs/4.0/263.html>