SPAM - Sender Address = Receiver Address

[Infodine]

Hi,

I host several domains and I trust my handful of clients not
to send spam and it is important that ALL their internal
emails get through so I white listed their domains. This allows
them to send all attachments, etc to people in their domain.

So now I got a spammer using the same email address for
the sender and receiver. So of course they all get through
because the receiver is whitelisted.

Any ideas how I can achieve what I want and stop this
guy's emails from getting through? I was hoping I could
do a rule like, if sender's email address = receiver's address
then trash it. Is this possible?

Ex)
Joe@joe.com is the sender and receiver on all the spam
going to Joe.

Thanks for any ideas you may have.

Happy holidays,

Infodine

[martin]

It's possible to do using script, but I'm not sure if it's a good idea though. Often people send email to themself.

It's possible to write a script which checks that the SMTP authentication is used if the sender is local.

[dzekas]

Any ideas how I can achieve what I want and stop this
guy's emails from getting through?

Check SPF

[martin]

Also, is the white listed domains located on your server?

[Infodine]

Thanks for the quick reply. Yes they are on my server. I white listed them so that no emails between people at the domain would be scanned or have to be checked with spam services.

Maybe there is another approach?

[martin]

Since the users are local, SPF checks won't work (local users are trusted). The best thing I can think of is setting up a script which requires that your users authenticate when delivering email.

[dzekas]

Since the users are local, SPF checks won't work (local users are trusted). The best thing I can think of is setting up a script which requires that your users authenticate when delivering email.

Spammer should not be local. His IP address is not the same as legit email sender's address and SPF is designed to block such spams. If hmailserver's SPF implementation can't block them, because users are local, there is something wrong with your SPF implementation.

[martin]

Say I'm working for the company Example. The companys domain example.com has a SPF record saying that the address 1.2.3.4 is the only IP address allowed sending from this domain. I connect to example.com:25 from my home network where I use a dynamic IP address (which is currently 85.224.97.2) and attempt to send an email to billg@microsoft.com. How would SPF work in this case? I attempt to send an email from the address martin@example.com, but my own IP address won't match the one in the SPF record for example.com.

[dzekas]

Say I'm working for the company Example. The companys domain example.com has a SPF record saying that the address 1.2.3.4 is the only IP address allowed sending from this domain. I connect to example.com:25 from my home network where I use a dynamic IP address (which is currently 85.224.97.2) and attempt to send an email to billg@microsoft.com. How would SPF work in this case? I attempt to send an email from the address martin@example.com, but my own IP address won't match the one in the SPF record for example.com.

1 option: You get "relaying denied"
2 option: You use SMTP AUTH and turn off SPF tests after successful authentication.
3 option: You also host microsoft.com emails and instead of sending you "relaying denied", server checks your IP address against SPF records for example.com domain and refuses to accept your email or tags it as possible spam.

[mattg]

Am I over simplifying this, or won't just SMTP Authentication for the Internet IP range meet the OP requirements?

[mattg]

Say I'm working for the company Example. The companys domain example.com has a SPF record saying that the address 1.2.3.4 is the only IP address allowed sending from this domain. I connect to example.com:25 from my home network where I use a dynamic IP address (which is currently 85.224.97.2) and attempt to send an email to billg@microsoft.com. How would SPF work in this case? I attempt to send an email from the address martin@example.com, but my own IP address won't match the one in the SPF record for example.com.

1 option: You get "relaying denied"
2 option: You use SMTP AUTH and turn off SPF tests after successful authentication.
3 option: You also host microsoft.com emails and instead of sending you "relaying denied", server checks your IP address against SPF records for example.com domain and refuses to accept your email or tags it as possible spam.

Dzekas,

I have the greatest respect for everything that you say (your knowledge is astounding), but isn't Martin's example just a normal e-mail (not a relay) from a internet based local user to a remote account, the type of e-mail that is sent many thousands of times per hour through ISP mailservers.

Matt

[dzekas]

