Bypass spam filtering for authenticated users?

19 posts / 0 new
Last post
#1 Fri, 08/24/2007 - 16:59
brainyron

Bypass spam filtering for authenticated users?

When certain users send email on my server to other local users, they are being marked as spam. This brings up my question: How can I bypass spam and virus scanning entirely for authenticated senders, or at the very least, have spamassassin reduce the score for these users?

Fri, 08/24/2007 - 21:37
Joe
Joe's picture

Howdy Ron,

It's a better idea to figure out why those messages are being blocked--they will trigger spam filters on other servers, as well, so better to fix the problems rather than workaround them.

So, check the headers of the offending messages and find the "X-Spam-Status" and "X-Spam-Report" fields. See what tests are failing, check the SpamAssassin documentation for further details if you aren't sure what they mean. And fix those problems! Most of them will probably be related to DNS.

If you aren't sure how to fix them, bring the big ones up here, and we'll help you sort it out.

If, after all of that, you find that users still get blocked, and you can't educate them about sending less spammy messages, you've got several options, and permitting them without spam/AV filtering is one of them. But it's a bit tricky, because the obvious place to permit that, in SpamAssassin, doesn't allow it to be particularly discriminating (the sender of spam could lie and pretend to be from one of your domains), so it probably ought to happen in Procmail.

We'll cross that bridge when we come to it. I bet we can make this problem go away just by fixing your mail server and DNS server configuration.

--

Check out the forum guidelines!

