spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Mittelstaedt <>
Subject Re: How do I stop SA checking mail from authenticated users
Date Tue, 04 Oct 2011 22:10:20 GMT
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

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!");

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


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.


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

View raw message