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

Reply via email to