Mailing List Archive

Feature LMTP daemon / unified delivery layer
Hi,

I've sent that mail a while ago but it never got to the list I think.

[ Aaron Stone ]
> For now, just getting the LMTP daemon, the unified delivery layer and
> the sort/ directories
[..]

Will the unified delivery layer be the right place to hand over mails to
spamassassin or amavis?

At the moment exim does that job for me, but I'd like to enable/disable
spam/virus scanning on a per user basis. All my aliases are resolved by
dbmail, so dbmail has to hand over the mails.

Are there any ideas for such an interface?


--
MfG Thomas Mueller - http://www.tmueller.com for pgp key (95702B3B)
Re: Feature LMTP daemon / unified delivery layer [ In reply to ]
This could very well be the place for a spam detector. However, SpamAssassin
works best at the MTA level and that's because it normally doesn't can the
spam for you; rather, it marks the subject with [spam] ala

"Subject: [SPAM] blah blah blah"

IMHO, the next thing to do is to write a Sieve script which moves all of the
messages with "spam" in their subject line into a spam folder or just drop
them altogether (though this is generally not recommended).

With respect to the sorting interface, because I'm a fan of statistical
Bayesian spam filters, I'd like to get one of those set up (and some of them
come in library form, too). The main problem is that most of them maintain
their own mbox or berkeley db database of spam to match against. That won't
work with dbmail, but we *do* have a "real" database right under our noses ;-)
So I've been looking into ways that we can build a corpus management
interface. Something that would give users a "mark as spam" button or a "Spam"
mailbox to move spam into / false positives out of.

Aaron


Thomas Mueller <dbmail@tmueller.com> said:

> Hi,
>
> I've sent that mail a while ago but it never got to the list I think.
>
> [ Aaron Stone ]
> > For now, just getting the LMTP daemon, the unified delivery layer and
> > the sort/ directories
> [..]
>
> Will the unified delivery layer be the right place to hand over mails to
> spamassassin or amavis?
>
> At the moment exim does that job for me, but I'd like to enable/disable
> spam/virus scanning on a per user basis. All my aliases are resolved by
> dbmail, so dbmail has to hand over the mails.
>
> Are there any ideas for such an interface?
>
>
> --
> MfG Thomas Mueller - http://www.tmueller.com for pgp key (95702B3B)
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

--
Re: Feature LMTP daemon / unified delivery layer [ In reply to ]
Hi Aaron,

> This could very well be the place for a spam detector. However, SpamAssassin
> works best at the MTA level and that's because it normally doesn't can the
> spam for you; rather, it marks the subject with [spam] ala
>
> "Subject: [SPAM] blah blah blah"

It changes the subject and/or modifies some headers (X-Spam-Status), yes.

I don't see a difference if the MTA or dbmail handles this?

MTA -> SpamAssassin -> MTA -> dbmail-smtp
MTA -> dbmail-smtp -> SpamAssassin -> dbmail-smtp

dbmail only needs the information if SpamAssassin got the mail yet:
MTA -> dbmail-smtp --send-to-sa -> SpamAssassin -> dbmail-smtp

If dbmail-smtp is called with --send-to-sa it can check if the user
wants the spamcheck. If not it can behave as if it was called without
--send-to-sa.

The MTA can't do that because the MTA doesn't know the final user.

Or did I miss something?

> IMHO, the next thing to do is to write a Sieve script which moves all of the
> messages with "spam" in their subject line into a spam folder or just drop
> them altogether (though this is generally not recommended).

Yes.

> With respect to the sorting interface, because I'm a fan of statistical
> Bayesian spam filters, I'd like to get one of those set up (and some of them
> come in library form, too). The main problem is that most of them maintain
> their own mbox or berkeley db database of spam to match against. That won't
> work with dbmail, but we *do* have a "real" database right under our noses ;-)
> So I've been looking into ways that we can build a corpus management
> interface. Something that would give users a "mark as spam" button or a "Spam"
> mailbox to move spam into / false positives out of.

SpamAssassin has a quite nice Bayesian spam filter integrated. Mails can
be piped to SpamAssassin:
cat the-mail |sa-learn --ham
cat the-mail |sa-learn --spam
To teach the Bayesian filter. Spam could be bounced to a special address
that pipes the mail to sa-learn then for example.
sa-learn keeps a database then and doesn't need access to mails in the
dbmail database.


--
MfG Thomas Mueller - http://www.tmueller.com for pgp key (95702B3B)