[Vulnerability] Local Domains Being Spoofed

Problem reported by ScottF - 4/14/2016 at 7:14 AM

Resolved

Hello,

A SmarterMail customer of ours received a phishing message with the "From:" address matching a co-worker at their domain (ex. From: user1@domain.com, To: user2@domain.com).

We have "Enable domain's SMTP auth setting for local deliveries" checked so if the "MAIL FROM:" is a local domain, SMTP auth is required. The message came through because in the SMTP session the "MAIL FROM:" was a non-local email address (ex. user3@spamdomain.com).

How do you stop messages where the "MAIL FROM:" does not match the message header "From"?

Thanks,

Scott

82 Replies

Reply to Thread

Bruce Barnes Replied

4/14/2016 at 3:44 PM

DMARC

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

ScottF Replied

4/15/2016 at 8:48 AM

Thanks Bruce. I'm looking for a global SmarterMail setting to handle this.With DMARC, I'm assuming we would need update each of our customer's DNS records.

Thanks,

Scott

Bruce Barnes Replied

4/15/2016 at 9:34 AM

Yes. DMARC DNS entries are required for each hosted domain, and DKIM Security key MUST be generated in SmarterMail. See my post at: https://portal.chicagonettech.com/kb/a116/why-am-i-having-problems-getting-my-e-mail-delivered.aspx for more information. Item # 12 discusses DMARC.

kevind Replied

7/11/2016 at 1:27 PM

Just following up on this post as we're seeing an increase in domain/email spoofing by spammers. Also, seems like there have been more posts about it here in the community.

So I'm wondering if there's a rule or setting in SmarterMail to check the 'from address' in message header to see if it's the same domain as the recipient. If so, it should require additional checks like SMTP Auth or SPF.

Another nice check would be the 'from address' in message header vs. the one in the Mail From. If it doesn't match, add points to the spam score.

Let me know if I'm missing something here. Thanks,
Kevin

Employee Replied

7/11/2016 at 3:14 PM

Employee Post

Kevin, I agree with you here.

It would be extremely valuable to have a check that verifies the From: header vs the Mail From: passed during the SMTP session.

I'll be glad to submit this as a feature request to have this considered for a future release.

Unfortunately, we do not have such checks or settings at this time.

kevind Replied

7/12/2016 at 10:03 AM

Von-Austin, that would be great if you could submit it as a feature request. Thanks!

David Jamell Replied

9/29/2016 at 4:04 PM

Has this been added as a request? I'm having the same issues.

kevind Replied

10/12/2016 at 11:48 AM

SmarterTools -- can we get this switched to Under Consideration or Planned? It seems like a simple request, should be easy to implement, and would reduce spam to the Inbox. Thanks!

Bruce Barnes Replied

10/13/2016 at 9:58 AM

It's already a feature in SmarterMail ENTERPRISE - require auth match for :e-mail address or domain. We enforce the entire e-mail address - no exceptions. No match, no pass.

Comcast does that for all of their network customers at the level III network level. If the SENT FROM and REPLY TO doesn't match, it simply doesn't get delivered.

The settings below also enforce TLS encryption of all SMTP clients - eliminating plain test passwords.

kevind Replied

10/13/2016 at 2:36 PM

Bruce, thanks for the reply and your settings. But this doesn't fix the spoofing problem. Unlike Comcast which checks the Reply To, this situation is when the MAIL FROM: doesn't match the message header From.

This should be reclassified as a bug in SmarterMail.

kevind Replied

10/20/2016 at 11:44 AM

Yes, updating hundreds of domains to add DMARC is not feasible. This needs to be done at the server level.

Bruce Barnes Replied

10/20/2016 at 10:47 PM

Not feasable, but required by GMAIL - :if to want to send thier servers more,than 25 messages per day m

ScottF Replied

10/21/2016 at 11:14 AM

With the increase in ransomware and other malicious messages with spoofed local senders it's more critical to get these messages stopped. Google and Outlook.com will flag these type of messages so it can be done. Please vote up this post to indicate there is demand.

Employee Replied

10/24/2016 at 12:41 PM

Employee Post

This has been added as a request. It is under consideration and hasn't been planned so I cannot offer an ETA on implementation.

Employee Replied

10/24/2016 at 12:47 PM

