Odd spoofing scenario

[EKjellquist]

Guys,

I recently updated our installation to the current 4.2.1, and I'm wondering if you have an idea how I can prevent a particular kind of spoof. I'm using blacklists / RBL / SPF / Spamtrap / Tarpitting as well as requiring secure connections where possible, and largely this has worked out well to keep my server secure. However, I recently got a spam that I'm not clear on as far as how it passed through:

SMTP excerpt (I put in [real address] and [obviously bad domain] to replace some identifying strings):

Tue, 06 Dec 2016 10:39:07 -> 84.255.249.10 -> Success: Action=[Accept Connection], Details=[Port 25]
Tue, 06 Dec 2016 10:39:07 -> 84.255.249.10 -> Success: Action=[Received Hello], Details=[Host=84-255-249-10.static.t-2.net]
Tue, 06 Dec 2016 10:39:08 -> 84.255.249.10 -> Success: Action=[Received Sender], Details=[untutoredllzr@[obviously bad domain].com]
Tue, 06 Dec 2016 10:39:10 -> 84.255.249.10 -> Success: Action=[SPF Check], Details=[Domain=[obviously bad domain].com, Result=NONE]
Tue, 06 Dec 2016 10:39:10 -> 84.255.249.10 -> Success: Action=[Received Recipient], Details=[[real address]@audiosears.com]
Tue, 06 Dec 2016 10:39:10 -> 84.255.249.10 -> Success: Action=[Received Recipient], Details=[[real address]@audiosears.com]
Tue, 06 Dec 2016 10:39:10 -> 84.255.249.10 -> Success: Action=[Received Recipient], Details=[[real address]@audiosears.com]
Tue, 06 Dec 2016 10:39:10 -> 84.255.249.10 -> Success: Action=[Start Mail Transaction]
Tue, 06 Dec 2016 10:39:11 -> 84.255.249.10 -> Success: Action=[Bayesian Scoring], Details=[Score=50.62%]
Tue, 06 Dec 2016 10:39:11 -> 84.255.249.10 -> Success: Action=[Complete Mail Transaction], Details=[From Host=84-255-249-10.static.t-2.net, Size=2 KB, From=untutoredllzr@[obviously bad domain].com, To=[real address]@audiosears.com;[real address]@audiosears.com;[real address]@audiosears.com]
Tue, 06 Dec 2016 10:39:11 -> 84.255.249.10 -> Success: Action=[Close Connection]

The fact that this email came through in and of itself is ok (the filters can't stop everything), but viewing the source of this email, the sender address is NOT untutoredllzr@[obviously bad domain].com but is instead one of our mailing list addresses, in which the box for 'Enable SMTP Sender' is NOT checked (none of our mailing list addresses are enabled for this):

Received: from 84-255-249-10.static.t-2.net ([84.255.249.10]) by mail.audiosears.com
with SMTP (Code Crafters Ability Mail Server);
Tue, 06 Dec 2016 10:39:10 -0500
Message-ID: <HHKA1951.5080861@[obviously bad domain].com>
Date: Tue, 6 Dec 2016 15:53:57 +0100
From: "[real mailing list address]@audiosears.com" <[real mailing list address]@audiosears.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: <[real address]@audiosears.com>
Subject: RE: RE: insurance
Content-Type: multipart/alternative;
boundary="------------010107070709000707020804"

This is a multi-part message in MIME format.
--------------010107070709000707020804
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

So I'm guessing one of two things happened; (1) the current version of AMS may not be checking properly to make sure mailing lists aren't being used as SMTP senders when not set up that way or (2) there's some level of spoof here where the sender is changing the to: address AFTER the antispam checks are performed. If the scenario is (2), is there a way to ensure that a SMTP sender cannot change the to: address midstream (much less use a to: address that should be unusable in this case)?

[Code Crafters]

There is an SMTP Sender (MAIL FROM) and SMTP Recipients (RCPT TO) from the SMTP delivery envelope which is present during the SMTP conversation and this is used for SPAM filtering and delivery.

The header lines From, To, Reply-To etc are in the raw email content and this is what your mail client / WebMail will show you when you read the email.

We used to have a SPAM filter in the very early years of Ability Mail Server to block emails where the SMTP Sender and From Header Line didn't match but this produced far too many false positives (cases where this was the true for legitimate emails) to but useful as a general rule. You can set up content filter rules for particular cases such as your mailing list being used as a From Header Line where the SMTP Sender isn't blank or whatever you expect.

You can also use the Sender Domain Check SPAM filter to stop people sending from your domain if they are not authenticated or if the email address on that domain doesn't exist on Ability Mail Server. However, in your scenario this won't help as the delivery SMTP Sender isn't your domain.

Mailing Lists should always use a subject trigger phrase for authentication to make sure nobody can send to the mailing list without this passphrase in the subject (it is stripped out before delivery). You can also tick the option that the sender should be in the mailing list delivery list if this is the case.

In summary, you probably want a content filter rule to block emails that appear to come from (From header line) your mailing list but don't have the correct SMTP Sender.

[EKjellquist]

That's just the thing, we ARE using sender domain check; there have been a few instances of similar spoofing where an email came through (as above) but from a non-existing user account as the from address (present in the source email), but in the SMTP log as from a (probably bad) address - is it possible the from address could be being switched due to some flaw in the SMTP handshake AFTER AMS allows the mail to come in but BEFORE it's actually received?

[Code Crafters]

Sender Domain Check only affects email from your Ability Mail Server domains, not any others. As we said before, checking for SMTP delivery and Mail header senders / recipients matching provides too many false positives to be a general rule so you need to set up content filter rules for specific cases. People can spoof the header lines being different from the SMTP delivery information. However, usually enough other SPAM filters (Grey listing, RBLs, SPF, Bayesian) will block them as SPAM anyway. We recommend the following SPAM setup:

Basic Filtering:
1) Make sure you’re running version 2.70 or higher.
2) Run the SPAM wizard from the dialog admin interface for medium level protection. Grey listing is very effective and should stop 80% of all SPAM on its own. RBLs are also very good SPAM protection.
3) Set up any black / white listing that you need. The relaying exemption option will allow any authenticated users to bypass SPAM filtering.

