On Sat, Mar 17, 2012 at 08:58:16AM -0400, Charles Marcus wrote:
> After modifying my config to work the way I want it to after the
> switch from webroot to postini,
I have a "funny" Postini story to tell. Recently I made inquiry
about features of the service, and in the web form I carefully and
deliberately unchecked the "spam me" boxes. I wanted my question
answered ONLY.
The question was partially (not fully) answered, and of course, I
continue to get marketing mail on the tagged address I used. A
spammer running an anti-spam service, how nice.
> I'd like a sanity check on my modified restrictions to make sure
> I didn't make some glaring mistake that is going to bite me
> (full postconf -n at the end of this message)...
>
> Here are my current restrictions (with comments to explain the
> purpose and contents of the maps, all still under
> smtpd_recipient_restrictions):
>
> 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.
> 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'm not sure how the DUNNO
results are supposed to act.
> # 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? I'd certainly
not trust them to relay, ahem. :)
> permit_mynetworks,
> reject_unauth_destination,
(And why can't the allowed_clients_external.cidr check go here?)
> # this map only has DISCARDs or REJECTs
> check_sender_access ${hash}/blocked_senders,
>
> My main question is, would it make more sense to move all of the
> check_mumble restrictions that come *before*
> reject_unauth_destination into their appropriate
> smtpd_mumble_restrictions class?
I don't see why they wouldn't work somewhere else, such as
smtpd_sender_restrictions. And you'd only need one such class, not
separate stages for each of these.
> 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.
In effect with smtpd_delay_reject=yes, there is no difference among
smtpd_mumble_restrictions for "client", "helo", and "sender" values
of "mumble". Pick one other stage and offload the chance for
disasterous errors thereto.
> myhost : Fri Mar 16, 12:41:11 : ~
> # postconf -n
snip
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