Tue, 08/28/2007 - 16:42 (Reply to #2)
ConRadical

I have this same problem also and i've had to white list the domains.

For the record i pointed this out some months ago but i believe it was written off, stating that it's not a virtualmin issue.

THE PROBLEM...
Variables
UserA -on the same domainA.com --IP is X.1.1.2
UserB -omn the same domainA.com --IP is X.1.1.5
DomainA.com - Is a virtual domain on virtualmin (server IP X.1.1.10

Lets say userA sends and email to userB.
when userB looks at the headers the received portion(in the headers) will display the IP of userB(x.1.1.2)

If user B is using residential DSL or something and is listed in and DNSBL/RTBL their email is going to be moved to spam or bounced.

Wed, 08/29/2007 - 19:59 (Reply to #3)
Joe
Joe's picture

<div class='quote'>For the record i pointed this out some months ago but i believe it was written off, stating that it's not a virtualmin issue.</div>

I can't imagine we would do such a thing. ;-)

<div class='quote'>If user B is using residential DSL or something and is listed in and DNSBL/RTBL their email is going to be moved to spam or bounced.</div>

The solution here is probably to reduce the importance of the particular DNSBL that triggers on these addresses. This can be configured in the Spam Assassin module (or in the system-wide SpamAssassin configuration).

Note, however, that I'm not saying you CAN'T specifically permit addresses--the system-wide white/black lists work fine--you can find them in Spam Assassin's Allowed and Denied addresses page (and if you are using the per-user/per-domain spamassassin configuration that we setup by default, it can be done on a per-user or per-domain basis, as well). I'm saying that spammers often use these whitelists against you. I get lots of spam claiming to be from support@virtualmin.com...if I whitelist that address, it's all coming straight to me and there's nothing SA will do about it. But, if I look at the filtered messages and figure out what makes them uniquely &quot;good&quot; versus all the spam that comes in, I can tune the SA rules to make it work.

But that's complicated. So maybe whitelisting is the way to go, just to get folks off your back. ;-)

--

Check out the forum guidelines!

Wed, 08/29/2007 - 21:21 (Reply to #4)
ConRadical

<div class='quote'>
The solution here is probably to reduce the importance of the particular DNSBL that triggers on these addresses. This can be configured in the Spam Assassin module (or in the system-wide SpamAssassin configuration).</div>

I've tried this Joe, but spams just starts pouring into the inbox.

<div class='quote'>
Note, however, that I'm not saying you CAN'T specifically permit addresses--the system-wide white/black lists work fine--you can find them in Spam Assassin's Allowed and Denied addresses page (and if you are using the per-user/per-domain spamassassin configuration that we setup by default, it can be done on a per-user or per-domain basis, as well). I'm saying that spammers often use these whitelists against you. I get lots of spam claiming to be from support@virtualmin.com...if I whitelist that address, it's all coming straight to me and there's nothing SA will do about it. But, if I look at the filtered messages and figure out what makes them uniquely &quot;good&quot; versus all the spam that comes in, I can tune the SA rules to make it work.
</div>

I agree, spammers just the whitelist against you, in fact the only spam that hits my inbox is from &quot;myself&quot;.

I've tons and tons of tunning to SA, but the only problem i have now is with the IPs of legitimate home or mobile users being on DNSBL because their IP is in a dynamic address range...etc

<b>Joe/Anyone...</b> Can you think of a way to bypass SA when the incoming me was authenticated?

Thu, 08/30/2007 - 20:21 (Reply to #5)
ConRadical

Joe/Anyone... Can you think of a way to bypass SA when the incoming me was authenticated?

that's what i meant to say on that last line... for some reason i can't edit my post.

Fri, 08/31/2007 - 02:11 (Reply to #6)
Joe
Joe's picture

Nothing immediately obvious. Procmail doesn't know that you've authenticated, and authenticated mail looks just like all other mail sent to the server.

And actually...I'm not sure your client had to authenticate to send to accounts on the system--I don't think the authentication challenge is ever sent if the mail is addressed to someone on the server (it all happens on port 25, and you have to allow non-authenticated users to send to your addresses). So, these may not even be authenticated messages.

I'll have to look into it...there really ought to be some way to deal with it.

--

Check out the forum guidelines!

Thu, 08/30/2007 - 12:25 (Reply to #7)
ConRadical

<div class='quote'>
Nothing immediately obvious. Procmail doesn't know that you've authenticated, and authenticated mail looks just like all other mail sent to the server.

And actually...I'm not sure your client had to authenticate to send to accounts on the system--I don't think the authentication challenge is ever sent if the mail is addressed to someone on the server (it all happens on port 25, and you have to allow non-authenticated users to send to your addresses). So, these may not even be authenticated messages.

I'll have to look into it...there really ought to be some way to deal with it.</div>

You're right, the client doesn't have to authenticate to send to accounts on the system, i didn't even think about that. What about some kind of graylist?

Thu, 08/30/2007 - 12:36 (Reply to #8)
ConRadical

<div class='quote'>
Okay - I'm staring to think heavily that his install really *should* use SpamAssassin Milter.

Are you using a Virtualmin Pro stock install, or is this a build-your-own? What MTA are you using? QMail, Sendmail, what?

If it supports milters, I would suggest you give it a try if you have the levity to do so. It gets called at SMTP connection time, and will call sendmail from there. Then use /etc/mail/access (in the case of sendmail) and put an entry in like:

IP.BLOCK OKAY
domain.com ALLOW

These will completely ignore the DNSRBL's at SMTP connection time, and then as Joe mentioned, you need to lower the priority of the associated SpamAssassin rules that refer to those, or disable DNSRBL's from SpamAssassin entirely, and use the MTA's in-built support for DNSRBL's (almost all modern MTA's support this).

Do you agree Joe? I know this is not explicitly supported by Virtualmin, but it sounds like his mail environment is not so different from my own. &lt;plug&gt;Also, if you need direct help, I am available to do consulting work. :)&lt;/plug&gt;
</div>

Tony...

it's Virtualmin Pro and running postfix. I also tried milters awhile back but i still have the problem with users who are traveling and using a verizon card or hotspot their emails were refused...

This is why i've put them in SA so users can at least check their junk /spam folder.

Thu, 08/30/2007 - 12:45 (Reply to #9)
TonyShadwick

<b>Joe wrote:</b>
<div class='quote'>Howdy Ron,

It's a better idea to figure out why those messages are being blocked--they will trigger spam filters on other servers, as well, so better to fix the problems rather than workaround them.

So, check the headers of the offending messages and find the &quot;X-Spam-Status&quot; and &quot;X-Spam-Report&quot; fields. See what tests are failing, check the SpamAssassin documentation for further details if you aren't sure what they mean. And fix those problems! Most of them will probably be related to DNS.

If you aren't sure how to fix them, bring the big ones up here, and we'll help you sort it out.

If, after all of that, you find that users still get blocked, and you can't educate them about sending less spammy messages, you've got several options, and permitting them without spam/AV filtering is one of them. But it's a bit tricky, because the obvious place to permit that, in SpamAssassin, doesn't allow it to be particularly discriminating (the sender of spam could lie and pretend to be from one of your domains), so it probably ought to happen in Procmail.

We'll cross that bridge when we come to it. I bet we can make this problem go away just by fixing your mail server and DNS server configuration.</div>

That's actually perfect. I think. :)

At least on Sendmail, you can set up SMTP-Auth to where milters are bypassed for authenticated users. Just have them use STMP Auth, DNSRBLs are bypassed, as are the milters. Problem solved.

Thu, 08/30/2007 - 12:50 (Reply to #10)
ConRadical

<div class='quote'>
At least on Sendmail, you can set up SMTP-Auth to where milters are bypassed for authenticated users. Just have them use STMP Auth, DNSRBLs are bypassed, as are the milters. Problem solved.</div>

Actually i'll have to check into SMTP-Auth for postfix... i'll check back here.

Fri, 08/31/2007 - 08:04 (Reply to #11)
ConRadical

I found this:
http://www200.pair.com/mecham/spam/bypassing.html#10

... it looks like adding 'smtpd_sasl_authenticated_header = yes' to postfix's main.cf will keep SA from checking the users... I added this to postfix and it added &quot;(Authenticated sender: &quot;USERNAME HERE&quot;) &quot; to the headers, now i'm going to remove some of the white listings and see if SA will actually let them thru.

Fri, 08/31/2007 - 08:22 (Reply to #12)
ConRadical

And it seems to be working... i'll let you guys know how it pans out

Fri, 08/31/2007 - 08:39 (Reply to #13)
ConRadical

And BTW, Joe just pointed out that not all platforms have the required versions of postfix and SA for smtpd_sasl_authenticated_header. You must be using Postfix 2.3.x, and SpamAssassin 3.1.4 or newer -- to quickly see what versions you're running open up virtualmin -&gt; system infromations -&gt; expand programs.

Tue, 08/28/2007 - 18:41
TonyShadwick

Virtualmin notwithstanding, the way I've dealt with this in the past is to call SpamAssassin from spamass-milter, and pass exclude flags for localhost, and any &quot;trusted&quot; networks. That way local filtering is disabled. I honestly don't know what mechanism virtualmin uses, but spamass-milter has a bypass for this built in.

Thu, 08/30/2007 - 12:09
TonyShadwick

Okay - I'm staring to think heavily that his install really *should* use SpamAssassin Milter.

Are you using a Virtualmin Pro stock install, or is this a build-your-own? What MTA are you using? QMail, Sendmail, what?

If it supports milters, I would suggest you give it a try if you have the levity to do so. It gets called at SMTP connection time, and will call sendmail from there. Then use /etc/mail/access (in the case of sendmail) and put an entry in like:

IP.BLOCK OKAY
domain.com ALLOW

These will completely ignore the DNSRBL's at SMTP connection time, and then as Joe mentioned, you need to lower the priority of the associated SpamAssassin rules that refer to those, or disable DNSRBL's from SpamAssassin entirely, and use the MTA's in-built support for DNSRBL's (almost all modern MTA's support this).

Do you agree Joe? I know this is not explicitly supported by Virtualmin, but it sounds like his mail environment is not so different from my own. &amp;lt;plug&amp;gt;Also, if you need direct help, I am available to do consulting work. :)&amp;lt;/plug&amp;gt;

Thu, 08/30/2007 - 17:42 (Reply to #16)
Joe
Joe's picture

A milter doesn't solve this problem--the rules you've mentioned are no different when used in a milter or via procmail. Conrad wants to act on information that can't be seen by milter or procmail, I think.

Though I did just do some testing, and we are actually authenticating even when the destination is local. So, the information exists somewhere, just not by the time the message gets to procmail. I'll look into the milter interface (Postfix 2.2 supports milters), but I don't think it has the data either.

If there is a way to do it, it'll maybe have to be via some sort of marking of incoming messages at the SMTP level. I dunno. This is a much trickier problem than it seems on the surface.

--

Check out the forum guidelines!

Fri, 08/31/2007 - 09:53
TonyShadwick

FYI - spamass-milter can and does get bypassed when using smtp-auth, Joe. :) If configured right anyway. Glad to see you got it working!

Wed, 10/03/2007 - 07:00
brainyron

For those who are using Ubuntu Dapper which does not have the required Postfix version, look into Prevu (<a href='https://wiki.ubuntu.com/Prevu' target='_blank'>https://wiki.ubuntu.com/Prevu</a>). It'll let you build the Feisty version of Postfix for Dapper. The package built without error for me and I'll be testing it soon.

Topic locked