isn't Martin's example just a normal e-mail (not a relay) from a internet based local user to a remote account

If his server is not MX for microsoft.com, then he must pass relay tests. He is trying to send message to address that is not hosted on his example.com server.

[mattg]

Ah OK

What I was thinking of was your option 2.

All good, just my limited knowledge.

[martin]

In his case, both the sender and recipient is local in the sense that their address match an email account on the server. Since the message isn't going to be delivered to an external server (but instead to a local user), hMailServer 4 won't require SMTP auth.

This is why I recommended that he add a script which forces hMailServer to require SMTP auth for deliveries from local accounts, regardless of whether the recipient is local or not.

The first example here lets you do that:
http://www.hmailserver.com/documentatio ... eptmessage

[dzekas]

In his case, both the sender and recipient is local in the sense that their address match an email account on the server. Since the message isn't going to be delivered to an external server (but instead to a local user), hMailServer 4 won't require SMTP auth.

Yes, but when relaying is not allowed (no SMTP AUTH), SPF checks should be applied to sender. These checks should detect spammer sending @example.com emails from unauthorized IP address.

Original poster complains that spammer uses his address for sender. SPF is designed to counter such email abuse.

[martin]

> Yes, but when relaying is not allowed (no SMTP AUTH), SPF checks should be applied to sender.

But in his case we are not talking about relaying. In his case, the sender address is the same as the recipient address. The spammer is sending an email to a user on his server.

[dzekas]

> Yes, but when relaying is not allowed (no SMTP AUTH), SPF checks should be applied to sender.
But in his case we are not talking about relaying. In his case, the sender address is the same as the recipient address. The spammer is sending an email to a user on his server.

If hmailserver does not check it in SPF, then you do have problem with your SPF implementation. Standard unauthorized SMTP client is not checked in SPF, when email recipient is local. It does not matter that sender and recipient match. If SPF is used, sender address of unauthorized SMTP client must be checked.

[DFitch]

Yes, but when relaying is not allowed (no SMTP AUTH), SPF checks should be applied to sender. These checks should detect spammer sending @example.com emails from unauthorized IP address.

I have to agree with dzekas here. SPF should be applied if no SMTP Auth(even if local domain), since its easy to send using forged email addresses, just because it appears to local domain doesn't mean the IP is. If the IP is local then you have an internal problem and need to turn off that said account.

[martin]

Reading my previous posts I see that some of the info was simply wrong (sorry dzekas). My own confusion was caused by item 3 below.

In version 4, with SPF checks enabled:

• If a user is connecting from a remote computer, not using SMTP authentication, and is trying to send from a local address to the same local address, and this clients IP does not match the SPF records for the domain, his message will be rejected.
• If a user is connecting from a remote computer and is using SMTP authentication, he will be considered trusted and SPF checks won't be performed.
• If a user is connecting from localhost, SPF checks won't be performed.
• If a user is connecting from an IP address which is whitelisted, SPF checks won't be run.

Hence, one way to proceed could be to enable SPF checks and disable the whitelisting records. Then all users would have to enable SMTP auth.

Personally, if the number of domains are few, I would use the script which enforces SMTP auth instead and skip SPF. (The scripts behavior is added as a built-in option in v5.1)

[niente]

Hi all,
a simple solution I found, that partially solves the spam problem, is to whitelist my domain in local.cf

Code: Select all

whitelist_from *@mydomain.com

then, for every user, I added in their ~/.spamassassin/user_prefs a blacklist line:

Code: Select all

blacklist_from username@mydomain.com

In this way I have a score of -100 with the general rule and a +100 with the custom rule (the total score is zero), so spamassassin can evaluate if the message is spam or not and assigns it a meaningful score.

I'd prefer if it could directly trash it, maybe that if one creates a custom rule in local.cf that gives a score of -50 instead of -100 to *@mydomain.com (so using a rule in place of the whitelist), the following +100 could reach a high score that would cause the message to be dropped.

Bye