I had similar problems just now, after moving my "ispcp powered" server to my home from another location that had a static ip. I use my server for my own webs, not actual clients, so I had not real urgency to fix it. But it was annoying not to get mail from my office emails. myoffice emails are running on a shared hosting at a large company.
According to the OR
".... In the later case, the problem is that the sender's ISP is badly configured. "
I did not believe it, since that host is among the top ten of hosting services on the net, according to their CEO blog. And I really do not get many bouncers from other destinations and I send a lot of mail to many clients and random support inquirers. So the bouncing back from my "ispcp powered" server were kind of abnormal.
Anyway, when I disabled policyd_weight, I was able to send mail to my home, from the office. No errors.
So there is the question on my mind regarding OR's :
"... simply policyd-weight doing its job ..."
I wanted to figure out how it works, or if there is anything else I can do.
So I compared some of the weight check logs to think it over. I found 3 mails in a row. 2 that came through to my domain and one that was bouncing back, sent from my office at the big hosting company server.
Well, the long story (short) looks like below. (edited for brevity and to protect identities).
Arrived mail 1.
Code:
/var/log/socklog/mail/@400000004fa5f48c0abedcb4.s:7233:mail.info:
May 5 23:15:04 postfix/policyd-weight[28613]:
CL_IP_EQ_FROM_MX=-3.1 < --- This like looks like the kicker.
<client=###.16.98.133>
<helo=mail.zmailer.org> < --- Nice email testing tool if you need it!
<from=postmaster@mail.zmailer.org>
<to=meetjesus@mydomain>;
rate: -1.125 < --- I think this number determines bouncing or not.
Arrived mail 2.
Code:
/var/log/socklog/mail/@400000004fa5f48c0abedcb4.s:7241:mail.info:
May 5 23:15:32 postfix/policyd-weight[28613]:
weighted check:
CL_IP_EQ_FROM_MX=-3.1; < --- same level reported .
<client=###.132.180.67>
<helo=vger.genericl.org>
<from=postmaster@vger.genericl.org>
<to=meetjesus@mydomain>;
rate: -3.35 < --- pretty low score.
Look closely at this one which bounced back to the sender.
Code:
/var/log/socklog/mail/@400000004fa5f48c0abedcb4.s:7249:mail.info:
May 5 23:17:25 postfix/policyd-weight[5283]:
weighted check:
CL_IP_EQ_HELO_IP=-2 < --- It is higher. Maybe caused extra checks?
(check from: .mycompany.
- helo: .oproxy5-pub.bighost.
- helo-domain: .bighost.)
FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.062
CLIENT_NOT_MX/A_FROM_DOMAIN=5.75
CLIENT/24_NOT_MX/A_FROM_DOMAIN=5.75;
<client=###.222.38.55>
<helo=oproxy5-pub.bighost.com>
<from=myofficemail@mycompany.com>
<to=meetjesus@mydomain>;
rate: 11.312 < --- wow! this is high by comparison.
This last mail, that was bouncing back to my office, has a pretty high score. I don't think the mail was configured wrong at the hosting service.
Rather, my guess is, they have so many accounts on their servers, that there is a much higher chance some client on their systems are getting flagged as spammers, which increases the chance of the mail servers getting high scores in my little server.
So, it might be better for me to use the white list idea, than to use the cancel policyd_weight idea. Or, I might look into setting the policyd_weight bounce levels in order to allow a little bit higher rejection level.
I just thought I would post this as a "my two cents" .
Some other notes.
From `man policyd-weight.conf`
CL_IP_EQ_HELO_IP
Client IP matches the A record of the HELO argument.
@helo_from_mx_eq_ip_score (1.5, -3.1)
Define scores for the match of Client IP against MX records. Positive (SPAM) values are used in case the MAIL FROM matches not the HELO argument AND the client seems to be dynamic AND the client is no MX for HELO and MAIL FROM arguments. The total DNSBL score is added to its bad score.
Log Entries:
CL_IP_EQ_FROM_MX - Client IP matches the MAIL FROM domain/host MX record
CL_IP_EQ_HELO_MX - Client IP matches the HELO domain/host MX record
CLIENT_NOT_MX/A_FROM_DOMAIN - Client is not a verified HELO and doesn't match A/MX records of MAIL FROM argument
CLIENT/24_NOT_MX/A_FROM_DOMAIN - Client's subnet does not match A/MX records of the MAIL FROM argument
Search
Member List
Calendar
Help
/
Mail appeared to be SPAM or forged
Mail appeared to be SPAM or forged 
