Blocking un-authorized local SPAM

*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

Is vipxenon.com listed in /etc/virtual/domains on the server you are using to send mail?

Code:
grep 83.52.247.120 /var/log/maillog

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

I'll send an email from [email protected] to [email protected] and I can put whatever subject,. and email content. I'll use outlook.

I am not sure what that will prove.
 
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

Then you should be able to use my mail server to do it. Feel free to try. If you try to send mail through mail server newwebsite.com then of course its going to accept mail for newwebsite.com.
 
Is vipxenon.com listed in /etc/virtual/domains on the server you are using to send mail?

Yes,. I understand this is permissable from your last post. But it shouldn't be, becuase , "Who the hell am I to send any email to any account without authenticating?"

That's a security hole.

Maybe not for others, but for us it certainly is. How can I cover this hole ?
 
Email sent to sales at your domain:

----------------------
Hi Floyd,

Customer no longer wants this server. Please shut it down and cancel the account.

Thanks

Hacker
---------------------

Now tell me that doesn't feel a little unconfortable ?
 
So the issue is that somebody can use your server directly to send mail to any domain on that server?

How is that a security issue? Whether they use your server or another server you will still get the email.
 
Yeah,

That's one issue. But the main issue, assuming you got my hacker email, is that I just faked being your support department asking your sales departmento to cancel a new customers server.

Now maybe this is ok with you,. but the hell if it's ok with me.

So, is there a rule / filter I can apply to exim.conf to make sure ALL activity is authenticated ?
 
Email sent to sales at your domain:


Now tell me that doesn't feel a little unconfortable ?

You used your server mail.cyberneticos.com to send me email. Big deal.

Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Mon, 25 May 2009 18:23:09 -0400
Received: from mail.cyberneticos.com ([212.34.158.65] helo=cyberneticos.com)
by server.newwebsite.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.67)
(envelope-from <[email protected]>)
id 1M8iZZ-00084F-1d
for [email protected]; Mon, 25 May 2009 18:23:09 -0400
Received: from 120.red-83-52-247.dynamicip.rima-tde.net ([83.52.247.120] helo=PCNATALIA)
by cyberneticos.cyberneticos.com with esmtpa (Exim 4.69)
(envelope-from <[email protected]>)
id 1M8iWT-0005ya-Gf
for [email protected]; Tue, 26 May 2009 00:19:57 +0200

I must be totally missing the point. Maybe somebody else can explain in a different way. Hopefully if somebody else gets involved one of us will understand.

I just faked being your support department

Really. I got an email from [email protected] asking to cancel a server.

But I think I might be starting to understand the logic. A spammer (or whatever) can claim to be from your support or billing or whatever and cause people to perhaps do something they shouldn't (like cancel a server). And because they used your server to send the email it looks legit.
 
Algunos de los destinatarios no recibieron su mensaje.

Asunto: Please cancel my server
Enviado el: 26/05/2009 0:44

No se puede localizar a los destinatarios siguientes:

'[email protected]' en 26/05/2009 0:44
503 Valid RCPT command must precede DATA

OK,. this time got bounced.

Got any other test domain on a different server ? Perhaps I'm block on this one ?
 
But I think I might be starting to understand the logic. A spammer (or whatever) can claim to be from your support or billing or whatever and cause people to perhaps do something they shouldn't (like cancel a server). And because they used your server to send the email it looks legit.

Yes. Exactly.
 
And that's putting just a little bit of imagination to the problem. I can probably come up with some very interesting things to do , knowing this is possible.

:mad:
 
OK,. this time got bounced.

Got any other test domain on a different server ? Perhaps I'm block on this one ?

[root@server ~]# exigrep "83.52.247.120" /var/log/exim/mainlog
2009-05-25 18:43:45 H=120.red-83-52-247.dynamicip.rima-tde.net (PCNATALIA) [83.52.247.120] F=<[email protected]> rejected RCPT <[email protected]>: Email blocked. 83.52.247.120 is in SORBS - to unblock send this email to your isp

