Unclear on SPF etc.

by **hecklertm** » Wed Nov 12, 2008 3:10 am

I am getting emails that are sent from a remote ip directly to my mail server and the spam is labeled as to me and from me. What setting in the server will stop this spammer from being able to send the mail to me using my address as the return address also. I assume sine it id a local account, it will allow the relay, but can't the server know not to allow someone claiming to have my address to send mail illegitimately to me. 83.240.137.83 was showing as an open relay at the time.

Any insight would be great. Thanks.

Here is a sample email

Received: from [83.240.137.83] ([83.240.137.83]) by mail.instaburst.com
with SMTP (Code-Crafters Ability Mail Server 2.61);
Mon, 10 Nov 2008 06:14:26 -0600
To: <th@hypewifi.com>
Subject: Your private life compromised
From: <th@hypewifi.com>
MIME-Version: 1.0
Importance: High
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<html>
<body>
<tr>
<td class=EC_container bgcolor="#F2F2F2">
<table cellpadding=0 cellspacing=0 width="100%">
<tr>
<td>

<div align=center> <a href="http://botzjj.dvaidzg.cn" target="_blank"><img src="http://njgycp.dvaidzg.cn/3.gif" border=0 alt="Click Here!"></a> </div>
</td>
</tr>
<tr>
<td class=EC_legal>
<strong>About this mailing: </strong><br>
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe
you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service
advertised. Prices and item availability subject to change without notice.<br><br>

?2008 Microsoft | <a href="http://www.dvaidzg.cn/" target="_blank">Unsubscribe</a> | <a href="http://vwzot.dvaidzg.cn" target="_blank">More Newsletters</a> | <a href="http://knnursa.dvaidzg.cn" target="_blank">Privacy</a><br><br>
Microsoft Corporation, One Microsoft Way, Redmond, WA 98052

</td>
</tr>
</table>
</td>
</tr>

</table>

by **Code Crafters** » Wed Nov 12, 2008 11:04 am

There are 2 SPAM filters that can help here.

1) SPF allows you to add an SPF record for your domain which indentifies which IPs are authorised to send mail from your domain. If the receiving mail server supports SPF and has it enabled then the mail will be blocked if it doesn't have its IP appear in the SPF record. A typical record would be "v=spf1 mx ptr ~all" which would allow any IPs listed as MX records for the domain or any IPs whose reverse DNS lookups (PTR) resolves correctly to the domain.

2) Sender Domain Check (SPAM filtering settings again) is specifically desgined to stop users sending unathorised mail to your mail server from your own local domains. There are options to block mail from local domains if the user doesn't exist locally for that domain and also to block if the client is not authorised via SMTP authentication by logging into the SMTP when sending mail to your mail server. Note that enabling this filter can cause issues with users who don't currently correctly log into the outgoing mail server for SMTP authentication on their mail client (e.g. outlook) but as long as they do this there should be no problems.

You can also use white / black listing to always allow / block certain IPs, senders etc. and can check the option for relaying exemption on the first page of the SPAM filtering settings to allow any users logged in to SMTP authentication to bypass all SPAM filters since they are already authorised as being a legitimate local user.

by **hecklertm** » Thu Nov 13, 2008 5:23 am

Thanks for your response. Sender domain check is on, but the person still send email.

From what I understand, why would the mail server ask someone to authenticate via SMTP for them to send a message to a local account on mail server. That would mean that all incoming mail to my server would require servers to authenticate to deliver mail to my local accounts.

SMTP authentication is used when someone tries to send mail to a non-local account.

So, since my email address is obviously local to my own mail server, how do I stop my mail server from excepting mail destined for my local account if the email headers say that my email address is also the from address (which obviously it is not since I did not send it to myself).

How can the ability mail server refuse mail that is destined for a local account if the sender/spammer forged the from address to be the same local account on the mail server?

Obviously this is an attack we have seen many times over the years. A spammer gets your email address, then he finds out the IP of your mail server though nslookup, and he sends you a spam directly from his bulk mail app to your server, and he also forges your email address as the return address too.

Since the mail server checks first to see if the email is destined for a local account, it never bothers doing smtp authentication because it was not necessary.

What can I do?

by **Code Crafters** » Thu Nov 13, 2008 10:53 am