Employee Post

Greetings,

This is something that we are considering a feature request and not a bug at this time.

We do have the request logged, and we will be implementing similar protection that Outlook and Gmail offer in which the message will be flagged indicating it may not be who the From header states its from. There are some legitimate cases when this is done (such as with Google's calendaring system) that we need to take into consideration so these will ultimate not be blocked outright, but made more visible to the end user.

The feature is still in the early process of planning and I cannot offer an ETA unfortunately.

David Jamell Replied

4/2/2017 at 8:45 AM

This is really a problem. Just had a client complain about getting a "Wire Transfer" message from their "boss".

I already had all of Bruce's settings implemented from above, but to no avail.

In the Header, The "From" address is the real Boss address, but the "Return-Path" and "Reply-To" are different.

None of the email addresses or domains are "Trusted Senders" globally, at the site level, or the user level.

Why in the world world this be delivered?

Matthew Titley Replied

4/4/2017 at 8:28 AM

Let's assume (yes, this is a dangerous supposition) that David Jamell truly has all the proper configuration settings set in his SM installation. If so, and messages as described above are able to pass the various rules and tests, then there should be additional configuration options available to block these kinds of messages.

I haven't yet tried it myself but I will when I have the chance.

David, I'm sure you checked this but make sure that you don't have any of the pertinent IP addresses in any "whitelists" which may allow unauthenticated SMTP traffic.

Matt

David Jamell Replied

4/4/2017 at 9:11 AM

Thanks Matt and I don't mind checking anything that might shed some light.

There is nothing in "SMTP Authentication Bypass". I do have SpamHero IPs setup in Bypass Gateway, but the Domain in question isn't using SH for inbound MX.

kevind Replied

9/8/2017 at 11:05 AM

This problem needs to be addressed ASAP. Just saw a message where Stevie@e-street.com received a message from TheBoss@e-street.com. The From address "TheBoss@e-street.com" looked totally legit. Only when you look at the header can you see it came from the outside and TheBoss was spoofed!

All the security settings discussed above (SMTP Auth, etc.) are in place. The real Boss never sent the message. Furthermore, no authentication was done on the message when it came in, even though the From domain exists on the server. Using 15.x.

Paul Blank Replied

9/9/2017 at 4:40 AM

Are you sure that this is really a "spoof" and not a situation where the "reply-to" address is different than the actual sender address, which is permitted, for better or worse.

kevind Replied

9/9/2017 at 9:25 AM

Yep, nothing to do with the 'reply-to' address. The 'from' address is a local domain on the server, but the message came from an external IP with no authentication.

Shaun Peet Replied

9/12/2017 at 6:05 AM

This also still happens in v16 and we really need to figure out a solution to this problem. The spammers / spoofers have gone low-tech with this - writing extremely personalized messages which are very hard for the average person to catch until it's too late. The spammers are customizing the signature / salutation in the messages for goodness sake.

When you look at the headers of the original message there's mis-matches in the from, return-path, reply-to, etc. At a minimum, if we can't block these from incoming due to legitimate uses then there needs to be a large warning banner injected into the message itself (not the UI of SmarterMail webmail because the messages aren't always viewed there).

David Jamell Replied

9/12/2017 at 6:29 AM

I've had several clients call me with these highly personalized email messages that have the "From" set to the email address of a person in a Financial Role. Very unsettling to the client and me.

In each case the "Envelope Sender" does not match the "From" address.

Removing "Reply-To" from the equation, is it legitimate for Envelope and From to be different?

Paul Blank Replied

9/12/2017 at 6:57 AM

This is the kind of issue that ST should weigh in on, in this forum, and quickly.

kevind Replied

9/13/2017 at 3:47 PM

FWIW, they did weigh in on this back in July 2016 saying it would be extremely valuable to check the from address against MAIL FROM: in the SMTP session. Then again in Oct. 2016 saying it wasn't a bug, but would add it to the feature request list with no ETA.

If anyone knows the addresses of the SM programmers, we could exploit this vulnerability to send them an email from Tim@smartertools.com saying that this issue is critical and needs to fixed ASAP. :) JJ

Seriously, we need to at least provide some mechanism to warn users that the message is from someone at the local domain, but was not authenticated and could be fraudulent. Technically, I would prefer that these messages be rejected as rarely do you allow others to send using your domain.

If you do use a service like Constant Contact that's allowed to send as your domain, then it should be whitelisted or entered as global trusted sender. It's a little extra work, but will protect your users. See this highly-rated (20 votes) idea to make the management of trusted senders easier:

https://portal.smartertools.com/community/a86864/why-not-validate-trusted-senders.aspx

kevind Replied

10/2/2017 at 6:58 AM

So it's been like 3 weeks and there's no official response to this vulnerability. This is definitely a problem, not a feature request. Summary:

When you receive an email from someone on your own domain, SmarterMail needs to do some kind of verification or authentication.
Or at least warn the recipient that the message is fake.

Would opening a ticket help?

Matthew Leyda Replied

10/2/2017 at 7:02 AM

"So it's been like 3 weeks and we don't have any official response on this vulnerability. " Didn't you mean to say 3 Years?

Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP

kevind Replied

10/2/2017 at 7:11 AM

Right!!! 3 weeks since my last post, but the vulnerability has been around for years. Spammers and phishers are exploiting it to trick users into clicking on links and wiring money because the message appears legit.

igorinuk Replied

11/2/2017 at 5:18 AM

I wanted to use X-SmarterMail-Authenticated-As header to detect and filter fake emails. But there is a bug in SmarterMail:

https://portal.smartertools.com/community/a89812/bug-x-smartermail-authenticated-as-header-is-missing.aspx

I am really surprised this important issue is not fixed for 3 years. Instead SM developers are busy making nice UI of the SM 16. We need the mail server working properly first. And only when it works then we may need some UI bells and whistles. SM Team, please reconsider your priorities.

Matthew Leyda Replied

11/2/2017 at 5:49 AM

Fix Spam, Fix SPAM, FIX SPAM ..... Earth to SmaterMail Are you listening?

Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP

kevind Replied

11/2/2017 at 6:18 AM

This is an ongoing problem 5 months later...
https://portal.smartertools.com/community/a89604/how-do-you-guys-handle-spear-phising.aspx

echoDreamz Replied

11/2/2017 at 10:05 AM

Had something similar happen today where the "Return Path" was used in the SMTP transaction, and the "From" header was used in the delivery spam checks. The Return Path was some .com.br address, but the From address was using our CEO's address. So the email got right through and skipped spool checks because it is a "trusted sender".

kevind Replied

11/3/2017 at 8:34 PM

How about this one -- a user receive spam sent from their own email address! All protection/security settings are enabled:

Authentication required for all outgoing mail.
Nether the user nor the domain is entered as a trusted sender.

Here's the header:

Return-Path: <dfgfde4n@mbw-a.com>
Received: from mbw-a.com (ohone.plasurvey.net [162.248.4.130]) by mail.smartermail15.net with SMTP;
   Thu, 26 Oct 2017 08:00:30 -0400
Received: from localhost (127.0.0.1) by mbw-a.com id hqofec16lt0h for <user@smartermail15.net>; Thu, 26 Oct 2017 07:40:18 -0400 (envelope-from <dfgfde4n@mbw-a.com>)
MIME-Version: 1.0
Date: Thu, 26 Oct 2017 07:40:18 -0400
From: User <user@smartermail15.net><dfgfde4n@mbw-a.com>
To: user@smartermail15.net
Subject:  Reverse Mortgage Pitfalls..
Content-Type: text/html;
Message-ID: <56b5a34c82a24a7ca6334971b70dbea8@com>
X-Exim-Id: 56b5a34c82a24a7ca6334971b70dbea8

The header has 2 From addresses, but webmail only shows the 1st one.

It's not good that this totally fraudulent message is presented to the user. If the From address is a local domain, it needs to be authenticated!

Matthew Shepard Replied

11/7/2017 at 7:33 AM

I'm trying to get DKIM working to try to stop this, has anyone had any success with that?

kevind Replied

11/8/2017 at 3:38 PM

Our users enjoy receiving spam from themselves. NOT REALLY! Check out this header:

Return-Path: <>
Received: from waterpath.info (waterpath.info [80.211.161.27]) by mail.server.net with SMTP;
   Wed, 8 Nov 2017 16:47:01 -0500
Received: from waterpath.info (80.211.161.27) by waterpath.info id 0jDy9EPHf2fb for <mary@server.net>; Wed, 08 Nov 2017 20:41:58 +0000 (envelope-from <>
MIME-Version: 1.0
From: AmazingCreditScores <mary@server.net>
Subject: Get_,your_,free_,credit_,scores_,today_,with_,free_,trial_,
To: mary@server.net
Sender: <IFWRK@waterpath.info>
Message-ID: <2lGzwV3XecrHeWxoqWnUBVZu019.4881606134915040124@waterpath.info>
Content-Type: multipart/alternative; boundary="----=_NextPart_BFE_1DE9_08A320EA.1A30A4C1"
Date: Wed, 08 Nov 2017 20:41:58 +0000

Can we PLEASE fix this???

There is no reason that mail From a local user should be able to sail through the system with no authentication!!!

Fix: If the From address is a local domain on the server, then this must exist in header:

X-SmarterMail-TotalSpamWeight: 0 (Authenticated)

or the From address must match the Return-Path. Otherwise, reject the message.

Thank you.

kevind Replied

11/8/2017 at 3:44 PM

Yes, getting a little frustrating when other problems posted in this forum receive 2 or 3 votes and get fixed in a week with a custom build!

kevind Replied

11/8/2017 at 3:51 PM

We have DKIM set up. Doesn't help. These spam messages come in with this in header:
X-SmarterMail-Spam: DKIM_None

kevind Replied

11/15/2017 at 7:29 AM

OK, so another week goes by and no official reply... Looks like the last reply from ST was over a year ago in Oct. 2016.

Not trying to be mean, but there are other trivial issues in this forum that get immediate replies. This is a significant issue that affects all customers and IMO is more important than group chat, etc.

Phishing attacks in 2017 have increased significantly, with 36% of companies reporting attacks – up from 26% last year. 17% of companies experienced ransomware attacks – up from 14% – and financial fraud increased from 7% to 12%. Business email compromise scams are also increasing, up from 5% to 9% in the past 12 months. -- SpamTitan.com

And a recent study found that more gmail account compromises come from phishing attacks vs. 3rd party data breaches:

We find that the risk of a full email takeover depends significantly on how attackers first acquire a victim’s (re-used) credentials. Using Google as a case study, we observe only 7% of victims in third party data breaches have their current Google password exposed, compared to 12% of keylogger victims and 25% of phishing victims. -- nakedsecurity.sophos.com

Would like to know if a fix for this a) under consideration, b) in progress, or c) will never be worked on, so we can plan our future. Thanks.

