Blocking un-authorized local SPAM

P

Percy

Verified User
Joined
Jul 11, 2003
Messages
30
Location
Calgary AB
This is a problem that appears to be alluded to in many places on this site, but I have yet to find a proper solution to it either on this site or through Google.

Here is the problem which I have just re-tested and confirmed. I ran into this problem recently when my server was black-listed by Barracuda *again* while I have tested it over and over again to make sure it is not an open relay.

Here is the problem.

1) Some of my clients have e-mail forwarders setup
2) It is possible (for some reason) to send e-mails from a local domain to a local domain without a locally authenticated user.
3) Spammers send e-mail from [email protected] to [email protected].
4) E-mail is (incorrectly) accepted by my server and sent to [email protected] and is then re-directed to [email protected]
5) myotherdomain.com uses Barracuda, the messages get filtered as SPAM, my server gets tagged as the source, and my server gets blocked by all Barracuda servers in the world.

Short of disabling/disallowing all forwarders (which I am tempted to do), I would like to find a proper solution to this.

Exim should NOT accept e-mails sent from/to a local domain from an EXTERNAL source. If it is a LOCAL source (i.e. authenticated local SMTP account, PHP script, etc.) then it should accept, otherwise, it should not.

I tested this with my ISP at work by sending an e-mail to/from my domain which was forwarded back to me. The e-mail went through without any problems. No authentication required at all.

So, the ideal solution would be to block ALL e-mails from ALL un-authenticated EXTERNAL sources. Currently, since my server is not an open relay, it is correctly blocking all e-mails to EXTERNAL sources. But it is accepting unauthenticated LOCAL to LOCAL.

If you feel like testing this out, my server's IP is 66.128.62.146, test forwarder setup at [email protected]. Try sending a message from [email protected] to [email protected] from any other server, and I should get the e-mail.

-Percy
 
I disagree with you.
Exim should NOT accept e-mails sent from/to a local domain from an EXTERNAL source.
Click to expand...
Then how would I send an email from my laptop to my local system so I'll see it in my inbox when I get home?

Jeff
 
jlasman said:
I disagree with you.

Then how would I send an email from my laptop to my local system so I'll see it in my inbox when I get home?

Jeff
Click to expand...

If you read my entire post clearly you would see this is not what I am wanting. My post clearly states that I want to block UNAUTHENTICATED local to local messages. If you send email from yourself to yourself then you should be an authenticated user. However, a forged email that is from an external source should not be allowed to send emails to itself or other users on the server. With that logic, I could heavily spam every user on one server simply by sending them email from themselves.
 
No, I do understand. If I'm using my friend's computer to send email to myself, then it comes from his server (or even his local system), where it's non-authenticated, but the From: field is still [email protected] and it's still coming from the outside world. And I still want the mail.

I could heavily spam every user on one server simply by sending them email from themselves.
Click to expand...
Yes, you can, as lots of spammers have figured out. Unless you install the kind of block you want. And you can certainly do that, but I can't include it in the SpamBlocker exim.conf file, because it prevents wanted emails sent according to the RFC standards.

Jeff
 
jlasman said:
No, I do understand. If I'm using my friend's computer to send email to myself, then it comes from his server (or even his local system), where it's non-authenticated, but the From: field is still [email protected] and it's still coming from the outside world. And I still want the mail.
Click to expand...

If you are sending an e-mail from your friend's computer, then would you not be using one of the following methods:

1) Sending an e-mail through his e-mail account, where the From: would be your friend's e-mail address and not your own, thereby not applying to my scenario. From: != To:, so it does not apply.
2) Sending an e-mail through web mail or some other authenticated method which would also thereby not apply in my scenario?

If you are implying that you would send an e-mail through your friend's mail client and manually change the From: field to your own e-mail address even though it is originating/being sent through his e-mail address, then this seems highly illogical, complicated, and should not be an RFC supported standard.

Maybe I am misunderstanding your example, but to me any conceivable benefits do not seem to be worth anything in comparison to the well proven track record of generating a lot of spam. Perhaps I am also missing how this would be used in every day common usage.

Any and all e-mails I would send from my laptop would be authenticated, no matter where I send it from. If I send it from someone else's computer then I would either 1) send it through webmail so it is local/authenticated, or 2) send it from their e-mail account and then From: != To:, therefore negating my problem.

Please help me to understand this because I do not appear to be understanding your reasoning.

