Procmail Moving Mail from ORGMAIL to DEFAULT?
Procmail Moving Mail from ORGMAIL to DEFAULT?
am 06.04.2005 10:52:40 von ade
Hi all,
Apologies if this turns out to be blazingly simple and in some docs
somewhere, but I have looked and searched and not found anything yet so
here I am....
I have procmail setup as local delivery agent for sendmail. Users'
standard inboxes ($DEFAULT in procmail) are ~/Mail/inbox but user also
operate in a fairly tightly restricted disk quota environment.
Regularly, users will go over their allocated disk quota and, when
receiving mail, procmail will then drop their mail into the $ORGMAIL
location (as compiled into procmail) of /usr/mail/$LOGNAME. Accessing
mail in $ORGMAIL is the problem, once the user is back under quota. The
IMAP server only looks at ~/Mail/inbox. Is it possible to get procmail
to, when delivering a mail, try to move all the mail from $ORGMAIL to
$DEFAULT? I'm thinking when a user is back under quota then the next
mail they receive triggers all spooled mail in $ORGMAIL to get moved to
$DEFAULT as well as the new one itself.
I'm sure this must have been seen elsewhere so would appreciate any
recommendations or suggestions.
Thanks
Ade
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 01:46:59 von Alan Connor
On comp.mail.misc, in ,
"Ade" wrote:
> Hi all,
>
> Apologies if this turns out to be blazingly simple and in some
> docs somewhere, but I have looked and searched and not found
> anything yet so here I am....
>
> I have procmail setup as local delivery agent for sendmail.
> Users' standard inboxes ($DEFAULT in procmail) are ~/Mail/inbox
> but user also operate in a fairly tightly restricted disk quota
> environment. Regularly, users will go over their allocated
> disk quota and, when receiving mail, procmail will then drop
> their mail into the $ORGMAIL location (as compiled into
> procmail) of /usr/mail/$LOGNAME. Accessing mail in $ORGMAIL
> is the problem, once the user is back under quota. The IMAP
> server only looks at ~/Mail/inbox. Is it possible to get
> procmail to, when delivering a mail, try to move all the mail
> from $ORGMAIL to $DEFAULT? I'm thinking when a user is back
> under quota then the next mail they receive triggers all
> spooled mail in $ORGMAIL to get moved to $DEFAULT as well as
> the new one itself.
>
> I'm sure this must have been seen elsewhere so would appreciate
> any recommendations or suggestions.
>
> Thanks Ade
Hello Ade.
This is really interesting, but I don't know maildir very well,
and even though I have some ideas, thought I'd wait and see if
what others more experienced with maildir have to say.
Can't see any way to do this with just procmail. Look's like you
are going to have to have procmail call a script that will do the
job. Or use your MTA somehow, to resend the mail in $ORGMAIL.
You _could_ write a wrapper script for the user's MUA that
checked for over-quota mail in $ORGMAIL, notified them if
there was, and gave them the option to run their MUA with
$ORGMAIL as its $MAILDIR, giving them N hours to take of
the problem before it would be deleted.
Seems like inadequate spamfilters are probably the cause of
this problem, no?
AC
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 11:09:37 von ade
Alan Connor wrote:
>>I have procmail setup as local delivery agent for sendmail.
>>Users' standard inboxes ($DEFAULT in procmail) are ~/Mail/inbox
>>but user also operate in a fairly tightly restricted disk quota
>>environment. Regularly, users will go over their allocated
>>disk quota and, when receiving mail, procmail will then drop
>>their mail into the $ORGMAIL location (as compiled into
>>procmail) of /usr/mail/$LOGNAME. Accessing mail in $ORGMAIL
>>is the problem, once the user is back under quota. The IMAP
>>server only looks at ~/Mail/inbox. Is it possible to get
>>procmail to, when delivering a mail, try to move all the mail
>>from $ORGMAIL to $DEFAULT? I'm thinking when a user is back
>>under quota then the next mail they receive triggers all
>>spooled mail in $ORGMAIL to get moved to $DEFAULT as well as
>>the new one itself.
> This is really interesting, but I don't know maildir very well,
> and even though I have some ideas, thought I'd wait and see if
> what others more experienced with maildir have to say.
>
> Can't see any way to do this with just procmail. Look's like you
> are going to have to have procmail call a script that will do the
> job. Or use your MTA somehow, to resend the mail in $ORGMAIL.
>
> You _could_ write a wrapper script for the user's MUA that
> checked for over-quota mail in $ORGMAIL, notified them if
> there was, and gave them the option to run their MUA with
> $ORGMAIL as its $MAILDIR, giving them N hours to take of
> the problem before it would be deleted.
>
> Seems like inadequate spamfilters are probably the cause of
> this problem, no?
Hi Alan,
Thanks for your feedback, but i think i've somehow confused either
myself or you (or both). I'm not actually using maildir format inboxs,
but standard single-file style ones. Is that part of my confusion? Am
I confusing something for maildir style with single-file style?
Other than that, I could write a shell script to carry this out, it's
just I was hoping to find a sweet solution using procmail. And you're
right, a contributant to this problem is inadequate spamfiltering, which
is in turn caused by inadequate mail server hardware that can do no more
than asked of it already!
Thanks for you thoughts
Ade
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 11:43:10 von Alan Connor
On comp.mail.misc, in ,
"Ade" wrote:
> Alan Connor wrote:
>
>>>I have procmail setup as local delivery agent for sendmail.
>>>Users' standard inboxes ($DEFAULT in procmail) are
>>>~/Mail/inbox but user also operate in a fairly tightly
>>>restricted disk quota environment. Regularly, users will go
>>>over their allocated disk quota and, when receiving mail,
>>>procmail will then drop their mail into the $ORGMAIL location
>>>(as compiled into procmail) of /usr/mail/$LOGNAME. Accessing
>>>mail in $ORGMAIL is the problem, once the user is back under
>>>quota. The IMAP server only looks at ~/Mail/inbox. Is it
>>>possible to get procmail to, when delivering a mail, try to
>>>move all the mail from $ORGMAIL to $DEFAULT? I'm thinking
>>>when a user is back under quota then the next mail they
>>>receive triggers all spooled mail in $ORGMAIL to get moved to
>>>$DEFAULT as well as the new one itself.
>
>> This is really interesting, but I don't know maildir very
>> well, and even though I have some ideas, thought I'd wait and
>> see if what others more experienced with maildir have to say.
>>
>> Can't see any way to do this with just procmail. Look's like
>> you are going to have to have procmail call a script that will
>> do the job. Or use your MTA somehow, to resend the mail in
>> $ORGMAIL.
>>
>> You _could_ write a wrapper script for the user's MUA that
>> checked for over-quota mail in $ORGMAIL, notified them if
>> there was, and gave them the option to run their MUA with
>> $ORGMAIL as its $MAILDIR, giving them N hours to take of the
>> problem before it would be deleted.
>>
>> Seems like inadequate spamfilters are probably the cause of
>> this problem, no?
>
> Hi Alan,
>
> Thanks for your feedback, but i think i've somehow confused
> either myself or you (or both). I'm not actually using maildir
> format inboxs, but standard single-file style ones. Is that
> part of my confusion? Am I confusing something for maildir
> style with single-file style?
>
> Other than that, I could write a shell script to carry this
> out, it's just I was hoping to find a sweet solution using
> procmail. And you're right, a contributant to this problem is
> inadequate spamfiltering, which is in turn caused by inadequate
> mail server hardware that can do no more than asked of it
> already!
>
> Thanks for you thoughts Ade
I thought IMAP was exclusively maildir. Could be wrong. Never
used anything but POP.
Don't see how the current procmail session could do it. It's
already delivered, or is in the process of delivering, that mail
to $ORGMAIL.
And if you send any of the $ORGMAIL mboxes back through
procmail, any over-quota mail would be sent to $ORGMAIL again,
the very file you are reading from....
:-)
AC
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 11:46:04 von ade
> I thought IMAP was exclusively maildir. Could be wrong. Never
> used anything but POP.
>
> Don't see how the current procmail session could do it. It's
> already delivered, or is in the process of delivering, that mail
> to $ORGMAIL.
>
> And if you send any of the $ORGMAIL mboxes back through
> procmail, any over-quota mail would be sent to $ORGMAIL again,
> the very file you are reading from....
>
> :-)
>
> AC
>
Some IMAP servers are exclusively maildir based (I think Courier is
one), but it certainly works with mailbox style files (UW-IMAPD, Dovecot
being examples).
I think i'm gonna have to write a shell script to 'try' to move such
mail and call it from cron.
Thanks
Ade
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 12:41:52 von Alan Connor
On comp.mail.misc, in ,
"Ade" wrote:
>> I thought IMAP was exclusively maildir. Could be wrong. Never
>> used anything but POP.
>>
>> Don't see how the current procmail session could do it. It's
>> already delivered, or is in the process of delivering, that
>> mail to $ORGMAIL.
>>
>> And if you send any of the $ORGMAIL mboxes back through
>> procmail, any over-quota mail would be sent to $ORGMAIL again,
>> the very file you are reading from....
>>
>> :-)
>>
>> AC
>
>
> Some IMAP servers are exclusively maildir based (I think
> Courier is one), but it certainly works with mailbox style
> files (UW-IMAPD, Dovecot being examples).
Thanks.
>
> I think i'm gonna have to write a shell script to 'try' to move
> such mail and call it from cron.
>
> Thanks Ade
Tricky. You'll have to make sure the cronjob doesn't run while
procmail is, see how much diskspace is left on the IMAP server
for each user, peel that much off the top of the $ORGMAIL mbox
(oldest mails first) and append that to the $DEFAULT mboxes.
I'd append a note to each mail telling the user that it was
delayed, over-quota mail.
You'd also need a wrapper script for procmail, or your MTA, (or
something like that) to make it sleep for a bit if the cronjob
was running. Perhaps just turn them off
Then, if they don't check their mail before new mail is
delivered, that new mail would just go to $ORGMAIL!
So just slipping in a few at a time would probably be a
good idea...
I highly recommend using procmail to /dev/null any mail that
comes in that isn't specifically addressed to a user. Which
is to say that their address isn't alone on the To: line.
If they want to subscribe to any mailing lists, they'd have
to passlist them: Send the request to you to write into the
procmailrc(s).
That'll take care of a LOT of your spam.
Good luck,
AC
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 14:32:41 von Sam
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
--=_mimegpg-commodore.email-scan.com-26796-1112877160-0002
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Ade writes:
>> I thought IMAP was exclusively maildir. Could be wrong. Never
>> used anything but POP.
>>
>>
>
> Some IMAP servers are exclusively maildir based (I think Courier is
> one), but it certainly works with mailbox style files (UW-IMAPD, Dovecot
> being examples).
Congratulations, you've met Beavis, our resident kookbag. Occasionally he
sticks to taking his meds on time, and manages to eke out a single coherent
thought.
Don't worry, this won't last for long.
http://angel.1jh.com/nanae/kooks/alanconnor.shtml
--=_mimegpg-commodore.email-scan.com-26796-1112877160-0002
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCVShox9p3GYHlUOIRAoBAAJsHJNNWhQNBXcdaM3+TRdbdX8v21QCd EgM4
RzGISOD6IT8a3EnNpGRIBKI=
=GDVS
-----END PGP SIGNATURE-----
--=_mimegpg-commodore.email-scan.com-26796-1112877160-0002--
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 16:20:16 von James
On Thu, 07 Apr 2005 10:41:52 +0000, Alan Connor wrote:
> I highly recommend using procmail to /dev/null any mail that
> comes in that isn't specifically addressed to a user. Which
> is to say that their address isn't alone on the To: line.
I'm curious, why do you accept the mail and then pass it to /dev/null ?
Surely it would be better to reject such mails while the original SMTP
session is still active, both because it saves your bandwidth and also
because the sender, assuming it's not a spam mail, has a chance to see an
error and realise their mail wasn't delivered?
Re: Procmail Moving Mail from ORGMAIL to DEFAULT?
am 07.04.2005 16:44:57 von Sam
This is a MIME GnuPG-signed message. If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
--=_mimegpg-commodore.email-scan.com-26776-1112885096-0001
Content-Type: text/plain; format=flowed; charset="US-ASCII"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
James writes:
> On Thu, 07 Apr 2005 10:41:52 +0000, Beavis wrote:
>
>> I highly recommend using procmail to /dev/null any mail that
>> comes in that isn't specifically addressed to a user. Which
>> is to say that their address isn't alone on the To: line.
>
> I'm curious, why do you accept the mail and then pass it to /dev/null ?
>
> Surely it would be better to reject such mails while the original SMTP
> session is still active, both because it saves your bandwidth and also
> because the sender, assuming it's not a spam mail, has a chance to see an
> error and realise their mail wasn't delivered?
Because Beavis, after stripping all his bluster and kookery, is just some
pissant on an Earthlink modem dialup.
He likes to present himself as a sooper mail expert, but the only time he
actually managed a production mail server is in his wet dream.
--=_mimegpg-commodore.email-scan.com-26776-1112885096-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCVUdox9p3GYHlUOIRAvohAJ0f74SXdUgM268gRks5gX66K/HrkgCe JcfW
roJF2yUnQBuqv7TPzCtuYkI=
=/N6e
-----END PGP SIGNATURE-----
--=_mimegpg-commodore.email-scan.com-26776-1112885096-0001--