This question comes up enough so that it ought to be in the FAQ.

spamass-milter as others have said does not pay attention to
authenticated mail.   Other milters do - but other milters are
often a lot more complicated, and can run slower, to say nothing
of having to learn additional configuration steps and possibly
load additional dependent libraries on the server for the milters.

There is something to be said for the UNIX philosophy of "small
is beautiful"  You may love your MIMEdefang but why do I have to
run it when this problem is so easily fixed?

The reason spamass-milter doesn't do this was documented
http://lists.nongnu.org/archive/html/spamass-milt-list/2004-03/msg00014.html

spamass-milter doesen't pass a complete Received line to Spamassassin so there is no way to exempt authenticated mail from spam scanning unless you do it in spamass-milter itself. The patch here does that:

mail# diff -u spamass-milter.cpp.original spamass-milter.cpp
--- spamass-milter.cpp.original 2009-01-15 14:43:32.000000000 -0800
+++ spamass-milter.cpp  2009-01-15 14:45:05.000000000 -0800
@@ -776,6 +776,12 @@
   struct context *sctx = (struct context *)smfi_getpriv(ctx);
   char *queueid;

+ if (smfi_getsymval (ctx, "{auth_type}") != NULL)
+         {
+                 return SMFIS_ACCEPT;
+         }
+
+
   if (sctx == NULL)
   {
     debug(D_ALWAYS, "smfi_getpriv failed!");
mail#

Make sure you pass the -a flag to the milter or this patch is not activated

ALSO NOTE:

This spamass-milter patch is already present in a number of UNIX
distributions.  For example in the FreeBSD ports system it is
a flag that is selected during the spamassassin build.  I believe I've
seen it mentioned in a Debian distro as well.

Ted

On 10/4/2011 2:52 PM, Kris Deugau wrote:
Frank Leonhardt wrote:
I think there's a terminology mis-match here. To me "milter" is a
sendmail mail filter, of which there can be any number configured (this
is me making no assumptions about Postfix &c). In this case it's just
spamass-milter (Georg C. F. Greve 2002)

Nope, you've got the terminology straight.

MIMEDefang is another (much more flexible) milter - which can call a
great many other things to do its processing including SpamAssassin.
IIRC amavis can be deployed as a milter. ClamAV ships one very similar
to spamass-milter, in that it's dedicated to passing messages to ClamAV.
There are several dedicated to SPF and DKIM.

And any of them can be used with Postfix >= 2.3 (although IIRC some
functions may not work well with Postfix 2.3).

IIRC, spamass-milter isn't particularly configurable; it's either
installed and passing all mail to SA, or not.

Other milters *do* have a lot more flexibility in deciding what to do
with any given message - for instance, since the "configuration" is a
Perl script fragment, anything you can do to a stream of bytes or a file
in Perl can be done by MIMEDefang. It uses SA a little differently (by
default) in that it loads the SA Perl libraries, rather than passing a
message to spamd.

I recently migrated outbound filtering at work to MIMEDefang from a
homebrew Postfix content filter. We have four or five intersecting sets
of conditions that decide whether or not a given message will be
scanned, and if so what threshold to reject the message at. The
conditions are currently set by the presence and content of a collection
of flatfiles, but we're planning on moving that data into a database
sometime.

- nothing to do with MIMEDefang
and suchlike.

Well, not exactly. sendmail <-> [some milter] <-> spamd (or the Perl SA
libraries)

[some milter] is spamass-milter in your case. I briefly tried a number
of milters before settling on MIMEDefang for flexibility in implementing
the full range of capabilities in the milter interface.

It's a daemon - hangs around on a socket and waits for
sendmail to give it an email.

And it's up to the milter to decide what to do with that message.
spamass-milter, IIRC, doesn't have many knobs to twist in this respect;
it passes everything to SA.

It then calls spamc and sends the modified
message back to sendmail. It didn't occur to me that it'd be called
indirectly by one of the other general purpose milters, but I can see
that now.

IIRC there *is* a milter-multiplexor milter that calls other milters,
but I'm not sure what the real use-case is.

 > Fortunately for me it's written in 'C', so I've got a reasonable
 > chance of understanding it. I'm trawling through the source now.

That's certainly an option. I'm not sure how active spamass-milter
development is, and whether they'd accept a patch for a "bypass on SMTP
AUTH" configuration switch - if not, you'll be carrying a custom patch.

-kgd

Reply via email to