On 27 October 2011 12:07, /dev/rob0 <r...@gmx.co.uk> wrote: > On Thursday 27 October 2011 10:32:54 Simon Brereton wrote: >> I know this gets beaten to death on a regular basis, but sometimes > > Indeed it does, such as ... today! Read the "Config check" thread.
It's tricky enough understanding my config, let alone someone else's but it did raise some of the questions I had and I didn't want to piggy back.. > I wouldn't trust Spamcop for outright rejection, but it is useful in > postscreen(8) scoring. I've never had a false-positive. If anything it's not useful enough (considering it's supposed to add IPs on a real-time basis). >> This stuff builds up over time and I find I can't always remember >> the rational for putting things in the order I put them. One >> point of concern that I have is that when I added in the >> policy-spf the warnings were clear that it needs to go after >> reject_unauth_destination otherwise it turns the box into an open >> relay. The same logic should apply to the policyd service, yes? > > As well as to anything which might return permit or OK. See the other > thread, and the link posted therein. > >> But yet there it is above reject_unauth_destination and the online >> but http://www.checkor.com/ and >> http://verify.abuse.net/cgi-bin/relaytest says I'm not an open >> relay, so I'm confused. > > You probably are open for certain relay attempts. An online checker > cannot test for all possible combinations of sender, EHLO, et c. Cheers. I'll fix that. >> Looking over the list though, I propose: >> >> ## SPAM STUFF and REJECT CODES ## >> smtpd_recipient_restrictions = reject_non_fqdn_sender, >> reject_non_fqdn_recipient, >> reject_sender_login_mismatch, >> # shouldn't this be before permit_sasl? > > Yes, if you're using that. Also a good idea to put user submission on > a separate smtpd(8) service. Submission port is open but not all clients can use it, so we remain open on 25 for SASL authentication. That may change in the future. Whilst rereading postconf.5 I found: reject_authenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for authenticated clients only. This feature is available in Postfix version 2.1 and later. reject_unauthenticated_sender_login_mismatch Enforces the reject_sender_login_mismatch restriction for authenticated clients only. This feature is available in Postfix version 2.1 and later. Should I add those in here (or only on the submission port)? I don't really understand their usage. Surely if sender login is mismatched, that's not authenticated? So my understanding (clearly wrong) is that reject_unauthenticated_sender_login_mismatch = reject_sender_login_mismatch and reject_authenticated_sender_login_mismatch can't happen because a mismatch wouldn't authenticate the sender! What have I missed? >> I'd be grateful for comments/suggestions. Are there newer/better >> RBLs I should be using? > > Quality of DNSBL is more important than quality. I have posted my > postscreen rules which are doing a very good job. I'd recommend that > you look that up and consider upgrading if you are pre-2.8. > > Also, the Barracuda BRBL is a very nice service, almost on par with > Zen in terms of effectiveness, and has seemed very safe here. 2.8 is waiting for a debian port :) My understanding is that once 2.8 is installed I don't need the policyd (at least not for grey-listing, but it might be useful for other things. At that stage I'll probably upgrade it to 2.0 anyway and see what new features it has. Haven't seen Cami on here in a while though.. I appreciate the advice and patience. Simon