Shaun Peet Replied

11/15/2017 at 7:34 AM

Way back in April 2016 Bruce's simple answer to this was DMARC. Has anyone researched this in more detail to know whether or not implementing DMARC actually solves this problem? I thought DMARC was more of a reporting mechanism but I'm no email scientist.

Derek Curtis Replied

11/15/2017 at 8:02 AM

Employee Post

Sorry, I thought someone had left a recent reply to this thread. Yes, better spoof protection is one of the more important things we'll be working on. It's VERY high on the list of items to work on, so a solution is coming. Once more info is available, we'll let you know.

Derek Curtis COO SmarterTools Inc. www.smartertools.com

ScottF Replied

11/15/2017 at 8:19 AM

Yes. You can block these with a strict DMARC setup. DMARC can be setup to require the MAIL FROM command (in SMTP) and the from: header (in the mail item) to match exactly.

This would be a difficult solution if your SmarterMail server contains hundreds of domains.

Matthew Leyda Replied

11/15/2017 at 3:39 PM

Will Ver15 get the fix or will we have to wait for Ver17?

Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP

kevind Replied

11/15/2017 at 8:30 PM

Great!!! Hope to see it in v15 also.
Feel free to contact me for questions, ideas on how to fix, testing, etc.

Matt Petty Replied

