Demi M. Obenour:
> > BTW I realized that I swapped the semantics of smtpd_sender_login_maps
> > (a mapping from sender address to the login names that are allowed
> > to use that sender address) when we were discussing the postdrop
> > feature (a mapping from login name to the sender addresses that the
> > login name is allowed to use).
> >
> > If we stick with that model, then I think that the feature should be
> > renamed to local_login_sender_maps.
>
> I agree, although I wonder if it is better to be consistent and
> change the semantics to match those of smtpd_sender_login_maps.
> local_login_sender_maps was easier to implement and seemed more
> intuitive, but it is less consistent than local_sender_login_maps,
> which can in some cases be set as
>
> local_sender_login_maps = $smtpd_sender_login_maps
This is not obviously right. In fact, I could argue for the opposite:
local_login_sender_maps = $smtpd_login_sender_maps
smtpd_sender_login_maps pre-dates the Postfix submission services
(submission + smtps) by three years. It solved a problem for an
SMTP server that receives authenticated and unauthenticated messages
on the same port. In that setting, the sender address had to be the
search key for policy lookup.
In contrast, postdrop always knows a user ID; there is no legitimate
way to invoke postdrop anonymously. With the Postfix submission
services, SMTP submission has become more similar to postdrop
submission: Postfix always knows a user identity, thus the user
identity can become the search key for policy lookup. For the port
25 MTA-to-MTA service one can then reject all mail from a remote
site that claims to be from a local user.
Wietse