2009-05-25 18:43:52 H=120.red-83-52-247.dynamicip.rima-tde.net (PCNATALIA) [83.52.247.120] incomplete transaction (QUIT) from <[email protected]>

All my servers use SORBS
 
My IP must just have got blacklisted, doing a test on some servers.

We use SORBS too (we have RBL check activated)

but ,. if the IP is not blacklisted,. SORBS ain't gonna do you any good.
 
"Hi guys, my email changed. Please email to : [email protected] (not domain)"

"Will, I?m at home and can't access webmail, can you send me our main VPS root password to [email protected] ?? Thanks"

"Hi guys, this new server we got in today, the customer asked to change his email to [email protected]"

These are just quick things I can come up with to hack the hell outta someone.

With a little bit of planning,. a lot of damage could be done.
 
I know this has been discussed previously. Maybe even in this thread; I'm not taking the time to reread.

So let's discuss it one more time:

1) Anyone can send email to any account on your server. Anyone. If you don't want people to be able to send email to your server, then turn off the exim daemon, since it's main purpose is to allow people to send email to your server.

2) Anyone can use any outgoing email address in any email. That's simply the way email was designed.

3) Authentication only refers to relaying.

4) relaying means sending from your server to another server.

5) When I send an email to an address on your server that's not relaying.

6) The above is true no matter what address I use as the "From:" address on my email.

7) Which is all as it should be.

8) If you want to keep email from an address hosted on your server from being sent the same address or another address on your server, then you're going to have to write that code yourself, because (a) RFCs don't forbid it, and (b) many of us, including me, want it.

If you don't understand one of the things I wrote above, please refer to it by number. If you disagree with one of the things I wrote above, please refer to it by number.

If you don't like any of the things above, either turn off your email server, or rewrite the code. It's NOT a hole in exim or in DirectAdmin; it's the way email is designed to work.

For better or for worse.

Jeff
 
No problem Jeff. I did understand everything you wrote. And yes, it has already been discussed. Pehaps you missed the part where I describe how it could be a security issue.

Now, is there any way I can configure exim.conf to force authentication for those sending within the server (domains in /etc/virtual)

??

That's all I really need. If it's RFC, FCC, BGD or WKY compliant,. I don't really care. I just don't want people sending emails without authenticating. In our setup, it's a security issue, and just asking for help.

Thanks.
 
"Hi guys, my email changed. Please email to : [email protected] (not domain)"

"Will, I?m at home and can't access webmail, can you send me our main VPS root password to [email protected] ?? Thanks"

"Hi guys, this new server we got in today, the customer asked to change his email to [email protected]"

These are just quick things I can come up with to hack the hell outta someone.

With a little bit of planning,. a lot of damage could be done.

If you or your company would really do these things above based on an email then you already have a security problem and its not email security. Things like this need to be verified with perhaps a phone call or secret question type of thing. You should have codes for internal use. I am too paranoid to trust email to take actions such as outlined above.

I think this brings me to the end of this discussion (I hope). You see the security problem as the way email functions. I see the security problem as the people who take action based on those emails.
 
Great Floyd:)

Can anyone tell my how to force authentication in this scenerio so no one can send emails from internal accounts to other internal accounts without authenticating ?

Thanks.
 
Can anyone tell my how to force authentication in this scenerio so no one can send emails from internal accounts to other internal accounts without authenticating ?

Posts #13 and #14. Ask the exim list since they know more about it than anyone here.
 
Now, is there any way I can configure exim.conf to force authentication for those sending within the server (domains in /etc/virtual)
There probably is.
I've never taken the time to learn it, because it's not something I'd do, either for myself, or for a shared hosting server. In my opinion it simply breaks email.

Why? Look again at what you wrote:
domains in /etc/virtual
Is that really how you're going to decide who's within the server? That's got nothing to do with who's sending within the server; there are lots of good reasons (as previously discussed) why you might not be using your own server to send mail, and therefore may not be authenticated.

But I agree with others; hopefully this can be our last post to this thread.

Go ask on the exim-users mailing list, and see if they disagree with me and others who've posted here :D.

Jeff
 
Back
Top