On Sun, Mar 18, 2012 at 12:32:33PM -0400, Charles Marcus wrote:
> 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.
My assumption was that smtpd_sender_restrictions would evaluate
before smtpd_recipient_restrictions, because MAIL FROM in SMTP
precedes RCPT TO. SMTPD_ACCESS_README.html#timing (the second
paragraph there) supports this assumption.
Why isn't it working like that? Can you show logs where this is not
working as documented?
> >> 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.
And we'll miss you. :) And we'll tell your successor that you told
them so. :)
> >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 -
The DUNNO inside a map only skips that map. In most cases it's the
same as if the sender address was not listed in that map at all.
> 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.
This explanation is not working for me. If they didn't queue it, what
DID they do? Seems to me like not queueing it would mean that they
keep your smtp(8) client on hold while their client attempts to
deliver to remote sites. That sounds terribly inefficient to me.
> >> 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
Um, excuse me, YOU are the paying customer who asked a reasonable
question.
> 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').
And they have no right to give such an answer, certainly not if they
expect you to pay them and use the service.
> 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...
I don't blame them, there. I preach against same-envelope forwarding
every chance I get. It's no longer a reasonable practice.
> On that OT note - anyone have any outsourced anti-spam providers
> they like? Feel free to send me a private note...
I've only found ones I don't like. I can do it myself, probably as
well as they do, but not as cheaply for a small business. And they
have the bells and whistles set up already, which I do not.
> >>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.
Not as it seems to me: your smtpd_sender_restrictions REJECT result
should have prevented evauluation of smtpd_recipient_restrictions.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
