Why is spoofed mail getting through
Question asked by Anthony Salter - December 7, 2016 at 1:07 PM
Unanswered
Just looking for clues to an issue, hoping to get a bit of input form those with experience on this.
 
Our server is getting spoof emails from our own domain sent through,
 
I have our domain in system trusted senders
 
I have set 'Require Auth Match' to 'Domain' (which i believe means it should block any emails sent to our domain which purport to be sent from a domain but are in fact send from from another)
 
Yet emails sent in the described method are still getting through, they are accepted under smtp with the real sender address, and then delivered to their intended mailbox under the guise of an internal email.
 
It appears that on delivery SM believes the mail is actually from our domain, basing this off the 'from' label that has been slapped on rather than the actual sender address which is clearly identified in smtp log, in the delivery log  it record the spoofed address instead, which then triggers 'Trusted User' letting it into the mailbox.
 
I want these mails to be stopped at SMTP In, if they try to send from one domain (i.e ours) when its is clearly sent from another.
 
It was my understanding that this was what the 'Require Auth Match' set to 'Domain'  was meant to do.
 
Is my understanding correct / is that the correct action to block this kind of spam ?
 
Any comments much appreciated

3 Replies

Reply to Thread
0
My other option would be to just remove our domain from trusted senders i guess, the setup i have in inherited and populated configuration so i'm not sure of the original reason for this.

This thread seems to hit the nail on the head in regard to trusted senders , http://portal.smartertools.com/community/a132/trusted-sender-user-level.aspx - its making some undesirable assumptions

I still don't understand why spoofed domains are let through when 'Require Auth Match' is set to domain though.
0
...further comments on 'Require Auth Match' Domain , seems it does what it should but in the wrong direction for this issue.

It blocks an authenticated user from sending an email that appears to be from another domain ,

yet an unauthenticated user can still send an email that appears to be form another domain , and worse doesn't even block mails using OUR domain as a from address.

i have now removed our domain from 'System Trusted Senders' and this is ok as authenticated users get a 0 spam score, so as long as these spoof emails fail spam tests when checked this should stop them.

I do think its odd that the functionality either doesn't work or isnt there to stop emails being sent in pretending to be from our domain, it should require auth if the 'from' address lists our domain.

And the other issue i mentioned before about trusted senders taking effect on the from / reply to header field data is still unbelievable.

Are these considered know caveats , or is it something that will be worked on (i hope so)?
0
Bruce Barnes Replied
Try these settings:
 
ALLOW RELAY - NOBODY and

REQUIRE AUTH MATCH EQUAL E-MAIL ADDRESS:
 
ALLOW RELAY - NOBODY | REQUIRE AUTH MATCH - E-MAIL ADDRESS
ALLOW RELAY - NOBODY | REQUIRE AUTH MATCH - E-MAIL ADDRESS

MORE!

Notice the two variables in the SMTP BANER LINE?
 
SMTP BANNER LINE
SMTP BANNER LINE
  • #HostName#  #TimeUTC# UTC
They MUST be included in the SMTP BANNER, POP BANNER, and IMAP banner as well. or YAHOO will either block, or limit the number of e-mail messages you can send during the day. 
 
To quote Gomer Pyle, "SUPRISE . . . SUPRISE . . . SUPRISE , , , "
 
This was quietly implemented last FEBRUARY, and no one from YAHOO said anything, they just started bouncing messages.  They did insert a cryptic message bounce and link in the header, but you had to search to find it and then open their Postmaster Portal page to search for the information you needed.
 
Once we added the banners, all mail to YAHOO started flowing, immediately, as if we'd never been blocked or slowed down
 
Here's our COMPLETE BANNER, which is added to the message headers of all SMTP transactions and also added to our logs.  It helps us a great deal when we are attempting to find a spammer or someone's account which has been compromised.
 
"#HostName#  #TimeUTC# UTC | SmarterMail Enterprise Version 15.4.6151.26341"
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting

Reply to Thread