Home / user-489319

glts's questions

Martin Hope
glts
Asked: 2021-05-18 04:36:17 +0800 CST
  • 2

One of the mechanisms in SPF is ptr. This mechanism checks that a sender using some domain name connects from a (forward-confirmed) IP address pointing to a subdomain of that name.

For example, when sender [email protected] connects from IP address 1.2.3.4, then the ptr mechanism would first do a reverse lookup on 1.2.3.4. If the domain name returned by that lookup (eg mail.example.com) also has IP address 1.2.3.4, and is a subdomain of example.com, then the sender is authorised.

This seems like a useful feature. At the time of writing, the domain yahoo.com uses this mechanism in its SPF records.

However, the SPF specification explicitly discourages using the ptr mechanism (‘SHOULD NOT be published’ [= use may be acceptable in certain circumstances, but only after careful deliberation]). It gives the following explanation:

Note: This mechanism is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers. If used, proper PTR records have to be in place for the domain's hosts and the "ptr" mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience, it has been concluded that it is unnecessary and more reliable alternatives should be used instead.

This explanation seems rather fuzzy to me, or at least not strong enough to completely give up on this useful feature. Why is the mechanism ‘slow’ or ‘not reliable’, and how would it place a ‘large’ burden on name servers? Surely doing one additional DNS lookup in a mail server context cannot be a big issue?

Are there strong, practical reasons for not using ptr, or can it be justified using it despite the RFC text?

spf
Martin Hope
glts
Asked: 2019-04-06 10:50:08 +0800 CST
  • 1

On my Postfix mail server, I would like to redirect local mail sent to root to my virtual mailbox [email protected]. At the same time, I do not want to receive any outside mail at [email protected]. Is such a configuration at all possible?

My motivation is to receive notifications generated by services like Cron conveniently in my inbox at [email protected]. Such notifications usually get sent to user root. I have been able to set up the redirection as desired:

  1. Daemon sends mail to root.
  2. Postfix appends $myorigin (append_at_myorigin = yes, must not be changed).
  3. [email protected] is looked up and mapped through virtual_alias_maps.
  4. Mail is delivered to mailbox [email protected].

However, with this setup anyone can send mail to [email protected]. I’d rather not have this address as a public alias of [email protected]. The behaviour I would like to have:

/etc/postfix/main.cf:

myhostname = mail.my.org
mydomain = my.org
myorigin = /etc/mailname
mydestination = localhost
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth
smtpd_sender_login_maps = $virtual_alias_maps
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = my.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/virtual
alias_maps = hash:/etc/aliases

/etc/mailname:

my.org

/etc/postfix/vmailbox:

[email protected]         [email protected]
[email protected] [email protected]

/etc/postfix/virtual:

[email protected]         [email protected]
[email protected]        [email protected]
[email protected]       [email protected]
[email protected] [email protected]

/etc/aliases:

postmaster: [email protected]
root: [email protected]
postfix