Blocking un-authorized local SPAM

[inferencia]

Thanks Jeff,

I was already doing that, per Floyd's suggestion But thanks in any case.

 

[nobaloney]

Have you gotten a response yet?

Anything helpful?

Jeff

 

[handrea]

Hi,
I've got the same problem. Please if anyone found a solution and/or received an answer from the exim group, please post here .
I understand, it breaks RFC but, from our prospective, is really usefull and logic constraint.
I think mail system must evolve and fix some holes was not considerated ad "design time" where system was not spread and SPAM not existing . Of course this is my personal opinion..

Regards
Andrea

 

[Percy]

Hi,
I've got the same problem. Please if anyone found a solution and/or received an answer from the exim group, please post here .
I understand, it breaks RFC but, from our prospective, is really usefull and logic constraint.
I think mail system must evolve and fix some holes was not considerated ad "design time" where system was not spread and SPAM not existing . Of course this is my personal opinion..

Regards
Andrea

Andrea, I completely agree. I think the core of the current systems used for e-mail was designed so long ago that it cannot fully appreciate what e-mail has become.

Although I cannot conceive of a perfect system, there are definitely some things that I believe that could be done to greatly improve e-mail as a whole and limit SPAM and other such issues. But, people in general are afraid of change so I do not how/if this will ever happen.

 

[floyd]

I still don't even understand the problem really.

 

[Percy]

I still don't even understand the problem really.

In my opinion, if you are sending e-mail to yourself (To == From), then you should be sending through your own mail server. Based on this assumption, therefore, any e-mails where To == From and the originating server is not your own server should be blocked, as it should be assumed to be spam.

I do not see how these assumptions are not correct. I can understand that these assumptions might not follow RFC, but that is different. As previously stated, I think the RFC needs to be updated/revisited to reflect the current usage.

I cannot think of a situation where the assumptions above would prevent me from sending/receiving a legitimate e-mail.

 

[floyd]

any e-mails where To == From and the originating server is not your own server should be blocked, as it should be assumed to be spam.

What is preventing you from doing that?

 

[Percy]

What is preventing you from doing that?

My knowledge of exim.conf...

Nothing, technically. This discussion is so old that I forgot that we already concluded the best path was to talk to Exim experts. However, I believe I have tried that path with no success.

 

[floyd]

You can block all To = From email in the filter.

One of the points raised was security and I believe that is making email do something it was not intended to do.

 

[nobaloney]

In my opinion, if you are sending e-mail to yourself (To == From), then you should be sending through your own mail server.

Unless of course you're a user at a remote location (Internet cafe while on vacation, for example) and they won't let you use your own server, and you're cc-ing yourself so when you get home you'll have a copy of the email in your main mailbox.

Or as another example, if you use your return address on a reseller system set up at enom/dotster/resellerclub/directi, etc., which uses your email return address.

Or as another example, if you've got multiple DirectAdmin servers, and you use the same return address for system emails from all of them.

These are common enough in a shared server environment that implementing what you suggest would create a nightmare.

I can't see implementing what you suggest on any shared server. And as long as you're using an exim.conf file written by me, you're stuck with what I implement.

DirectAdmin staff and I have seen eye to eye on shared-server systems administration for some time, and so far, they've used my exim.conf file. There's no reason why someone else (even you) can't write one. If you can convince DirectAdmin to install yours by default, it will do what you want, and you'd have severely broken intended email functionality; many of your clients will have problems receiving email; perhaps you as well.

I won't, because I'll continue to use my configuration.



I really do think about what I implement, and I've been using email for a long time; in fact since long before the Internet went public.

Jeff

 

[Percy]

Unless of course you're a user at a remote location (Internet cafe while on vacation, for example) and they won't let you use your own server, and you're cc-ing yourself so when you get home you'll have a copy of the email in your main mailbox.

Or as another example, if you use your return address on a reseller system set up at enom/dotster/resellerclub/directi, etc., which uses your email return address.

Or as another example, if you've got multiple DirectAdmin servers, and you use the same return address for system emails from all of them.

