On Wed, 13 Jan 2010, John Hardin wrote: > On Thu, 14 Jan 2010, Jean-Yves Avenard wrote: > > > Mail system is made of > > Sendmail as MTA -> spamass-milter -> spamd > > > > Legitimate users are using the sendmail server over TLS and first need > > to authenticate themselves before being able to post. > > > > Is there a way to have a particular score if the sender has > > succesfully authenticated ? > > > > Like if the sender was authenticated then score is -10.0 etc > > Take a look at the Received header that your MTA inserts for an > authenticated session. It will look something like this: > > Received: from [192.168.1.86] ([xxx.202.179.87]) > (authenticated bits=0) > by mail.impsec.org (8.13.7/8.13.7) with ESMTP id n7OIlctS024743 > (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) > for <jhar...@impsec.org>; Mon, 24 Aug 2009 11:47:42 -0700 > > The "by mail.impsec.org" would be _your_ MTA. > > Such a rule might be: (warning, untested!) > > header AUTH_SMTP Received =~ /\(authenticated bits=\d+\) by > mail\.impsec\.org / > score AUTH_SMTP -10.0 > > ...substituting _your_ MTA name, of course.
One risk to this rule, a savvy spammer could forge a "Received" header to mimic that information to gain your white-list score (now that it's been publicized on this list they know ;). To prevent forgeries from getting that free ride, test against the special Received pseudo-headers, either "X-Spam-Relays-Internal" or "X-Spam-Relays-Trusted" You might want to experiment to see what works best. A caveat, as you're using sendmail with a milter, be aware that the milter taps into the mail stream -before- the local sendmail "Received" header is added. Therefore the milter has to synthesize the "Received" header itself (to mimic what sendmail will create). Make sure that your milter will correctly add that "(authenticated bits=" stuff itself. some early versions didn't do this correctly. (this is assuming that the users are connecting/authenticating to the sendmail instance that you're running your milter on. If they're going to an upstream instance then this won't be an issue). -- Dave Funk University of Iowa <dbfunk (at) engineering.uiowa.edu> College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527 #include <std_disclaimer.h> Better is not better, 'standard' is better. B{