The side effect of using Sender Domain Check is that the option to require SMTP authentication for local domains means that even mail delivered locally will now require setting up your mail client to log into the outgoing mail server as well as the incoming mail server but if you ever want to relay mail you'd have to do this anyway. SPAMers won't be able to authenticate unless a username / password has been comprimised and will therefore be blocked. Only white listing can bypass this filter when the user isn't authenticated but otherwise it will work at the expense of having to log in to deliver locally.

SPF records will limit which other mail servers are allowed to send mail from your domain and will help but isn't as directly responsible for stopping this problem as Sender Domain Check which is specifically designed for this exact type of attack.

by **hecklertm** » Fri Nov 14, 2008 8:11 am

I need to make sure we are on the same page. ..

I already use SMTP authentication.

But, when an external sender is sending mail to detstined to me, they DO NOT have to authenticate with my mail server, since they are not a user of my mail server.

Since they are sending the mail to me, my server (which sees my address as local for delivery) unconditionally accepts the mail, assuming it passes incoming spam filters. This is how SMTP works and how I understand Ability mail is processing the incoming messages.

Now, what I am trying to prevent is a person out on the Internet sending me an email and forging the from address to act as if the email originated from me. Is this not possible? Can the server not look at the headers and say, "Wait a minute. The from address you put in the email is an address that is local to me. Since you did not originate the email through me, I am not going to allow you to deliver this message to any local mailbox that I handle. If you are sending mail using a from address that I know is local to me, it should be originating through me where I can do SMTP authentication on you first, to confirm that you are not a fake."

Haven't you ever received a spam message that said it was sent from your email address? Everybody has. That way, an ignorant recipient believes that they don't have any way to know who to complain to about the spam (since they dont know about reading the headers).

I just want to know if the ability mail server has a way to prevent the "from address" forging from occurring on incoming messages when the forged "from address" is the same as the "to address."

Mail servers do not standardly ask for SMTP authentication if the the destination of the mail is for local delivery, only when relaying to another server.

What am I missing? Maybe no SMTP servers block this type of spam...

by **hecklertm** » Fri Nov 14, 2008 8:49 am

From what I read, Sender Domain Check is supposed to do exactly what I am asking, but it is not doing it. I doubt seriously that some spammer in China has my mail password to send mail using my email account. Any other suggestions.

by **Code Crafters** » Fri Nov 14, 2008 11:27 am

I do understand your scenario and Sender Domain Check works perfectly for this situation but let me explain in more detail so you're confident of what's going on with it.

1) Mail from external senders (domains not hosted by your AMS) do not need SMTP authentication to deliver locally to you nor will they be subject to any Sender Domain Check filtering. Sender Domain Check works only when senders are from local domains. Obviously, these recipients cannot relay mail to external users for SPAM policy reasons.
2) Mail from senders on your local domains need to use SMTP authentication only for relaying mail to external email addresses normally; local delivery is allowed by any sender. However, Sender Domain Check increases security by also requiring local senders to use SMTP authenticiation for sending mail for local delivery as well as external relaying which obviously if you relay mail you would already have this setup in your mail client. WebMail is automaticaly SMTP authenticated. Requiring all local users to authenticate that they are legitimate users when sending mail will guarantee to stop any unauthorised mails forged as local users when they aren't really from local users. The only way round this is by white listing, SMTP relaying safe IPs or usernames / passwords being comprimised.

by **Jodrik** » Fri Nov 21, 2008 10:02 pm

I kept having this very same issue and neither SPF and Sender Domain Check seemed to help. Or in more then alot of cases SPF and SDC ruled to many positives to be considderd reliable.

I implemented RLBs to cut down on alot of SPAM, adding 5 of them cut down this type of SPAM immensely. I've also added a private RBL using a locally run DNS server, currently added some features to allow my own SPAM trap to feed this RBL server automatically instead of having to do it manually. Simple but effective.

by **Code Crafters** » Mon Nov 24, 2008 11:00 am

Grey Listing will usually stop 80% of all SPAM. Bayesian is the most effective SPAM filter but requires more attention as it's a learning system but will stop 99.5% of all SPAM once well trained. We get over 1000 SPAM mails a day and rarely see even one hit our Inbox now mostly due to Bayesian alone. We reocmmend the following setup for your SPAM filtering.

Basic Filtering:
1) Make sure youâ€™re running version 2.63.
2) Run the SPAM wizard from the dialog admin interface for medium level 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 today.
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.

Unclear on SPF etc.

Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Re: Unclear on SPF etc.

Who is online