On Mon, Sep 16, 2013 at 10:19:14AM -0400, Wietse Venema wrote:
> > Perhaps:
> >
> > reject_restricted_sender_misuse
> >
> > Patch below, potentially subject to replacement of the above name with
> > something more obvious.
>
> Bah, you solved the easy part of the problem :-)
Yes, I know. The feature is small, just a couple of lines of code
and related documentation updates. Indeed choosing a new name is
the main problem. With either of:
reject_authenticated_sender_login_conflict
reject_authenticated_sender_login_maps_conflict
it is not clear to me why "conflict" allows unowned senders and
mistmatch does not. I think these are too similar to the name
of the existing features. My proposal focuses on the new task
of restricting selected sender addresses to designated authenticated
users, rather than restricting authenticated users to designated
addresses (be it via a table from addresses -> owners).
So I think putting "sender" first and indicating that *only*
listed senders are in scope makes sense:
reject_restricted_sender_wrong_login
this should likely automatically imply reject_unauth_sender_login_mismatch
(to protect said restricted sender addresses from misuse when the
client does not authenticate). (Thus a small change in the proposed code).
--
Viktor.