11/20/2017 at 12:42 PM

Employee Post

Hello,

We have started development on this issue. It is requiring multiple days of evaluation and there is a hefty amount of SMTP and delivery related code moving around for this. This will be in SmarterMail 17.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

Shaun Peet Replied

11/20/2017 at 1:09 PM

So you've given up on SM16? As an early adopter who's gone through all the growing pains for the past several months, this is very disappointing.

Paul Blank Replied

11/20/2017 at 1:12 PM

Not really a great answer.

This should be in V15 because V16's interface is not ready for production, in my opinion, and that of many others.

Derek Curtis Replied

11/20/2017 at 2:13 PM

Employee Post

It's not a matter of giving up on 16, which we obviously haven't done. We generally don't add major features to our products in minor releases unless they're features that are still in development or that were announced as part of the major but didn't make it into the production release. After evaluating how we wanted to handle this item, it will take a lot of work to do it the way we want. That turns it into a major feature or major change to the core product, which is why it's going to be in a major release and not a minor.

Derek Curtis COO SmarterTools Inc. www.smartertools.com

kevind Replied

11/20/2017 at 4:51 PM

Disappointed that we have to wait 6-12 months for v17. How about this simple solution be included in a minor update to v15 and v16?

If the From address is a local domain on the server, it needs to match the Return-Path. Otherwise, take this action (whatever is easiest to implement):
-- reject the message
-- assign points so it goes to Junk
-- change the "From" so that it warns the recipient that the message is fake

