Stan Hoeppner a écrit : > mouss put forth on 12/16/2009 5:52 PM: > >> these are rdns warnings. the usual stuff. they are good for >> "information", because when you get other logs, you'll see "from >> unknown[a.b.c.d]", so if you want the PTR, you can consolidate the >> warning logs (I do this with a script because I want to see the PTR even >> if it doesn't match). > > Yeah, I know what they are. I'm just curious as to why I'm seeing so > many more of them. I guess it due to the reordering of the smtpd checks? >
No. maybe did you remove a firewall block? postfix does rdns check for all connections (unless you disable that) so you should see the warnings however you order your smtpd checks. >> Take a habit of sending the output of 'postconf -n'. >> - it will show you what postfix sees, instead of what you think. in >> particular, typos and "double defintions", ... >> - it's alphabetically ordered. this makes it easier for us to "parse" it >> (for example, I want o see relay_recipient_maps. with you message, I'm >> forced to check all the lines...). > > I posted main.cf instead of postconf -n because my changes are all about > order and location of smtpd_foo_restrictions checks. As you allude to > below, postconf -n reorders the output into alphabetical order. As I > understand it, the order of checks within smtpd_recipient_restrictions > is *critical* once you consolidate all smtpd_foo_restrictions here. If > I am incorrect here, I'll gladly provide postconf -n. > 'postconf -n' reoders _variables_, not values. and anyway, 'postconf -n' is what postfix uses, whatever you write in main.cf. so always use 'postconf -n' when troubleshooting or when posting to the list. the alphabetic order makes it easy for us to search for the variables we need to check (quickly finding problems/explanations). there's one caveat though. 'postconf -n' doesn't show non built-in variables, such as the value of the classes you defined under smtpd_restriction_classes. for these, you need to post them from main.cf (if applicable/needed). >>> [snip] >>> reject_unauth_pipelining >> this is useless. there is no "unauth pipelining" at RCPT TO stage. > > Noted. So, to use reject_unauth_pipelining, I'd still need an > smtpd_client_restrictions section containing this one option? Not all > things can be consolidated under smtpd_recipient_restrictions? > In the default (and recommended) config, client|helo|sender|recipient checks are all performed at RCPT TO stage, so reject_unauth_pipelining is useless in these checks. you can however put it under data restrictions. >>> # smtpd_sender_restrictions = >>> reject_non_fqdn_sender >> put this one before. it's cheap and there's no point checking maps and >> the like for mail that uses non fqdn addresses. smtp addresses must be >> fqdn. > > I have two spam trap addresses in my whitelist. I want all mail to > those addresses sent on through. If I move reject_non_fqdn_sender up > before the whitelist checks, I will potentially reject some spam > destined to the traps, no? yes. > In this case, is it better to leave this check where it is? yes. > >> you can consider this start: >> >> smtpd_recipient_retsrictions = >> reject_non_fqdn_sender >> reject_non_fqdn_recipient >> permit_mynetworks >> permit_sasl_authenticated >> reject_unauth_destination >> ... > > Is reject_non_fqdn_recipient cheaper than rejecting with > reject_unlisted_recipient? these are different. if you don't reject non fqdn recipients, you will get mail destined to <stan> (postfix will add @$myorigin). and sure reject_non_fqdn_* is cheap. it needs no map lookup. > With delayed evaluation, is this check > needed? Also, I don't use sasl authentication. > >> after this, you need to decide whether you accept some "misbehaviour" >> based on rcpt/client/sender or not. > > I'm not sure what you mean here. Can you elaborate? > I meant you can add check_*_access checks to whitelist some clients/recipients/... before putting reject_invalid_helo_hostname and other reject_* checks. but don't bother. it's what you are doing!