1) Lots of places block port 25, but I've yet to use a hotspot that blocks port 587, which is what I use anyway. This is why I've said that only authenticated To/From local mail should be accepted.

2) Not quite sure what you mean by this, but if it is what I take it to be, then perhaps the reseller system should not send e-mail on your behalf, or it should be SPF'd?

3) This would seem like something that could be easily fixed with a whitelist of sorts. Being in a multi-server environment, I'm sure there's already been some configuration changes to facilitate that specific environment. This could just be one more change.

 

[floyd]

2) Not quite sure what you mean by this, but if it is what I take it to be, then perhaps the reseller system should not send e-mail on your behalf, or it should be SPF'd?

The idea of a reseller system is that the end customer believes that it is you selling the server/product. If the reseller system cannot send email in your behalf then it cannot send email at all and still be a reseller system. That means that if it were a domain registrar and you did not want them sending email reminders to your customers to renew their domain then you would be responsible for tracking all their domains and then sending the email reminders to them. Is that what you really want?

 

[Percy]

The idea of a reseller system is that the end customer believes that it is you selling the server/product. If the reseller system cannot send email in your behalf then it cannot send email at all and still be a reseller system. That means that if it were a domain registrar and you did not want them sending email reminders to your customers to renew their domain then you would be responsible for tracking all their domains and then sending the email reminders to them. Is that what you really want?

Right, that is what I understood. So something like an SPF would take care of that, wouldn't it?

 

[floyd]

I am not sure if SPF would fix it or not but I do know that even if did if the reseller program switched to a different ip without telling you then you would be in trouble and it may be a long time before you figure out there is a problem.

 

[handrea]

I still don't even understand the problem really.

Hi Floyd,
the problem is really simple: avoid tons of everyday SPAM . This is what happens:
considering the domain example.com, I'm John with [email protected].
I receive every day a lot of spam messages from [email protected] sent to [email protected]. I'm surprised that these emails are not considered spam because I see that the source is not my server mail.example.com (ip: 100.100.100.100) but a Korean server (ip: 283.125.157.75).
This is possibile because Spam system is not filtering my self. So? What to do? Do I want to filter myself? No! Or better:

• I want to be able to send email to myself (for example, a simple stupid "remember the milk email"..)
• I want to be able to send an email including my address in CC or BCC.
• I want to block others telling they are me (John) just to sell me their viagra

Is this really impossibile? My answer is NO (comments are welcome). Let me explain why (from my point of view).

• If I'm on mail server (webmail running on, a PHP script, an application, etc.) I should be able to send email locally without authentication. Why? Because sender = mail.example.com = the authorized mail server (MX). So in this context sending email from [email protected] should not require authentication.
  
• If I'm outside of mail server (outlook client, application on remote server different from mail.example.com)I should be able to send email from [email protected] only using smtp authentication.
• Even considering a PHP script, application, webmail application running outside of mailserver, this should send email from [email protected] only using smtp authentication: all relevant commercial / opensource web application support authenticated smtp delivery (not only calling mail() )
• Nobody else should be able to send email from [email protected].

I think that this logic is valid for the initial assumptions. Infact I can:

• Send email to myself (remember the milk!) by webmail because is running locally on Mail server or because webmail application is using smtp authentication.
• Send an email including myself in CC or BCC because, if I'm sending it by Outlook I'm using smtp authentication, If I'm on webmail we're in previous case, if I'm sending it from [email protected] should not be a problem including me in CC / BCC.
• The viagra-man contacting my mail server has no possibility to send me his wonderfull products.

Conclusions (please read )
So what I mean is this. I explained my idea (and I think is the same of Percy). I don't mean is RFC compliant, I don't want to sell my exim.conf to DirectAdmin , I don't pretend this should be the default behaviour.
I just want to outline this problem in order to:

• Collect your comments and understand, If I'm wrong, where I'm mistaking and, eventually, how can I save myself from the Viagra man?
• In addition to comments, because of your technical experience, even if your mail server will NOT adopt this logic, can you please tell us what (and, possibly, how ..) change Exim configuration, filters, etc. in order to implement this logic?

