Added reject_authenticated_sender_login_mismatch

[17Halbe]

Kudos to @TechnicLab who had the idea and found that "undesired behaviour"
This will deny authorized clients to send with a different than their owned mail-address.

So there remain some considerations:

• With this in place people may not be sending mails under their aliases as well. (Except they configure an account for every alias(which they would have to do with a normal client program anyway))
• Might their be use cases where someone wants to send mails as a different user?

See also #825
partially solves #524

[johansmitsnl]

@17Halbe looks good!
Does this needs testing for ldap to or is this just the same behaviour?
Does it also work with an alias setup for your account and use it as a sender email?

[TechnicLab]

@17Halbe Thank you! @johansmitsnl It is working for LDAP.

[17Halbe]

Yes I don't see a reason why this shouldn't be working with ldap.
It is comparing the logged in email address with the one sending. If they are identical, the request is granted. This shouldn't make a difference for ldap.

[johansmitsnl]

And for the aliases?

[17Halbe]

Yes, as I said, if root@mailserver.com trys to send an email as (his alias) postmaster@mailserver.com, it would fail.
In that case one has to set a seperate mailaccount for postmaster@mailserver.com up to be able to send mail from postmaster@mailserver.com.
I don't know, does anyone do that?

Receiving mails for your alias of course is not a problem.

In my opinion the behaviour of not allowing someone to send a mail with a spoofed address (even non existing ones) should be default. If someone would need to send an email via an alias, they should actually consider setting this account up as a regular one. IMHO that's not what aliases are for. I always considered them as more restrictive "catch-all" addresses.
How do you use them?

[17Halbe]

I'm still thinking about this. we could probably work around the alias problem if you consider it neccessary. But in that case we would have to add every normal address to the virtual (alias) file as well.
And this would need a special handling for ldap.

[johansmitsnl]

@17Halbe in my personal setup I use on the iPhone mail app and there I have setup some aliasses so that I can email with the same account back but maintain the alias in the reply.
Example:
main account: johan@domain.com
Alias: alias@domain.com
When I reply to a email that arrived on the alias it replies with the alias from and should be valid to me.
If not this might break more then desired on multiple setups.

[17Halbe]

Ok, we then need a setup differenciating between ldap and the standard setup.
I will provide a solution for the standard setup. I‘ll try my best for ldap.
Do we need an exception for mails containing delimiters as well?

[johansmitsnl]

I don't use it but if you can include them yes.

[dmcgrandle]

We have set up our servers internally to send reports from servername@domain.com so the source of the report can easily be identified. All these severs are not set up to receive mail, so they do not have valid accounts in the email system. If suddenly all those reports started being rejected, that would be a problem. If you do decide to make changes like this, please do NOT make them default, and be sure to add a well documented control such as an env variable to allow users to choose which behavior they wish. Regards, :D

…

Sent from my iPhone

On Mar 4, 2018, at 12:05 PM, Johan Smits ***@***.***> wrote: I don't use it but if you can include them yes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[17Halbe]

Just to clarify, this PR is just denying a logged in(!) user to send mails with another than his account address or (going to be implemented) his alias addresses.
Would this work for your setup?

[dmcgrandle]

We have not gotten emails to be sent without logging in a user with smtp. We are currently using a test user login (the same login for multiple servers) as a work around until we are able to determine why our servers can’t simply deliver unauthenticated on port 25 to a local user. While this isn’t a preferred long term solution, I would not like to see this work around permanently denied in the future. We should at least implement an env variable to control this behaviour. :D

…

Sent from my iPhone

On Mar 4, 2018, at 1:56 PM, 17Halbe ***@***.***> wrote: Just to clarify, this PR is just denying a logged in(!) user to send mails with another than his account address or (going to be implemented) his alias addresses. Would this work for your setup? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[17Halbe]

So I introduced a new env variable, which default value is deactivating reject_authenticated_sender_login_mismatch.

For a new upcoming release in the hopefully upcoming release channel system I would suggest to implement reject_authenticated_sender_login_mismatch as a default. It's really easy to delete out of main.cf if one really needs to work around it.
In the end I think most people would agree that sending mails for a different account is wrong. ;)

Tested ldap implementation only in the test.bats. Can someone please check if this would work with an alias in ldap. I just copy pasted the ldap config from #825

bind             = yes
bind_dn          = cn=admin,dc=domain,dc=com
bind_pw          = admin
query_filter     = (&(|(mail=%s)(mailalias=%s))(mailEnabled=TRUE))
result_attribute = mail
search_base      = ou=people,dc=domain,dc=com
server_host      = mail.domain.com
start_tls        = no
version          = 3

Does that look correct?

[17Halbe]

Nevermind. Just reverted the ldap lookup to the already existing tables and added test for aliases as well. This should now be a safe ldap implementation!

[johansmitsnl]

This looks very good! Waiting for @tomav to let me know when the release branches are setup to I can merge it.

[17Halbe]

So if you're going to merge this to a new release I would suggest switching the default to enable SPOOF_PROTECTION. This PR can be merged without changing the current behaviour at all. It's disabled by default. You have to set SPOOF_PROTECTION to 1 to make it work.

What about merging it now and I'll provide a PR for the new release to make spoof protection the default setting?

[johansmitsnl]

@17Halbe thats a good idea. Merged it so you can provide a new PR once the branching is done.

[dmcgrandle]

Good work on this @17Halbe!
:D