On 2012-03-17 10:20 AM, /dev/rob0 <r...@gmx.co.uk> wrote:
On Sat, Mar 17, 2012 at 08:58:16AM -0400, Charles Marcus wrote:
smtpd_recipient_restrictions =
# these two maps only have REJECTs, no OKs allowed
check_recipient_access ${hash}/moved-employees,
check_recipient_access ${hash}/x-employees,
Fine until someone slips up and puts an OK in there. Why wouldn't
this work elsewhere, e.g., smtpd_sender_restrictions? I think it
would.
Thus my last question about moving them... ;)
I would *love* to be able to figure out how to get these to work the way
I want outside of smtpd_recipient_restrictions, but I haven't been able
to. I need this check to happen *before* the check for a valid
recipient, because I have custom reject messages for these - the first
check informs the sender of a new email address, and the second that the
recipient is no longer employed there. When I moved these to
smtpd_sender_restrictions, they were ignored - all I got was the
standard 'User unknown in virtual mailbox table' error.
permit_sasl_authenticated,
# this map only has PERMIT_AUTH_DESTINATIONs for a few ancient client
# devices that don't support SMTP_AUTH, and a final OK for localhost
# (127.0.0.1) at the end
check_client_access ${cidr}/allowed_clients_local.cidr,
Fundamentally the same as permit_mynetworks, which you have later.
# this map is to prevent messages from/to one of our domains but has
# some DUNNOs for a few exceptions, and a final REJECT, no OKs allowed
check_sender_access ${hash}/nospoof,
Again, fine until the slip-up occurs.
I know... but I understand the danger and the comments at the top of
these files and in my documentation/manual are VERY clear, so if I get
hit by a truck tomorrow and someone comes along behind me and makes this
mistake, it will be their own fault.
I'm not sure how the DUNNO results are supposed to act.
The purpose of the map was/is specified... I can specify certain
addresses (ie, ad...@example.com) that will skip this restriction - ie,
will be allowed to send from an outside system spoofing the from address
of one we host, but still be subject to all subsequent checks - while
rejecting all other spoof attempts.
# this map only has REJECTs to block external access to internal only
# mail list addresses
check_recipient_access ${hash}/blocked_recipients,
# this map only has PERMIT for postini's network and a final REJECT
# telling other clients to use our MX
check_client_access ${cidr}/allowed_clients_external.cidr,
Why can't Postini work with permit_auth_destination?
They will - unless you also want to use them for outbound relay... :(
I'd certainly not trust them to relay, ahem. :)
I agree, and was extremely unhappy about this when I found out about it
- and I had to escalate this issue to one of their senior engineers to
get a straight answer. He was very irritated that I was able to get to
him when I was supposed to be going through my third party sales/support
provider, but my rep couldn't answer my question as to *why* I had to
add postini's network to mynetworks thereby giving them blanket relay
capability through my system. The answer is because they do not queue
the messages, so must be able to reinject messages bound for the
internet back into my queue in the event of a softfail.
permit_mynetworks,
reject_unauth_destination,
(And why can't the allowed_clients_external.cidr check go here?)
Because for reasons already specified, I must add postini's network to
mynetworks, and I need this check to come before the check for postini's
network. Sucks, I know, and in order to get a straight answer I had to
escalate this issue to one of their senior engineers who seemed very
irritated that I was able to get to him when I was supposed to be going
through my third part sales/support provider (but they couldn't answer
my questions as to *why* I had to add postini's network to mynetworks
thereby giving them blanket relay capability through my system, and I am
bullheaded when it comes to stuff like this and I *hate* answers like
'because I said so').
Incidentally, for the above, and one other reason, I think I'm going to
be able to convince my client to either not use them for relay, or to
switch to another provider altogether, maybe AppRiver...
That other reason is, while they require the customer to trust them
completely when using them for outbound relay, they refuse to return the
favor, which completely breaks sender_bcc maps (and .forwards) that
relay mail to an external domain - they require the envelope sender to
be one of ours...
On that OT note - anyone have any outsourced anti-spam providers they
like? Feel free to send me a private note...
And if I did this, would I then have to change smtpd_delay_reject
to no?
Definitely not. That's rarely a good idea. In fact I am having
trouble imagining where it might be a good idea. I did it before,
implementing a greet pause, and it caused pain.
Ok, I just thought maybe that was why it didn't work when I tried to add
those custom recipient checks into smtpd_sender_restrictions.
--
Best regards,
Charles
