Thanks *very* much for taking the time to reply rob0 - it forced me to
re-examine my prior attempts...
On 2012-03-18 6:13 PM, /dev/rob0 <r...@gmx.co.uk> wrote:
On Sun, Mar 18, 2012 at 12:32:33PM -0400, Charles Marcus wrote:
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?
Ok... it does work that way. My mistake when I was testing this was
really stupid - hope you enjoy the coming laugh, I know I did ;)...
I tested this again, and was getting the same results, but I then
noticed something in the logs that I must have missed before:
Mar 19 07:20:31 myhost postfix/virtual[23325]: fatal: open dictionary:
expecting "type:name" form instead of "check_sender_access"
Mar 19 07:20:32 myhost postfix/master[10764]: warning: process
/usr/libexec/postfix/virtual pid 23325 exit status 1
Mar 19 07:20:32 myhost postfix/master[10764]: warning:
/usr/libexec/postfix/virtual: bad command startup -- throttling
Ok so, after the wtf moment, I looked more closely - and there it was,
staring me in the face...
smtpd_sender_restrictions =
<red-faced-dumbass>
was *commented*
</red-faced-dumbass>
Uncommenting and retesting indeed shows everything now works as it should.
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.
You are correct again - changed the DUNNO to OK after moving these
checks under smtpd_sender_restrictions and now they work as expected.
One question/confirmation though (reading
http://www.postfix.org/access.5.html does not seem to answer this, but I
may be missing that too) - does an OK here skip further checks in the
entire restriction class, or just for that one map check?
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.
That is precisely what they do, I can see it in the logs. When we were
using webroot, outbound messages were accepted immediately. Now, there
is a delay of many seconds, sometimes a lot (15,20,30 seconds) between
when the message is submitted to postini and when they accept it for
delivery.
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.
I agree, but the guy I ended up speaking with apparently isn't supposed
to be talking directly to us lowly customers... ;)
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.
Depends...
In theory I agree with you, but that is precisely how mumble_bcc maps
work, right? And lastly, the reality is, there are legitimate business
reasons, and sometimes *legal* reasons, for wanting to archive email.
Thankfully our laws do not require our business to archive *all* email,
but we do have certain cases where we want to do so for certain users,
and the use of mumble_bcc maps is the *only* answer I've ever seen here
on the postfix list as to how to use postfix to archive a users
in/outbound mail.
My understanding is that as long as we have good anti-spam measures in
place and enforce rate limits for outbound mail, we shouldn't have any
problem with being flagged as a spammer.
--
Best regards,
Charles
