On Sat, Dec 05, 2009 at 05:34:03AM -0600, Stan Hoeppner wrote: > You'll likely have to go for the fruit at the top of the tree to > get the right answer. I've been on the top branch all day and > can't figure it out, thus my email to the list.
Climb down from the tree. Your answer was among the fallen fruit laying on the ground. Everyone in this thread but you seems to understand what happened. This is a classic example of why it's generally better to keep your restrictions in ONE STAGE unless you have a good reason not to, and of course, a good understanding of how multiple restriction stages wok (independently of one another: the simple fact that was lying beneath the tree, rotting.) ANY rejection in ANY stage means the mail is rejected. Doesn't matter how many whitelists you check in other stages. You forgot it in one that mattered. When whitelisting in smtpd_recipient_restrictions, be careful with how it's done. Use "permit_auth_destination" rather than "OK" unless you really did intend to allow relaying. The same thing can be done with whitelisting restrictions after reject_unauth_destination. Also give heed to mouss' advice about splitting up the access maps by type of lookup. No point in listing IP addresses in a sender or HELO lookup map. No point in listing email addresses in a client lookup map. Domain names can be in any, but are you sure you want to do the same thing for any of client, helo, sender and recipient lookups? This post might seem like a gratuitous me-too, and it partly is, but the thing that concerned me, as one of the people responsible for the Spam-L list, was the rejection, in the original post: > Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT > from unknown[204.238.179.8]: 450 4.7.1 <mx1.mfn.org>: Helo command > rejected: Host not found; from=<spam-l-boun...@spam-l.com> > to=<s...@hardwarefreak.com> proto=ESMTP helo=<mx1.mfn.org> Unknown? Here's what I get: 8.179.238.204.in-addr.arpa. 3600 IN PTR mx1.mfn.org. mx1.mfn.org. 14400 IN A 204.238.179.8 That looks like perfect FCrDNS to me. So another issue you ought to look at: why is your resolver failing on this? Is it consistent? -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header