4
How to block fake local email addresses from delivering mail?
Question asked by Philip Van Pul - 12/3/2015 at 8:31 AM
Unanswered
Hi all, my first post...
 
I'm not sure how to search for this in the knowledge base or community. This may already be answered, and if so, I apologize for the duplication; and would appreciate a link to the pertinent thread,
 
I've seen quite a few instances where an fake email address using one of our domain names is used to send mail inbound to the server from outside our organization to a valid email account on our server.  The domain portion is correct, but the email root is not.
 
Example:  We host the xyz.com domain and fake@xyz.com sends an email to real@xyz.com from an outside server.  There is no fake@xyz.com email/user on our server. The fake@ email is delivered through port 25 unauthenticated (just like any other email). 
 
It seems that by default SmarterMail 11 allows this.  I run a few other mail servers and they all seem to disallow this out of the box, recognizing that the fake@ is not a valid user.
 
Is there a setting that governs this?
(Note that I considered the use of spf in our dns, but I'll have to make changes to the mail systems at some of our remote properties to make that work,)
 
Thanks!
 
--p

8 Replies

Reply to Thread
0
Joe Wolf Replied
Settings, Protocol Settings, SMTP In then check the "Enable domain's SMTP auth setting for local deliveries" box.
 
-Joe
 
1
Philip Van Pul Replied
Hi Joe,
 
thanks for replying!
 
That setting seems to cause some issues with out copier/scanners that use the mail server to send out.  They can scan to outside addresses (as they authenticate to do that), but cannot deliver to internal ones.  I'll need to get our local IT support in those locations to have a look at the settings in those machines.  For now I disabled that setting again. (I did establish spf in our dns last night. Still testing that.)
0
kevind Replied
Enter the IP of your copier/scanner to bypass SMTP Auth.
- Kevin
0
Philip Van Pul Replied
Hi Kevin, thanks for the suggestion! That would end up being the outside gateway ip of the property (in another city). This would basically whitelist all the machines within that network. This may be an option as a workaround if I can't come up with a different solution. I'll need to coordinate with the local support (about 3hrs away) to troubleshoot a bit first. If all else fails, I'll head out to have a look myself.
0
kevind Replied
Sure, having all devices authenticate is always best. The bypass is just a quick fix as it's unlikely the users of this gateway are the source of your spoofing.
2
kevind Replied
 
The setting that Joe pointed him to is hard to find, difficult to understand, and should be eliminated.
 
Instead, this existing check box at the domain level should require SMTP Auth for all users. Period.
Eliminating the local deliveries check box will make SM easier to set up and more hardened against spammers.
0
Paul Blank Replied
Agreed. ALL devices that send email from your domain should be forced to authenticate. Stops many problems before they happen.
0
Philip Van Pul Replied
Just to clarify/recap, here's the protocol settings I'm using under SMTP IN:
- Allow Relay: Nobody
- Allow relay for authenticated users: on/yes
- Enable domain's SMTP auth setting for local deliveries: off/no
- Disable AUTH LOGIN method for SMTP authentication: off/no

Everything is working fine, except that we get spam from joe@mydomain.com to philip@mydomain.com when joe@mydomain.com isn't a valid email on our server, and his outgoing server/ip is not our mail server. The recipient philip@mydomain.com is a real email address on our server.

I've tested this myself from my workstation to the server using telnet on port 25 and manually sending a message with MAIL FROM <joe@mydomain.com> and RCPT TO <philip@mydomain.com> and the server allows it, and accepts the message and puts it in my inbox.

I'm surprised the server doesn't come back with "sorry, I know all valid email addresses on mydomain.com, and you are not one of them..."

The SPF filter does catch this (wrong ip) and calls it Permanent Fail, but still lets the message through as the spam score is below the minimum level. I can't (not allowed to) increase the weight of the SPF score so it will fail the message all by itself. There's legit companies that have incorrect SPF records, and we (ownership/management) don't want to block them. (We are in the hospitality industry, dealing with the general public, and a bounce back is a potentially lost client.)

Reply to Thread