Really thank you for support and for reading this long post. Regards
Andrea

 

[Percy]

I am not sure if SPF would fix it or not but I do know that even if did if the reseller program switched to a different ip without telling you then you would be in trouble and it may be a long time before you figure out there is a problem.

If this is your understanding of SPF, then I question your knowledge of it. SPF can use several different methods to specify allowed/legitimate senders, not limited to just a list of IP addresses. The more likely path to use in this situation would be to use an mx: or a: setting, which provides a server/DNS name rather than an IP. Therefore, the reseller would simply update their DNSs and the SPF would continue to work without any interruption.

In my mind this is a relatively simple administrative task if the end product is moving towards a SPAM-free environment (or at least less SPAM anyway).

 

[floyd]

Since I do not feel like reading a novel at this point I will just comment on this one thing:

I receive every day a lot of spam messages from [email protected] sent to [email protected]. I'm surprised that these emails are not considered spam because I see that the source is not my server mail.example.com (ip: 100.100.100.100) but a Korean server (ip: 283.125.157.75).

So you are saying that it should be considered spam just because an email with your address in the From header it did not originate on your server? That logic in itself is ludicrous. It has already been explained why such a thing might happen and be desired.

 

[floyd]

If this is your understanding of SPF, then I question your knowledge of it.

I beat you to it in my last post. I already stated "I am not sure."

SPF can use several different methods to specify allowed/legitimate senders, not limited to just a list of IP addresses.

DirectAdmin uses the ip address and why I commented like I did.

 

[Percy]

Since I do not feel like reading a novel at this point I will just comment on this one thing:



So you are saying that it should be considered spam just because an email with your address in the From header it did not originate on your server? That logic in itself is ludicrous. It has already been explained why such a thing might happen and be desired.

And yet in the 3 situations you gave as examples, I was able to come up with a better/alternative solution to prevent this from happening.

To me it seems ludicrous that an e-mail server should be expected to accept an e-mail from an outside server if it is being sent from an unauthorized source. Again, in the 3 examples you gave, none of them were not fixable by a solution that I proposed (unless I have been mistaken in those solutions, but I believe I am correct).

It seems so obvious to me and others that this portion of the RFC has created a loophole that spammers are obviously well aware of and gladly take advantage of it. And yet the only argument you have come up with to counter it is that one might have to change the way things work. Ultimately it seems as though you either fear change or are unwilling to even test/theorize possible solutions. It seems that you are happier to simply live with SPAM and e-mail the way it is without trying to make any improvements to it.

Myself and others feel that there are better ways to block SPAM, and that the RFC is outdated and should be updated to present a more modern approach at blocking SPAM.

So I ask, why are you so hesitant to attempt to improve a SPAM blocking system and e-mail in general? I can completely understand that if you are running a multi-server environment with hundreds of customers that you do not want to make a change that will potentially block many legitimate e-mail messages. I can completely understand that DA would not want to update their default exim.conf if it does the same thing across hundreds or thousands of servers across the globe. However, I doubt that many of our great hardware and software started today with someone saying "Well, this might cause some problems with A and B." Those people addressed those problems/concerns, came up with solutions for them, tested them, and the finished result was a better product for everyone.

I think Andrea and I are both simply saying that we do not in ourselves possess the knowledge to change our exim.conf file to make the suggested changes. Nor do we expect others to blindly make said changes, were they ever made. But in our usage, I think both Andrea and I would say that the potential disadvantages of making such a change are nothing in comparison to the advantages.

So ultimately my question comes down to this:

Is someone here able to assist Andrea and I (and possibly others) in changing our exim.conf settings in order to test such a configuration?

 

[Percy]

PS: floyd, I really don't want to be coming across as harsh or rude, but your statements imply that mine and Andrea's "expectations" are ludicrous, when I really do not think they are. I hope you are able to understand where we are coming form and see why it might not be as difficult as you seem to think it would be, to make such a change.