Reject if SMTP AUTH different from server

This is a good one, and I'd say is more like "kind of a bug" that should be solved immediately.

According to their documentation, the feature is described as:

"Check this option to reject any connections where the Sender information differs from the information used in the SMTP AUTH command."

In essence, you'd like it so that if the FROM: of the email mismatches the SMTP authorized email account, to reject the email send attempt?

If so, there are at least two circumstances that you should be aware of which would effectively circumvent this feature.

1) Antirelayd (or "POP before SMTP)".

By its very intended design and purpose, if this feature is turned on, the user is allowed to forego SMTP authentication if the IP they're sending mail from has experienced a valid POP/IMAP authentication in the last 30 minutes. This would mean "Antirelayd" being on (and users making use of it) would be able to circumvent this restriction.

2) sendmail

Again by its nature, any scripts on the server that use /usr/sbin/sendmail (the vast majority of them do this by default) would not be utilizing SMTP AUTH and therefore circumvent this feature entirely.

--

Do you still wish for this feature to be included knowing the above limitations? I explain them simply to indicate that, even if this feature were implemented and enabled, it would *not* ensure that all mail sent out from the server matched a valid email account on the server.

For example, if the intent of this feature is to curb mass spam mailers that might get deployed onto accounts, the feature would have zero effect on them since they'd likely be using sendmail and not SMTP AUTH.

This is a serious issue that is being exploited widely as I write and many server admins are struggling with the cleanup requirement that results.

Hi Brian,

Yes, the request is as stated. The reason is that a current modus operandi of spammers is to steal SMTP Auth credentials from a PC (via virus/trojan). These are then used to send spam, possibly on a trickle basis.

The sending of this spam eventually results in the server IPs being blocked on RBL lists, which becomes a huge headache to fix. And major email providers are really struggling with this attack as for them, it aggregates to become very considerable.

Current behaviour seen is that the user will auth via SMTP credentials and send spam from a user such as fred1234@aol.com.

Cheers,

Brian

example line from /var/log/exim_mainlog:

2014-04-22 22:31:22 1WcZr6-00074V-VB <= robertnewar@aol.com H=(toniharro.com) [46.1.130.190]:3862 P=esmtpa A=dovecot_plain:tony@toniharro.com S=3395 T="Fw:" for johnquiglay@sytaer.co.uk mathew.stevans@bpstl.co nicola.fisher1@bpstl.co fritchie@batchelors.co.uc .... (20 other random email addesses removed so I don't need to sanitize them)

see also my detailed comments in http://features.cpanel.net/responses/reject-if-smtp-auth-different-from-server:

Hi Brian,

Yes, the request is as stated. The reason is that a current modus operandi of spammers is to steal SMTP Auth credentials from a PC (via virus/trojan). These are then used to send spam, possibly on a trickle basis.

The sending of this spam eventually results in the server IPs being blocked on RBL lists, which becomes a huge headache to fix. And major email providers are really struggling with this attack as for them, it aggregates to become very considerable.

Current behaviour seen is that the user will auth via SMTP credentials and send spam from a user such as fred1234@aol.com.

example line from /var/log/exim_mainlog:

2014-04-22 22:31:22 1WcZr6-00074V-VB <= robertnewar@aol.com H=(toniharro.com) [46.1.130.190]:3862 P=esmtpa A=dovecot_plain:tony@toniharro.com S=3395 T="Fw:" for johnquiglay@sytaer.co.uk mathew.stevans@bpstl.co nicola.fisher1@bpstl.co fritchie@batchelors.co.uc .... (20 other random email addesses removed so I don't need to sanitize them)

Voted!

see my comments on this one, which is better worded than this request: http://features.cpanel.net/responses/reject-if-smtp-auth-different-from-server

The feature requirement would be:

• default level of not allowing email From non-local domains, always enforced (no reason not to enforce this, there are services that they can use for the extremely rare use case of needing to send as a non-local user, and leaving this open causes huge cleanup issues for email providers and attracts spammers to attack cpanel servers and steal SMTP auth details)
• Configurable option to only allow From of authenticated domain. If SMTP user authenticated as fred@somedomain.com they should only be allowed to send From anyuser@somedomain.com.
• Configurable option to only allow as same user. Ideal if this could be the default for new cPanel installations (or perhaps the same-domain option above, at least).

So the three choices would be:

• enforce non-local
• enforce same-domain
• enforce same-user

Hope this helps ...

Another option could be a 'verified' 'from' addresses list.

I really need this option against spammers sending phishing emails, with authenticated users, supplanting another domains

I really need this option against spammers sending phishing emails, with authenticated users, supplanting another domains

We implemented this solution which has been useful to us:

https://bobcares.com/blog/blocking-spoofed-mails-going-out-of-your-cpanel-whm-web-hosting-server/

1. Login to WHM >> EXIM CONFIGURATION MANAGER >> ADVANCED EDITOR

2. Add the following entry using the Add additional configuration setting feature:

1. domainlist remote_domains = lsearch;/etc/remotedomains

3. Under the section “ACLs“, add the following code in acl_not_smtp >> custom_begin_outgoing_notsmtp_checkall :

1. deny
2. condition = ${if ! match_domain{${domain:${address:$h_From:}}}{+local_domains : +remote_domains}}
3. message = Sorry, you don't have permission to send email from this server with a header that \
4. states the email is from ${lc:${domain:${address:$h_from:}}}.

4. Search for acl_smtp_data and add the following lines undercustom_begin_outgoing_smtp_checkall :

1. deny
2. authenticated = *
3. condition = ${if or { \
4. { !eqi{$authenticated_id} {${address:$header_From:}} } \
5. } }
6. message = Your FROM address ( $header_From ) must \
7. match your authenticated email user ( $authenticated_id ). \
8. Treating this as a spoofed email.

Important points to keep in mind:

1. POP before SMTP won’t work. You will have to ask your customers to use the option – “My Server Requires Authentication” in the SMTP settings of their email client.
2. Username in the format user+domain.com will not work. Customers will have to use user@domain.com instead.