Thanks,
-Percy
 
Try sending a message from [email protected] to [email protected] from any other server, and I should get the e-mail.
Click to expand...

That is correct. The server hosting 7light.com should accept mail for it no matter where it comes from unless you have set up specific filters.

You are also free to set up a filter that prevents mail being sent to the an address that is the same as the from address.
 
floyd said:
That is correct. The server hosting 7light.com should accept mail for it no matter where it comes from unless you have set up specific filters.

You are also free to set up a filter that prevents mail being sent to the an address that is the same as the from address.
Click to expand...

In my mind setup up such a filter in the way I've described would not block any legitimate e-mails.

However, now that I think about it, the original source of my problem is that e-mail being forwarded/redirected through my server that is SPAM makes my server look like it is sending spam, even though it is only acting as a messenger.

In that sense, the actual solution would be to somehow re-direct the e-mail in such a way that my server would not be considered a spammer. Otherwise, forwards are ultimately doomed to always taint the redirecting server's spam score.
 
Percy said:
Sending an e-mail through his e-mail account, where the From: would be your friend's e-mail address and not your own, thereby not applying to my scenario. From: != To:, so it does not apply.
Click to expand...
No, I certainly would (and have) changed the "From:" field. Good email clients (even Squirrelmail and other webmail clients) allow it as a matter of course, and we allow it to our clients for several reasons, two of which are: (1) I use it and (2) I choose to not limit what my clients can reasonably do with their accounts on my servers as long as doing so is reasonably with RFCs.
If you are implying that you would send an e-mail through your friend's mail client and manually change the From: field to your own e-mail address even though it is originating/being sent through his e-mail address, then this seems highly illogical, complicated, and should not be an RFC supported standard.
Click to expand...
Says you.

The RFCs (thankfully) offer flexibility, the ISPs take it away. Me? I do all I can in the name of RFCs and flexibility.
Maybe I am misunderstanding your example, but to me any conceivable benefits do not seem to be worth anything in comparison to the well proven track record of generating a lot of spam. Perhaps I am also missing how this would be used in every day common usage.
Click to expand...
It appears to me I've been defending this from my point of view, but actually my point of view doesn't matter. Since I'm writing an exim implementation for others to use, I really need to offer RFC-allowable behavior.
Any and all e-mails I would send from my laptop would be authenticated, no matter where I send it from.
Click to expand...
Unless your friend or your local Starbucks hotspot transparently rerouted outgoing mail traffic to their own mailservers. AOL does that.
If I send it from someone else's computer then I would either 1) send it through webmail so it is local/authenticated, or 2) send it from their e-mail account and then From: != To:, therefore negating my problem.
Click to expand...
And that's you. And that's why you should be able, and ARE able, to implement the filtering if you want it.

I don't feel comfortable putting into a program used by lots of others besides myself, because it makes life less convenient and it's against RFC standards.

However I point out that DirectAdmin uses my exim.conf file only because they want to; I don't twist their arms. Perhaps if you ask them they'll disagree with me, and write their own, using as much or as little of my code as they'd like, since it's all open-source.

Jeff
 
Now that I think more about it, I do see the value in being able to customize the From: field.

As far as AOL/Starbucks is concerned, I send all my mail through port 587, and in my usage I have yet to find a location that redirects port 587. Definitely port 25, but not 587.

I guess really it would just seem that fundamentally at the core of the e-mail transportation system there are some flaws that make spam a big problem, since at the time of inception, these problems did not exist or were simply not thought of as a potential problem down the road.

Anyway, I guess there's no real solution to my problem without breaking standards -- however, it still leaves me with my original problem -- my server getting a bad reputation for simply forwarding e-mail for one of my domains. I'm just the "messenger"...

Unless my spam filtering catches enough of the spam pre-forwarding to alleviate redirecting said spam, then it seems like my only other pro-active alternative would be to deny forwards altogether?

Maybe you can provide some insight into the actual root cause/problem?
 
AOL (for one) is aware of the problem they cause when they accept email forwarded through you as an innocent bystander, because your mutual customer sends the forward and then reports it.

See aol.postmaster.com for information on how you can work with them. You can apply for whitelisting and set up a feedback loop.

