I have a SpamAssasin rule for this that adds a score of 1.  You can make this number as high as you like.  Also, the rule only works if the TO and FROM are exactly the same, for example, if the FROM is "wendy@example.com" and the TO is "Wendy Smith <wendy@example.com" it will not match.  Though, this does mark a lot of the spam.  I didn't write this rule, I found it somewhere.

For RHEL & Centos

Add to :
/etc/mail/spamassassin/local.cf

#Email messages that are TO and FROM the same address
header __TOM_TO_EQ_FRa ALL =~ m/^From:\s+?<?(.+@.+)>?(\s|$)[^\0]*^To:.*\1/m
header __TOM_TO_EQ_FRb ALL =~ m/^To:\s+?<?(.+@.+)>?(\s|$)[^\0]*^From:.*\1/m
meta TOM_TO_EQ_FR __TOM_TO_EQ_FRa || __TOM_TO_EQ_FRb
score TOM_TO_EQ_FR 1
describe TOM_TO_EQ_FR To and From are the same, could be a cc or a forgery

Then restart amavisd
service amavisd restart

Most likely your spamassassin is getting a -10 score because your sending FROM a TRUSTED server.  So, it will not be flagged as spam unless you have your settings different then the default.  Two ways to test this, change the score to a huge number, say 25, or follow the directions below.

I made the following change to /etc/amavisd.conf

$sa_tag_level_deflt  = -9000;

This will add spamassassin header information to all emails, not just the ones that it thinks may be spam.  After you make this change, restart amavisd again.  Send yourself an email again, this time look at the all the headers.  You should see TOM_TO_EQ_FR mentioned in the spamaassasin area.

I don't think this is such a good idea, some of your users might actually want to send mail to themselves... I think the proper way to do this is to increase the score on SPF fail (and add SPF to your domain, that is...).

I'm not sure about that. Maybe because you can have the same domain on more than one mail server (multiple MXs)? For example, send mail from myself@domain, connected to mx1, and the mail will be delivered to mx2? Or at least this is what postfix will think, not being sure that it has direct local delivery enabled?

Zhang, when you are saying that "iRedMail has sender login check by default", are you talking about reject_unauth_destination? Or which rule?

LE:

I get it about this part.

Maybe I found the problem, at least in my configuration:

Shouldn't it also contain one of?:

?

Zhang, I don't think reject_unauth_destination does what we think.

According to the manual:

Unfortunately, we are in the second case, because it matches virtual_alias_domains/virtual_mailbox_domains.

So I guess we also need to add reject_sender_login_mismatch to smtpd_sender_restrictions.

Are any of you willing to test it? I can't for a day or two...

LE:

* Added the rule with warn_if_reject to test it for some time.
* I see that I get in the maillog:

So at least the relay rule is working (To and From are identical), but it doesn't protect entirely. I still don't get it why.

Hi,

Came across an article on spf. 

http://www.thetlog.net/2009/11/26/spf-p … ving-mail/

Thought it may solve this type of spam.

I added reject_sender_login_mismatch to smtpd_sender_restrictions. I don't know if this setting is already included in iRedMail, I might have accidentally deleted it.

smtpd_sender_restrictions = [...], reject_sender_login_mismatch

Unfortunately that article is using postfix-policyd-spf-perl. According to the OpenSPF software page, you are strongly recommended to use the python version, python-postfix-policyd-spf. I'm testing it for some time, but I'm still having some problems with it.