Advanced Filtering:
4) If you want to also do Bayesian filtering, this take a bit of setting up but is by far the most effective SPAM filter available.
a) Set up Bayesian filtering to use only the Auto-Learn from Users training method. Add participating users and appropriate SPAM / non-SPAM folders to the Bayesian settings.
b) Get Participating users to sort their mail into SPAM / non-SPAM folders where Bayesian will automatically learn from them periodically.
c) You need to disable rejecting (deleting) the email on all SPAM filters so that the SPAM flag is set and the mail is allowed to pass through.
d) Set up Content Filtering with the Preset Content Filter Rule (Add Preset button) “SPAM Identifier”. This rule will mark SPAM detected mails with <SPAM> in the subject so that they can be more easily identified and moved to the SPAM folder. Bayesian is a learning system so once it is well trained (minimum of 1000 SPAM and 1000 non-SPAM mails) you can set this content filter rule to also place mails in the SPAM account directory but don’t do this until you are happy it is training accurately and you must then check your SPAM folder for false positives (mails wrongly marked as SPAM that aren’t really SPAM) and move them appropriately.

Grey listing will block 80% of SPAM generally. Beyond that RBLs is your next best. However, this will occasionally have a false positive so we filter RBL-Fails into another folder to filter good emails back into Inbox and copy the rest into a Junk E-mail folder. We then use this Junk E-mail folder together with an archive of good emails as training folders for the Bayesian filter with user-learning which over time will capture most of your other SPAM as it becomes better trained. We recommend again filtering Bayesian SPAM into another folder for manual inspection to put good emails back into Inbox and rest into Junk E-mail to help further train Bayesian but generally wait until you have at least 1000 of each good / SPAM mails trained first. You can also use black and white lists to filtering common bad IPs / domains. The rest of the filters will help too. Default settings for these are usually fine (medium setting via the SPAM wizard). Also you can use the relaying exemption check box on the first page of SPAM filtering settings to allow authenticated users to bypass SPAM filtering.

[EKjellquist]

We do use Bayesian filtering (actually we use everything BUT transaction delays and greylisting - for us it wasn't found to be worth it because there were too many delays where contacts were trying to mail us quickly and lots of panicked phone calls when they didn't understand the message, and also because (believe it or not) a good amount of spam was STILL being delivered even with a 60 minute delay).

I did have to clean out and retrain the Bayesian filter after upgrading from 2.72 to 4.2.1, but between that, RBL, SPF, spamtraps, tarpitting, sender domain check, the static block list, AV filtering, etc they've been largely effective since 2006 when we first bought AMS.

I do use content filtering to quarantine everything from user inboxes that's between 65-85% spam (via Bayes) and auto block anything at 90% or above, which has been very useful.

[Code Crafters]

Past tests have shown that Grey Listing can stop 80% of all SPAM. We changed the window retry start time to 1 minute instead of 60 to allow this to work better. Grey Listing is based on the fact that email servers will retry delivery but SPAM clients won't.

On our own email server, we have content filter rules to move RBL and Bayesian fails to a folder each to check for false positives before moving them to Junk E-mails to be used for Bayesian training along with Archive folders.

Bayesian technically should be per user rather than per server and hopefully we can make this change in a future update to improve the accuracy of this filter.

[EKjellquist]

I'd be in favor of per-user Bayesian rules; largely it works well as is, but it's impossible to distinguish between two or more users where one thinks mail X is spam, but the others actually solicit it;

[Code Crafters]

This will probably be a fairly big change but we'll try to implement it in a future update at some point.