(Our feedback loop for an entire class-c allocation only gives us three or four emails a day; we've been quite successful at educating our clients.)

So ... let your customers know that if they forward mail from their account on your server to AOL (and/or others) and then report it as spam, that you'll have to disable forwarding on their account.

That's what we do. It works.

Jeff
 
jlasman said:
So ... let your customers know that if they forward mail from their account on your server to AOL (and/or others) and then report it as spam, that you'll have to disable forwarding on their account.
Click to expand...

The customers in question have Barracuda servers filtering their e-mail, so the spam flagging is, for the most part, completely transparent to them. And then, with the Barracuda network, eventually all e-mails originating from my server will get blocked by any Barracuda server.

Because of this, it seems my only option really is to completely disable forwards. I have had this problem several times in the past with different clients, and each time I would determine that this was the source, and then disable their forwards. However, I had hoped to be able to somehow fix the problem at its source rather than remove functionality from my clients.
 
We've had the problem with Barracuda blocking us; they always release the block on request when we tell them the cause. It's a pain, but it works.

Of course you could write code to replace forwarding with rewriting, and information should be available on the SPF site.
Jeff
 
jlasman said:
We've had the problem with Barracuda blocking us; they always release the block on request when we tell them the cause. It's a pain, but it works.

Of course you could write code to replace forwarding with rewriting, and information should be available on the SPF site.
Jeff
Click to expand...

I've had to do the Barracuda request many times as well. The issue there is 1) annoying for me but more importantly 2) bad customer service/quality when my client's e-mails get blocked for "no reason".

It's mainly the frequency that it appears to be happening lately.

Maybe discussing this on the Exim mailing lists would be a better path for me.
 
Hi Jeff,

We are having this very same problem too. And for us this is a big security issue.

We do not want any non-authenticated activity going on in our server. How do I add this filter to exim.conf ??

Basically, and hopefully no one tries this now that I've publicized it, hehe, I can send an email from anywhere to my employee distribution list. I could easily send "Please cancel server XX " as if it was me sending it.

I need to cover this hole.

How can we do it ?

thanks ;)
 
The default install of exim and spamblocker do not allow any unauthenticated activity.

I can send an email from anywhere to my employee distribution list.
Click to expand...

There is only 2 ways this could happen:

1. You have already checked for email on the server via pop3 from your computer, therefore authenticated.

2. The domain of the distribution list is hosted on your server.

If number 2 is true then you should set up a filter to only allow you to send to the list.
 
Thanks Floyd,

Is there a file that contains my PC's (workgroup) ip ? Becuase we just picked any ole madeup name like [email protected] and sent to my personal email address. We also tried this on a server that I never accessed from our network, and worked. Default exim.conf

Now, perhaps I am not understanding what authenticated means. Does that mean, that for that session, I have authority to use SMTP ?? Or from that IP I can send via SMTP, forever , once authenticated ?

Thanks for helpin out :)
 
Just did it again:

*2009-05-25 23:50:22 1M8i3p-0000op-U8 <= bull****[email protected] H=120.red-83-52-247.dynamicip.rima-tde.net (PCNATALIA) [83.52.247.120] P=esmtp S=2640 id=016e01c9dd82$cf408990$6dc19cb0$@com T="just sending,. no pop first" from <bull****[email protected]> for [email protected]
2009-05-25 23:50:22 1M8i3p-0000op-U8 => prueba <[email protected]> F=<bull****[email protected]> R=virtual_user T=virtual_localdelivery S=2760
2009-05-25 23:50:22 1M8i3p-0000op-U8 Completed


I'll show you guys I can do it if you tell me any domain that is using default exim.conf

I'll send an email from [email protected] to [email protected] and I can put whatever subject,. and email content. I'll use outlook.
 
To send mail through your server:

1. You would either have to send the username and password while sending mail (smtp) or
2. send the username and password while checking for mail (pop3) or
3. your ip is statically listed in exim.conf (hostlist relay_hosts) or a file that exim.conf refers to (/etc/virtual/pophosts) or
4. you are sending to a domain listed in /etc/virtual/domains or
5. your From address matches whitelist_senders or whitelist_domains or whitelist_hosts.

They are the only ways I can think of now. I am sure Jeff will clarify.
 
Well,

Are you ready to get surprised ??

Give me any domain that uses the default exim.conf I will prove to you that I can send locally from whatever account I make up , to any existing account you tell me.

WITHOUT AUTHENTICATING

:D
 
Last edited:
You must log in or register to reply here.
Back
Top