Paul Blank Replied

11/20/2017 at 6:08 PM

Agreed, Kevin. It is nice to see this being addressed, however late. In fact, my client's (and my) incoming email travels through a decent cloud service, so this hasn't been a direct issue here.

As has been mentioned previously, using a cloud filter means that trapped incoming spam and malware-infected messages never touch the mail server. Sizable reduction in traffic and server load as well.

echoDreamz Replied

11/20/2017 at 11:15 PM

I am still wondering about the RDNS improvements as well as FCRDNS checks as well and what is planned for that or if it has been written off.

echoDreamz Replied

11/20/2017 at 11:16 PM

Agreed Paul. Though 16 is getting better - I still heavily dislike the interface. I am really really really hoping for a v15 theme for v16/17.

Although the SM changelog for v16 states...

IMPORTANT: Additional SmarterMail themes are coming soon! Administrators and/or users will soon be able to choose from a variety of preset layouts and color themes. In preparation for this design, some personalization options, including the ability to change the color scheme or add custom CSS, have been removed from SmarterMail 16.x. (16.0.6345)

However I am not sure what "numerous layouts and color themes" they are talking about. We have, what? 2?. Though I know, they've been super busy squashing the massive amounts of bugs :), which is good.

Derek Curtis Replied

11/21/2017 at 12:21 PM

Employee Post

After talking with the developers this morning, it appears the majority of the work was already done for this, so we'll be putting it in the next minor of 16.x.

Derek Curtis COO SmarterTools Inc. www.smartertools.com

echoDreamz Replied

11/21/2017 at 12:29 PM

Awesome Derek! If I could thumbs this up I would!

Shaun Peet Replied

11/21/2017 at 12:40 PM

Well that's good news. In our case we're finally somewhat stable with the last 2 minor releases of SM, including (as far as I know) the mysterious dropping of mailing list subscribers. But the last 5 months have been particularly difficult for us because we decided to stick with V16 despite the bugs and help be part of the solution. That, in turn, had an enormous impact on our own resources since we were both supporting our own customers as well as working with SmarterTools to help improve their product.

Please don't discount the frustration that people like us have endured during the V16 release to this point by putting things onto V17. I'd prefer if V17 wasn't even "a thing" yet actually - and it should be a goal to get everyone who's not upgraded from prior versions to V16 to prove to them that it's a good move. Once everyone is on V16 because it's the best thing ever, then move on to V17.

Thanks for listening.

Paul Blank Replied

11/21/2017 at 12:51 PM

"Somewhat" stable??? Some recommendation. That implies that it's also somewhat unstable.

Shaun Peet Replied

11/21/2017 at 1:36 PM

@Paul Blank - what's the last version you've tested? All I see on here is you flaming V16 but there's not a whole lot of constructive criticism on your end. We get it - you had a bad experience with V16. The question is - are you interested in V16 becoming what it was promised to be (which benefits everyone including yourself) or will you always be this dark cloud hanging over the forums looking to take every possible dig at SmarterTools possible? If you've got no interest in upgrading to V16 ever, no matter what, then please focus your time elsewhere. However, I feel that you could be a valuable contributor to the overall progress should you choose to do so.

