Well, you detest my "at the top" style quoting, I detest your "pick it apart" sentence by sentence style quoting, so I will go back to my style, refer to my quote _if_ you need your memory refreshed ;)
On Tue, 21 Jun 2005 17:10:31 +0200, Jan Pieter Cornet wrote > No, I know for a fact that you are confused. filter_relay, filter_sender > and filter_recipient are run independent on the `delay_checks' > feature in sendmail.mc. ...snip... > See, I actually _tried_ this, because I had a sneaking suspicion of being > flamed on this list if I got it wrong. So I setup several ways to block > a message, both from MIMEDefang and from access.db, and tried that with > and without FEATURE(`delay_checks'). And it worked exactly like I > said before: > > Without delay_checks, both MIMEDefang and sendmail ruleset invoked tests > (like access.db) react immediately. > > WITH delay_checks, tests like access.db delay until after RCPT To:, but > MIMEDefang checks still react immediately. > ...snip... > delay_checks feature (which is not a "sendmail flag", by the way). Looking at the recipients.c in the sendmail 8.13.4 source and at: http://www.milter.org/milter_api/overview.html Sure makes it look like it breaks out during each callback to a milter then back, at which a milter may reject or tempfail or modify the recipients list at any point. Now I may not be reading it correctly or interpreting it correctly but it sure looks like it to me (and makes more sense to me as well). Due to your "pasion" about this subject I will not respond to the list on this anymore, feel free to continue this via private email if you wish though. You confirmed my "test" which also seems to corroborate it though I must admit, I only checked the scenario I described (which is the one that mattered to my implementation), so you say filter_sender ran before filter_relay when delay_checks is enabled in your testing? even though sendmail would check the recipient first and relays afterwards? according to the sendmail docs: delay_checks- The rulesets check_mail and check_relay will not be called when a client connects or issues a MAIL command, respectively. Instead, those rulesets will be called by the check_rcpt ruleset; they will be skipped under certain circumstances. Certain circumstances basically means a trusted auth mechanism or a spamfriend/hater setup in most cases. It is possible my test is skewed since my users do authenticate and I do check for that in MD, thus might have skipped the other checks regardless? And technically, the delay_checks setting in the mc file IS a flag... a flag is just something set to activate or deactive a feature in the programming sense... if I stepped on some sendmail specific nomenclature by calling it that.. then I apologize.. but for all intents and purposes, everyone here understood what I was referring to. Jim -- EsisNet.com Webmail Client _______________________________________________ Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
