I thought I'd toss this out for discussion rather than just filing a bug and patch. (@florian030) Currently when enabling reject_sender_login_mismatch, what actually gets set is reject_authenticated_sender_login_mismatch, a weaker variant that only applies when the sender is authenticated. Ie. right now, your own authenticated users cannot forge the sender address, but any unauthenticated mail from the internet can. (spm/dkim aside, etc....) There are not many use cases when reject_authenticated_sender_login_mismatch is truely useful, where reject_sender_login_mismatch would not be more appropriate. We used it many years ago when transitioning from unauthenticated setups (eg. pop-before-smtp, prior to sasl) to using authentication, and you want to improve sender restrictions without affecting those users who have not transitioned yet. Other than that, it probably covers some lazy/poorly configured setups and a few corner cases where you both can't use sasl and can't set a correct sender address (maybe an old printer or something ... I don't have any actual examples, only contrived possibilities). So, there's very little reason to use it, it should really be changed to reject_sender_login_mismatch. Is there any opposition to doing so? Anyone who relies on the 'authenticated' version now could simply turn it off, though of course there's no way to determine who that would be automatically (most systems would want reject_sender_login_mismatch on).
Having wondered about this today (a setting that I had unchecked by default), I certainly agree with your reasoning. I see that currently (a year or so after this discussion was started), ISPConfig3 sets both. I guess that's by design?
