A check to only allow MAIL FROM same as the authenticated user's username

[onprem]

Use case

With the default configuration, a user can use any email (from the same domain) in the MAIL FROM and it will work. This means that an authenticated user with username user@example.org can send email from admin@example.org. This can become a major concern in environments with multiple tenants.

Your idea for a solution

There are two options that came to my mind:

• Add a check that can be used to reject a mail of authenticated user and mail from address doesn't match.
• Add a modifier that overwrites MAIL FROM with the current username.

I think the second option is more desirable and provides better UX, but I don't think it's possible currently. But I was able to simulate the first option by using the command check and a script that exits with status code 1 when it's two arguments don't match in submission section.

check {
     command match {auth_user} {address} {
         run_on sender

         code 1 reject 550 5.7.0 "Use your own name, you imposter"
    }
}

• I'm willing to help with the implementation

[foxcpp]

Add a check that can be used to reject a mail of authenticated user and mail from address doesn't match.

One might want to check MAIL FROM and/or From header in this case.

Note that MAIL FROM might not always match the sender account name exactly. E.g. mailing list sender adding VERP suffix to MAIL FROM: list+somehashorwhatever@example.com while using account list@example.com. There are maybe special-use accounts that should be allowed to use any sender address. If we unbrick PAM support then account name could not be a full email at all.

But for start, I think adding a check that would do direct comparison* is a good idea. We could then extend it by using a table to map from account name to additionally allowed sender addresses, or glob, or regexp matching them, dunno.

* Subject to internationalization and format normalization, we have address.Equal function for this.

[theo546]

To add something to this issue, I think aliases should also be allowed to be sent from.

[foxcpp]

7c2afde adds authorize_sender check for this. The check configuration is done in a way that would allow:

• "Superuser" accounts being able to use any address
• Users being able to use any address aliased to their account
• Optional From/Sender header check (compatible with MLM software since Sender is also checked)

[theo546]

7c2afde adds authorize_sender check for this. The check configuration is done in a way that would allow:

* "Superuser" accounts being able to use any address

* Users being able to use any address aliased to their account

* Optional From/Sender header check (compatible with MLM software since Sender is also checked)

Amazing implementation! Looking forward to test it as soon as the new version of Maddy drops!

I looked at the new configuration options, is

check.authorize_sender {
    prepare_email identity
    user_to_email identity
    check_header yes
    unauth_action reject
    no_match_action reject
    malformed_action reject
    err_action reject
    auth_normalize precis_casefold_email
    from_normalize precis_casefold_email
}

only required to check if someone is allowed to send from an alias as?

[foxcpp]

prepare_email is what is needed for it. Other options are just knobs for policy mechanism (I will probably reconsider what *_action are configurable).

[theo546]

Is there any configuration example about how to use that new feature so it can support aliases?
Will it be added to the default configuration?

[foxcpp]

It will be added to default configuration, here is the updated maddy.conf:

maddy/maddy.conf

Lines 111 to 140 in fae1072

	submission tls://0.0.0.0:465 tcp://0.0.0.0:587 {
	limits {
	# Up to 50 msgs/sec across any amount of SMTP connections.
	all rate 50 1s
	}
	auth &local_authdb
	source $(local_domains) {
	check {
	authorize_sender {
	prepare_email &local_rewrites
	user_to_email identity
	}
	}
	destination postmaster $(local_domains) {
	deliver_to &local_routing
	}
	default_destination {
	modify {
	dkim $(primary_domain) $(local_domains) default
	}
	deliver_to &remote_queue
	}
	}
	default_source {
	reject 501 5.1.8 "Non-local sender domain"
	}
	}