Local delivery SPAM getting through

Problem reported by Patrick Hedgepath - 9/1/2015 at 5:51 PM

Submitted

Ok so our server is setup to relay for nobody etc. We have been getting reports of our clients spam counts going through the roof. Even clients that are using AppRiver spam filtering. So I started to try to investigate. I asked them to send me some of the messages. They are coming from some of the new domain extensions like .racing and .faith etc. So I check AppRivers spam logs and I don't see these messages at all. Yet they are being delivered to the boxes on the server. This would indicate to me that the messages are somehow being delivered locally to a bunch of local boxes without first going through the records indicated by the MX records (thus not going through AppRiver filtering at all).

My problem is I am not sure how to track down let along fix this issue. Where is this stuff coming from? Here is a log snippet for one of the spam emails in question. It came from @tarnishedtags.faith so I looked at the delivery and smtp logs for tarnishedtags.faith and this is what the SMTP log shows for example. I can't see where they are authenticating in any way. Any help here would be greatly appreciated.

[2015.09.01] 20:22:53 [217.172.190.161][6036280] rsp: 220 mail.pegweb.com
[2015.09.01] 20:22:53 [217.172.190.161][6036280] connected at 9/1/2015 8:22:53 PM
[2015.09.01] 20:22:53 [217.172.190.161][6036280] cmd: EHLO feedtuneup.faith
[2015.09.01] 20:22:53 [217.172.190.161][6036280] rsp: 250-mail.pegweb.com Hello [217.172.190.161]250-SIZE 41943040250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2015.09.01] 20:22:54 [217.172.190.161][6036280] cmd: MAIL FROM:<MensHealth-Millionaire-Maker@feedtuneup.faith> BODY=7BIT
[2015.09.01] 20:22:55 [217.172.190.161][6036280] rsp: 250 OK <menshealth-millionaire-maker@feedtuneup.faith> Sender ok
[2015.09.01] 20:22:55 [217.172.190.161][6036280] cmd: RCPT TO:<karol@myfiberworks.com>
[2015.09.01] 20:22:55 [217.172.190.161][6036280] rsp: 250 OK <karol@myfiberworks.com> Recipient ok
[2015.09.01] 20:22:55 [217.172.190.161][6036280] cmd: DATA
[2015.09.01] 20:22:55 [217.172.190.161][6036280] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2015.09.01] 20:22:55 [217.172.190.161][6036280] rsp: 250 OK
[2015.09.01] 20:22:55 [217.172.190.161][6036280] Data transfer succeeded, writing mail to 58569293.eml
[2015.09.01] 20:22:56 [217.172.190.161][6036280] cmd: QUIT
[2015.09.01] 20:22:56 [217.172.190.161][6036280] rsp: 221 Service closing transmission channel
[2015.09.01] 20:22:56 [217.172.190.161][6036280] disconnected at 9/1/2015 8:22:56 PM
[2015.09.01] 20:23:17 [217.172.190.161][55609656] rsp: 220 mail.pegweb.com
[2015.09.01] 20:23:17 [217.172.190.161][55609656] connected at 9/1/2015 8:23:17 PM
[2015.09.01] 20:23:17 [217.172.190.161][55609656] cmd: EHLO feedtuneup.faith
[2015.09.01] 20:23:17 [217.172.190.161][55609656] rsp: 250-mail.pegweb.com Hello [217.172.190.161]250-SIZE 41943040250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2015.09.01] 20:23:17 [217.172.190.161][55609656] cmd: MAIL FROM:<MensHealth-Millionaire-Maker@feedtuneup.faith> BODY=7BIT
[2015.09.01] 20:23:17 [217.172.190.161][55609656] rsp: 250 OK <menshealth-millionaire-maker@feedtuneup.faith> Sender ok
[2015.09.01] 20:23:17 [217.172.190.161][55609656] cmd: RCPT TO:<jdonovan@northruncorgis.com>
[2015.09.01] 20:23:17 [217.172.190.161][55609656] rsp: 250 OK <jdonovan@northruncorgis.com> Recipient ok
[2015.09.01] 20:23:18 [217.172.190.161][55609656] cmd: DATA
[2015.09.01] 20:23:18 [217.172.190.161][55609656] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2015.09.01] 20:23:18 [217.172.190.161][55609656] rsp: 250 OK
[2015.09.01] 20:23:18 [217.172.190.161][55609656] Data transfer succeeded, writing mail to 58569296.eml
[2015.09.01] 20:23:18 [217.172.190.161][55609656] cmd: QUIT
[2015.09.01] 20:23:18 [217.172.190.161][55609656] rsp: 221 Service closing transmission channel
[2015.09.01] 20:23:18 [217.172.190.161][55609656] disconnected at 9/1/2015 8:23:18 PM
[2015.09.01] 20:23:24 [217.172.190.161][65762983] rsp: 220 mail.pegweb.com
[2015.09.01] 20:23:24 [217.172.190.161][65762983] connected at 9/1/2015 8:23:24 PM
[2015.09.01] 20:23:24 [217.172.190.161][65762983] cmd: EHLO feedtuneup.faith
[2015.09.01] 20:23:24 [217.172.190.161][65762983] rsp: 250-mail.pegweb.com Hello [217.172.190.161]250-SIZE 41943040250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
[2015.09.01] 20:23:25 [217.172.190.161][65762983] cmd: MAIL FROM:<MensHealth-Millionaire-Maker@feedtuneup.faith> BODY=7BIT
[2015.09.01] 20:23:25 [217.172.190.161][65762983] rsp: 250 OK <menshealth-millionaire-maker@feedtuneup.faith> Sender ok
[2015.09.01] 20:23:25 [217.172.190.161][65762983] cmd: RCPT TO:<mike@maskconsultantssc.com>
[2015.09.01] 20:23:25 [217.172.190.161][65762983] rsp: 250 OK <mike@maskconsultantssc.com> Recipient ok
[2015.09.01] 20:23:25 [217.172.190.161][65762983] cmd: DATA
[2015.09.01] 20:23:25 [217.172.190.161][65762983] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2015.09.01] 20:23:25 [217.172.190.161][65762983] rsp: 250 OK
[2015.09.01] 20:23:25 [217.172.190.161][65762983] Data transfer succeeded, writing mail to 58569297.eml
[2015.09.01] 20:23:26 [217.172.190.161][65762983] cmd: QUIT
[2015.09.01] 20:23:26 [217.172.190.161][65762983] rsp: 221 Service closing transmission channel
[2015.09.01] 20:23:26 [217.172.190.161][65762983] disconnected at 9/1/2015 8:23:26 PM

