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

Reply via email to