When I say somewhat stable I say that for our own environment and our own experience for the past two releases things have been working as originally advertised. I'm not prepared to stake my own reputation to announce to the world that things are 100% rock solid, but that doesn't mean that I wouldn't recommend the upgrade at this point either. The reason we stuck with V16 from the start was that some of the core engine elements like EAS (and autodiscovery) seemed to work better, and for whatever reason we didn't have the huge issues with webmail slowness reported by others. Along the way there were regressions, some minor and some major, but we worked through them and the last couple of minor releases have been - to my knowledge - without any issues* (at least, no issues that didn't exist in prior versions, such as the topic of this thread).

I'm not trying to start a flame war with anyone but every post you've made is always negative, negative, negative. It gets exhausting after a while and certainly isn't productive.

Paul Blank Replied

11/21/2017 at 1:59 PM

Believe me, the last thing I care to do is start a flame war.

Paul Blank Replied

11/21/2017 at 4:24 PM

I seriously expected better from ST, and that is the source of frustration.

And again, to be sure, nothing at all personal between me an any SM user/admin on here. Anyone using v16 is to be commended for their perseverance / stamina. I mean that. I think the postings of others regarding v16 since its production release, even through today, speak volumes.

igorinuk Replied

6/6/2018 at 2:44 PM

Hi Derek,

Have you fixed this bug already in v16?

igorinuk Replied

6/7/2018 at 12:07 PM

I ask this, because in November you said: "After talking with the developers this morning, it appears the majority of the work was already done for this, so we'll be putting it in the next minor of 16.x.
(Derek Curtis November 21, 2017)"

kevind Replied

6/19/2018 at 6:28 AM

Saw a few thousand messages this morning where the user received spam from themselves. :-(

https://portal.smartertools.com/community/a89857/spam-from-the-own-user.aspx

Unfortunately they were all delivered because we're still on v15 (our customers like this UI better). Does anyone know if this is fixed in v16.

FWIW, prefer to see issues like this be fixed before work is done on new features.

echoDreamz Replied

6/19/2018 at 1:21 PM

I have not had any issues since the minor that "fixed" this was released. We used to get the spoofed emails all the time, I havent seen anything in maybe ~6 months.

Curtis Kropar www.HawaiianHope.org Replied

6/20/2018 at 2:32 AM

echo, is that ver 15 or ver 16 that you are referring to it is fixed ?

www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !

Employee Replied

8/13/2018 at 10:28 AM

Employee Post

Hello all,

I just want to provide a quick update on this thread while adjusting the status to Resolved. In the release notes for SmarterMail 16.3.6543 (Nov 30, 2017), you'll find the following note: "Changed: SMTP and Delivery processes now utilize the From address in email headers if it is provided; provides better spoofing protection."

If you're still having trouble with spoofed emails on version 16.3.6543 or higher, please submit a ticket to the Support Department for a further review.

Thank you!

kevind Replied

8/14/2018 at 9:40 AM

Hi Andrea,

Any chance that this will be fixed in v15 also? We still use v15 and judging from the posts in the forum, there are a lot of other customers that do as well.

I know the standard answer is new features don't get added to older versions, but this fixes a vulnerability. FWIW, the original post above was back in 2016 -- well before v16 was even released. :)

Maybe people could thumbs-up this post if they would like to see it fixed in v15, just to see if it's still an issue.

Thanks,
Kevin

Paul Blank Replied

8/14/2018 at 10:06 AM

It is not at all good that this apparently isn't being fixed in v15, so far.

Hemen Shah Replied

8/14/2018 at 11:25 AM

Inline with Kevin, we too still on SM 15 and would really like to get this fixed.

Employee Replied

8/14/2018 at 4:06 PM

Employee Post

Kevin, Paul,

I reached out to the development team with this request, and I'm afraid we aren't able to implement this change in SmarterMail 15.x. Unfortunately, the foundation of the product doesn't support this change in version 15.x or earlier.

Paul Blank Replied

8/14/2018 at 4:52 PM

Doesn't seem likely, it appears, that this will ever happen with v15, as you can see from the below comment. But hey, we're just a few members of a sizable group of ticked-off resellers, admins and users. Don't listen to us; we don't matter.

kevind Replied

8/15/2018 at 6:06 AM

OK, thanks for asking.

Matt Petty Replied

8/15/2018 at 7:27 AM

Employee Post

While we are unable to move this 16 change into 15, It might still be interesting to get some ideas on how we could fix this in alternate ways. The change that we are referencing would be very difficult to move down into 15. However we can do things like, not counting emails with the same from/to as a trusted sender unless its authenticated, could be one. Any other ideas? If we can get some ideas down we can evaluate doing them in 15 still, just that particular 16 implementation we don't plan on rolling down. Maybe we can find a completely better idea for this. I don't wanna leave you guys hangin'.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

David Jamell Replied

8/15/2018 at 7:43 AM

Three cheers for Matt!

kevind Replied

8/15/2018 at 2:28 PM

Hey Matt, appreciate you looking out for us v15 users! Please find a way to fix this in v15.

You might ask why not just upgrade to v16 to fix the problem? It's not a cost or technical issue, but the UI. If you could improve the v16 UI so it's more like v15, our customers would go for the upgrade. Currently they don't want to move because they don't like the new UI.

Michael Replied

11/14/2018 at 10:00 AM

It was disappointing this was not rolled out v15.

Can we understand how v17 handles this issue?

Paul Blank Replied

11/14/2018 at 10:28 AM

Two possible fixes:

1. An external email filtering service may be of help e.g. Barracuda, Messagelabs (Symantec email security.cloud), Mimecast etc. Have been using Messagelabs, and this has not been an issue thus far. Of course I haven't seen the problem, but it might be because our filter has blocked these emails.

2. Check out Declude from www.mailsbestfriend.com. Not sure if this is a feature of the program, but it might be.

kevind Replied

3/1/2019 at 7:57 AM

This thread is marked as Resolved, but seems like it's still an outstanding issue in March 2019:

https://portal.smartertools.com/community/a91739/spammers-impersonation-of-users-what-should-i-do.aspx

Thanks.

Matt Petty Replied

3/1/2019 at 8:00 AM

Employee Post

Lets keep our discussion in the other topic until we get to the bottom of whats actually occuring.

Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com

David Jamell Replied

9/25/2019 at 11:53 AM

I'm experiencing this problem again with version 100.0.7172.

All settings regarding authentication and relay from above are set appropriately for the domain jdalfordlaw.com on my server.

From the SMTP Logs, a message where Envelope Sender is operations.masvingo@freshtrade.co.zw but the From is john@jdalfordlaw.com.

Here is the SMTP Log:

[2019.09.25] 01:08:53.793 [108.166.161.242][20839078] rsp: 220 mail.jdalfordlaw.com Wed, 25 Sep 2019 06:08:53 +0000 UTC
[2019.09.25] 01:08:53.793 [108.166.161.242][20839078] connected at 9/25/2019 1:08:53 AM
[2019.09.25] 01:08:53.793 [108.166.161.242][20839078] Country code: US
[2019.09.25] 01:08:53.840 [108.166.161.242][20839078] cmd: EHLO bolt100a.mxthunder.net
[2019.09.25] 01:08:53.840 [108.166.161.242][20839078] rsp: 250-mail.jdalfordlaw.com Hello [108.166.161.242]250-SIZE 104857600250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250-DSN250 OK
[2019.09.25] 01:08:53.871 [108.166.161.242][20839078] cmd: STARTTLS
[2019.09.25] 01:08:53.871 [108.166.161.242][20839078] rsp: 220 Start TLS negotiation
[2019.09.25] 01:08:53.980 [108.166.161.242][20839078] cmd: EHLO bolt100a.mxthunder.net
[2019.09.25] 01:08:53.996 [108.166.161.242][20839078] rsp: 250-mail.jdalfordlaw.com Hello [108.166.161.242]250-SIZE 104857600250-AUTH LOGIN CRAM-MD5250-8BITMIME250-DSN250 OK
[2019.09.25] 01:08:54.027 [108.166.161.242][20839078] cmd: MAIL FROM:<operations.masvingo@freshtrade.co.zw> SIZE=302896
[2019.09.25] 01:08:54.027 [108.166.161.242][20839078] senderEmail(1): operations.masvingo@freshtrade.co.zw parsed using: <operations.masvingo@freshtrade.co.zw>
[2019.09.25] 01:09:02.686 [108.166.161.242][20839078] rsp: 250 OK <operations.masvingo@freshtrade.co.zw> Sender ok
[2019.09.25] 01:09:02.686 [108.166.161.242][20839078] Sender accepted. Weight: 0. Block threshold: 30.
[2019.09.25] 01:09:02.716 [108.166.161.242][20839078] cmd: RCPT TO:<carolyn@jdalfordlaw.com> ORCPT=rfc822;carolyn@jdalfordlaw.com
[2019.09.25] 01:09:02.716 [108.166.161.242][20839078] rsp: 250 OK <carolyn@jdalfordlaw.com> Recipient ok
[2019.09.25] 01:09:02.763 [108.166.161.242][20839078] cmd: DATA
[2019.09.25] 01:09:02.763 [108.166.161.242][20839078] Performing PTR host name lookup for 108.166.161.242
[2019.09.25] 01:09:02.763 [108.166.161.242][20839078] PTR host name for 108.166.161.242 resolved as bolt100a.mxthunder.net
[2019.09.25] 01:09:02.763 [108.166.161.242][20839078] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2019.09.25] 01:09:02.794 [108.166.161.242][20839078] senderEmail(2): john@jdalfordlaw.com parsed using: "John D. Alford <john@jdalfordlaw.com>" <operations.masvingo@freshtrade.co.zw>
[2019.09.25] 01:09:02.825 [108.166.161.242][20839078] Sender accepted. Weight: 0. Block threshold: 30.
[2019.09.25] 01:09:02.950 [108.166.161.242][20839078] rsp: 250 OK
[2019.09.25] 01:09:02.950 [108.166.161.242][20839078] Received message size: 302898 bytes
[2019.09.25] 01:09:02.950 [108.166.161.242][20839078] Successfully wrote to the HDR file. (c:\SmarterMail\Spool\SubSpool6\69010461.hdr)
[2019.09.25] 01:09:02.950 [108.166.161.242][20839078] Data transfer succeeded, writing mail to 69010461.eml (MessageID: <201909250408.x8P46pK6012610@rs112.zol.co.zw>)
[2019.09.25] 01:09:02.981 [108.166.161.242][20839078] cmd: QUIT
[2019.09.25] 01:09:02.981 [108.166.161.242][20839078] rsp: 221 Service closing transmission channel
[2019.09.25] 01:09:02.981 [108.166.161.242][20839078] disconnected at 9/25/2019 1:09:02 AM

Please advise.

Kyle Kerst Replied

9/30/2019 at 11:42 AM

Employee Post

David, you'll need to upgrade to our latest release and implement SPF/DKIM and our recommended antispam best practices to resolve these issues. Please also make sure SMTP authentication is required under Settings>Protocols>SMTP IN and the domain-level configurations as well. If you continue to have issues with this you'll want to submit a support ticket as this thread is quite old at this point.

Kyle Kerst IT Coordinator SmarterTools Inc. www.smartertools.com

Jade D Replied

11/19/2019 at 11:54 AM

Hi David

Do you have smtp authentication required for local deliveries? This would have stopped the second email.

PS, your client is going to be subjected to alot more spam after you posted their email address on a public forum.

You need to redact all personally identifiable information

Jade https://absolutehosting.co.za

David Jamell Replied

11/19/2019 at 12:16 PM

Yes Jade D, smtp authentication is required for local deliveries.

Sébastien Riccio Replied

11/19/2019 at 12:55 PM

I think they are fooling your customer here by altering the "full name" of the sender because, this:

"John D. Alford <john@jdalfordlaw.com>" <operations.masvingo@freshtrade.co.zw>

is the format of "Full name" <sender-email-address>

So SmarterMail is acting correctly here, as the sender is <operations.masvingo@freshtrade.co.zw> it's not a same domain local delivery.

However the mail client would display the full name and here it is "John D. Alford <john@jdalfordlaw.com>", like it could have been "John Doe". The content between the begining and ending double-quotes is considered as the full name.

I think you can't do much about it. The only thing would be to clean the full name and remove any <xxx> from it, but should it be the task of the mail server or the mail client ?

Sébastien Riccio System & Network Admin https://swisscenter.com

Back to Community Threads

Please leave this box unchecked