On Mon, Mar 19, 2012 at 09:20:13AM -0400, Charles Marcus wrote: > 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 ;)...
Heh, no worries, these things happen. You made me question my assumption and RTFM, so that was a good thing too. > 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" And that is from virtual(8), not smtpd. Oh, I get it, leading whitespace put your check_sender_access under some virtual_* parameter. Funny. :) > 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? "OK" is one of many possible final results. When that is reached for any lookup, the stage ends. > >>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. Fine (FSVO fine), but I still don't see why they'd reinject back to you. They keep you on the line during their outbound attempt. If that attempt fails, they report that to your smtp(8), and YOU keep it in your queue. If it's a softfail, same thing, they report that to you. > >>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... ;) And I begin to suspect that this "senior engineer" does not know what he is doing! :) > >>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? I would keep those within my control. I bet you do, too. Using an external address as always_bcc or mumble_bcc_maps recipient seems wrong to me. There's no danger doing same-envelope forwarding within your realm of control. > 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. It's very difficult to be 100% certain that you're not forwarding spam, but yes, you can put the odds in your favor. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