7 Replies

Reply to Thread

Rolf Jacobs Replied

9/3/2015 at 9:41 AM

Having the SAME problems here.... Any recommendations?

Patrick Hedgepath Replied

9/3/2015 at 10:09 AM

I sent in an email ticket and this is the reply I got yesterday but I have heard nothing back today. Looking around on the forums this is happening to more than just the 2 of us so something weird is going on. I'll post here if they let me know how to fix it.

Hi Patrick,
Yeah, something doesn't seem quite right here. I'm going to check with our developers on this. I'll try to get you an answer as soon as possible.

Regards.

Rolf Jacobs Replied

9/8/2015 at 7:09 AM

Any word back from SM yet?

I installed the latest SmarterMail 14.2.5711. Didn't seem to make any difference.

One additional note*..... We are getting two identical emails sequentially. Users have their typical account login which consists of their first and last name (firstlast@domain.com) along with an alias that only includes their first name (first@domain.com). So email is being sent to both at the same time and appears in the inbox as two identical emails back to back.

The email origins are all from domains .faith, .racing, .win and .date but are not being flagged as SPAM.

I have tried blocking these in the admin area "Domain Blocking" using .domain as the blocked address but this does nothing.

Perhaps my syntax is incorrect. Would be nice to completely exclude these suffix as we never communicate with these new domain extensions.

There are additional SPAM messages being sent from .com domains but these messages ARE being flagged and moved to Junk. They only appear to be sent to one address or the other (firstlast@domain.com or first@domain.com) but not both back to back like the other suffix .faith, .racing, .win and .date.

Let me know if you hear back from them.

Rolf Jacobs Replied

9/8/2015 at 1:34 PM

Another Update.....

I just noticed that starting at just after 10am this morning all the SPAM originating from .racing seems to be making its way to the Junk folder. No not see SPAM from the other usual suspects .win, .date and .faith

Ironic that it changed on the heels of my earlier mail.

Still monitoring.

Rolf Jacobs Replied

9/8/2015 at 2:13 PM

No sooner did I send the previous post than duplicate SPAM arrived in both the firstlast@domain.com and first@domain.com boxes from the .win domain.

Rolf Jacobs Replied

9/8/2015 at 2:14 PM

Are you seeing any change in behavior?

Patrick Hedgepath Replied

9/8/2015 at 3:04 PM

Ok here is what my adventure yielded. Here is a topic they have going on it.

http://portal.smartertools.com/community/a86882/postermaster-messages-in-smartermail-14_x.aspx

Here is what he recommended. Apparently they made a change to how postmaster@ accounts were handled.

I am Robert Emmett, one of the developers of SmarterMail. All of those postmaster@<domain> entries that you are seeing in the SMTP logs are legitimate deliveries. According to the RFC, we are supposed to handle messages to postmaster@. In previous additions of SmarterMail, if a domain did not have a postmaster user/alias and the system admin did not have an overall postmaster address entered, the message was completely ignored. To ensure that we were in better compliance with the RFC, we made the decision in SM 14.x that if a domain did not have a postmaster user/alias configured it would be delivered instead to the primary domain administrator. This is probably why your primary domain administrators are now seeing these messages being delivered to them.

There are a few things that you may try to rectify this:

1. Create a postmaster user for each domain. This ensures that postmaster@<domain> messages will be properly delivered to an existing account.

2. Create a postmaster alias for each domain. With this option you can set the alias up so that it does not have any recipients in which case the messages just "disappear," but you have also actively chosen not to receive those messages. This option also does not take up a user license.

3. Enter a system level postmaster address. If the domains do not have a postmaster address, SmarterMail will try delivering to the system level postmaster address.

4. Make the domain primary admin accounts not set to a "normal-everyday" domain user.

5. Make a domain level event that triggers on recipient "postmaster"

I understand the frustration you are experiencing, and I have spoken with the development team. We did not fully anticipate the spamming abuse this could cause. We are contemplating adding a system administrator option to deliver postmaster@ messages to the primary domain administrator if the postmaster@ account/alias does not exist. This setting could then be propagated to all domains, as desired. I am going to start a community thread asking for community opinions on this matter before we implement any change.

I hope this explains our current position, possible workarounds, and a potential change/solution to address the issue better.

Back to Community Threads

Please leave this box unchecked

Block Type	EHLO Domain
Blocked Address
Description

7 Replies

Reply to Thread

Tags

Related Knowledge Base Articles