Hi group,

Lately I have been fooling around with setting up a mailserver using
Slackware of course. I am now at the point where I want to enforce
quota's.

Slackwares default LTA procmail complies just fine with quota. Only
problem is it temp fails.... and sendmail ques the mail for a next try.
I would like it to temp fail on a soft limit exceed and bounce on a hard
limit exceed.
But this behaviour can not be modified with switches.

I've allready discussed this at a sendmail group. The suggestion there
was:

- patch procmail to let it signal noavail
- make sendmail bounce temp fails
- use mail(er).local

I've tried to find a patch for procmail on this subject. Actually found
one concerning quota's, but that had to do with spooling on a NFS
filesystem.
Patching it my self is not an option. I've just spend the better part of
the morning trying to figure out the code (I have a pacal background
which does not really help a lot with C sources )

Changing sendmails behaviour on temp fails seems riskfull to say the
least. Other temp fail - than quota exceeded - would bounce as wel. So
this is not a real option I think.

Leaves me with using mail.local..... this one seems to have switches by
which you can controll what it does on a quota exceeded.

But that brings up yet another problem.... In my current setup I've got
spammassassin working via /etc/procmailrc, so I would have to come up
with another scheme for spamassassin to work (milter? allready have it
for clamav).

So finally my question(s), and I fully realize that the final anwser (on
the first at least) should come from PJV.....
- why does Slackware default to procmail?
- what else can I expect to happen when I switch to mail.local?
- are there other LTAs I can consider using?


regards,

Peter
--
If two wrongs don't make a right, try three.
-- Laurence J. Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bilbo <bilbono@spamnedlinux.nl> wrote:

> But that brings up yet another problem.... In my current setup I've got
> spammassassin working via /etc/procmailrc, so I would have to come up
> with another scheme for spamassassin to work (milter? allready have it
> for clamav).
>

I'm not clear on exactly what you want, but then I just woke up. Is
this what you're looking for?

http://www.worlddesign.com/index.cfm/rd/mta/spampd.htm

- --
George Georgakis geegATtripleg_net_au http://www.tripleg.net.au/
SlackBuild Central - http://slackpack.tripleg.net.au/

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBQG6nBElp3nJf7PixEQKHLACcD0g/qELep0ItIFZEqv4nuoZjSqoAn0Yl
9udDLrCqjL6FrxZgA3hjMo+e
=3O0l
-----END PGP SIGNATURE-----

pgp trash troll delete

Guy Macon

George Georgakis <geeg@tripleg.go.away.spammers.net.au> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Bilbo <bilbono@spamnedlinux.nl> wrote:

> > But that brings up yet another problem.... In my current setup I've got
> > spammassassin working via /etc/procmailrc, so I would have to come up
> > with another scheme for spamassassin to work (milter? allready have it
> > for clamav).
> >

> I'm not clear on exactly what you want, but then I just woke up. Is
> this what you're looking for?

> http://www.worlddesign.com/index.cfm/rd/mta/spampd.htm

> - --
> George Georgakis geegATtripleg_net_au http://www.tripleg.net.au/
> SlackBuild Central - http://slackpack.tripleg.net.au/

> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

> iQA/AwUBQG6nBElp3nJf7PixEQKHLACcD0g/qELep0ItIFZEqv4nuoZjSqoAn0Yl
> 9udDLrCqjL6FrxZgA3hjMo+e
> =3O0l
> -----END PGP SIGNATURE-----

On 2004-04-03, George Georgakis <geeg@tripleg.GO.AWAY.SPAMMERS.net.au> wrote:
> I'm not clear on exactly what you want, but then I just woke up. Is
> this what you're looking for?
>
> http://www.worlddesign.com/index.cfm/rd/mta/spampd.htm


No... that is not it.
What I wanted to do was to not use procmail at all and leave spam
filtering to to spamd and sendmail with the help of a milter wrapper
around spamd. There is a project around to do that.

But after that I found another way to do the job.

I seems I mixed up the reasons for procmail and sendmail to temp fail. I
thought that if I would let procmail exit with a no avail it would
somehow keep sendmail from temp failing when it has i.e. a DNS timeout.

But off course procmails exit code has nothing to do with the action
sendmail takes when it would normally temp fail.

So what I do now is let procmail exit with no avail in case it would
normally temp fail..... in effect this bounces mail when a users quota
is execeeded. This can be done by deleting one of the procmail switches
in /usr/share/sendmail/cf/cf/sendmail_slackware.mc

Am I making any sense? Sure hope so


Thanks anyway, allready gave up on this topic

Peter

--
A jury consists of 12 persons chosen to decide
who has the better lawyer.
-- Robert Frost