Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter. The first thing we thought of was to make all users use procmail, and set up a global procmail rule with a sleep in it, while this will almost certainly work, the users must not be able to run commands on the server, which they can do with a ~/.procmailrc file. I have tried to set up a postfix filter which would delay the mail (similar to this: http://pintant.cat/2010/04/14/how-to-delay-the-mails-postfix/) but that has an issue where it will only allow 5 of these filters to be running at a time, so if I where to send 10 messages with a 5 minute delay, the first 5 will take 5 minutes and the next 5 will take 10 minutes. I can change this limit within postfix but I would prefer to use a method that is more scalable. Anyone got any ideas? -- Mike Fabre
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective.
The first thing we thought of was to make all users use procmail, and set up a global procmail rule with a sleep in it, while this will almost certainly work, the users must not be able to run commands on the server, which they can do with a ~/.procmailrc file.
You could add your rules to /etc/procmailrc, however, and ensure that all mail is delivered from there.
On Tue, Mar 13, 2012 at 03:22:06PM +1100, Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective.
I also use postgrey for greylisting, however we need *all* mail to be delayed whether it is recognized or not, I also don't want to delay it the half hour or so which greylisting will normally do, just a short delay of a few minutes is fine.
The first thing we thought of was to make all users use procmail, and set up a global procmail rule with a sleep in it, while this will almost certainly work, the users must not be able to run commands on the server, which they can do with a ~/.procmailrc file.
You could add your rules to /etc/procmailrc, however, and ensure that all mail is delivered from there.
As far as I can tell from procmail's manpage I can't tell it *not* to read the users .procmailrc when it's finished with everything else, if I'm wrong here then that's probably the easiest way to go about it. -- Mike Fabre
Mike Fabre <mike+luv@fabre.id.au> wrote:
As far as I can tell from procmail's manpage I can't tell it *not* to read the users .procmailrc when it's finished with everything else, if I'm wrong here then that's probably the easiest way to go about it.
I might be wrong, but my understanding is that if the last recipe in /etc/procmailrc delivers all mail not handled by proceding recipes, then it won't matter what is in the user's ~/.procmailrc file, because /etc/procmailrc is executed first, and processing ends once the message has been handled by a delivering recipe.
Looking at the procmail(1) manual page: "If no rcfiles are specified, it looks for $HOME/.procmailrc." I haven't tested this, but it appears from the above that if you specify a file on the procmail command line, it will use that instead of ~/.procmailrc - and you can specify command line arguments for Procmail in your Postfix configuration.
On Tue, Mar 13, 2012 at 03:45:30PM +1100, Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
As far as I can tell from procmail's manpage I can't tell it *not* to read the users .procmailrc when it's finished with everything else, if I'm wrong here then that's probably the easiest way to go about it.
I might be wrong, but my understanding is that if the last recipe in /etc/procmailrc delivers all mail not handled by proceding recipes, then it won't matter what is in the user's ~/.procmailrc file, because /etc/procmailrc is executed first, and processing ends once the message has been handled by a delivering recipe.
Ah, that makes sense, I shall test this some more. -- Mike Fabre
On Tue, Mar 13, 2012 at 03:53:19PM +1100, Mike Fabre wrote:
On Tue, Mar 13, 2012@03:45:30PM +1100, Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
As far as I can tell from procmail's manpage I can't tell it *not* to read the users .procmailrc when it's finished with everything else, if I'm wrong here then that's probably the easiest way to go about it.
I might be wrong, but my understanding is that if the last recipe in /etc/procmailrc delivers all mail not handled by proceding recipes, then it won't matter what is in the user's ~/.procmailrc file, because /etc/procmailrc is executed first, and processing ends once the message has been handled by a delivering recipe.
Ah, that makes sense, I shall test this some more.
Follow-up: having tested this further I have found that it doesn't work, postfix is only allowing 2 copies of procmail per recipient to run at a time so if I put 'sleep 5m' into the procmailrc then each user can only receive 2 message every 5 minutes. I can probably change the arbitrary limit of 2 procmail processes, but that's likely to introduce other problems such as too many procmail instances eating up memory. -- Mike Fabre
Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective.
Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u".
Trent W. Buck <trentbuck@gmail.com> wrote:
Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u". _______________________________________________
That should be an effective strategy. I've never heard of mail as a substitute for IRC, XMPP, StatusNet and their proprietary counterparts, which are actually designed for this application.
Jason White wrote:
Trent W. Buck <trentbuck@gmail.com> wrote:
Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u". _______________________________________________
That should be an effective strategy. I've never heard of mail as a substitute for IRC, XMPP, StatusNet and their proprietary counterparts, which are actually designed for this application.
Ah, well, the users are not allowed IM either :-)
On 14/03/12 12:09, Trent W. Buck wrote:
Jason White wrote:
Trent W. Buck <trentbuck@gmail.com> wrote:
Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u". _______________________________________________ That should be an effective strategy. I've never heard of mail as a substitute for IRC, XMPP, StatusNet and their proprietary counterparts, which are actually designed for this application. Ah, well, the users are not allowed IM either :-)
luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
Thats what happens when restrictions are placed on how technology can be used!! People find ways around. Perhaps a better strategy would be to allow IM? Cheers Daniel. -- ---------------------------------------- Daniel Jitnah Melbourne, Australia e: djitnah@greenwareit.com.au w: www.greenwareit.com.au SIP: dj-git@ekiga.net ---------------------------------------- ** For All your Linux, Open Source and IT requirements visit: www.greenwareit.com.au ** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. For All your Open Source and IT requirements see: www.greenwareit.com.au
Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective.
Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u".
Sigh. Users. Our jobs would be a lot easier without them. Under Exim I would set up dual spool directories, so incoming email gets dumped in Q1, but only Q2 is processed for delivery automatically. A cron job would run every few minutes and move spool files older than 5 minutes from Q1 to Q2. Maybe you can do something similar with postfix? I don't think the greylist solution is the right one. You still want your server to receive the email... forcing a retry could introduce a much larger delay than you want. Have you considered charging the users department for excessive emails? ;) James
On 14/03/12 12:32, James Harper wrote:
Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter. Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective. Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u". Sigh. Users. Our jobs would be a lot easier without them.
Under Exim I would set up dual spool directories, so incoming email gets dumped in Q1, but only Q2 is processed for delivery automatically. A cron job would run every few minutes and move spool files older than 5 minutes from Q1 to Q2. Maybe you can do something similar with postfix?
I don't think the greylist solution is the right one. You still want your server to receive the email... forcing a retry could introduce a much larger delay than you want.
Have you considered charging the users department for excessive emails? ;)
What if you do really have a legitimate need to have an email sent as quickly as possible? What happens then? (For example: you are talking to someone on the phone and want a feedback on a doc while on the phone, you could legitimately want to send the doc to the person as quickly as possible). I think its a case of barking the wrong tree here. Cheers, Daniel
James
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- ---------------------------------------- Daniel Jitnah Melbourne, Australia e: djitnah@greenwareit.com.au w: www.greenwareit.com.au SIP: dj-git@ekiga.net ---------------------------------------- ** For All your Linux, Open Source and IT requirements visit: www.greenwareit.com.au ** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. For All your Open Source and IT requirements see: www.greenwareit.com.au
On 14/03/12 12:32, James Harper wrote:
Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter. Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective. Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u". Sigh. Users. Our jobs would be a lot easier without them.
Under Exim I would set up dual spool directories, so incoming email gets dumped in Q1, but only Q2 is processed for delivery automatically. A cron job would run every few minutes and move spool files older than 5 minutes from Q1 to Q2. Maybe you can do something similar with postfix?
I don't think the greylist solution is the right one. You still want your server to receive the email... forcing a retry could introduce a much larger delay than you want.
Have you considered charging the users department for excessive emails? ;)
What if you do really have a legitimate need to have an email sent as quickly as possible? What happens then? (For example: you are talking to someone on the phone and want a feedback on a doc while on the phone, you could legitimately want to send the doc to the person as quickly as possible). I think its a case of barking the wrong tree here.
I seldom point out the fallacy of a technical workaround to a social problem these days. I assume the OP has already thought this thing through and has already had this argument with the person who gave the instruction. The whole thing sounds like a megalomaniac manager trying to run an office like a battery hen egg farm, which never works unless your employees enjoy being treated like crap. Unless it's a school or university of course, and the users in question are students, which was my original assumption. Then you should indeed try and make their lives as difficult as possible! <evil grin> James
Quoting James Harper (james.harper@bendigoit.com.au):
I seldom point out the fallacy of a technical workaround to a social problem these days.
http://linuxmafia.com/~rick/lexicon.html#edwards Edwards's Law "You cannot apply a technological solution to a sociological problem." Nobody seems to know who Edwards was, but pretty much the entire system administrator profession rests on the implicit assumption that he/she was egregiously mistaken. This plausible-sounding but empty-headed dictum is most often referred to as "Edwards' [sic] Law" -- by the depressingly huge mass of semi-literates unable to correctly write possessives of singular nouns ending in "s".
Quoting James Harper (james.harper@bendigoit.com.au):
I seldom point out the fallacy of a technical workaround to a social problem these days.
http://linuxmafia.com/~rick/lexicon.html#edwards
Edwards's Law
"You cannot apply a technological solution to a sociological problem." Nobody seems to know who Edwards was, but pretty much the entire system administrator profession rests on the implicit assumption that he/she was egregiously mistaken.
This plausible-sounding but empty-headed dictum is most often referred to as "Edwards' [sic] Law" -- by the depressingly huge mass of semi-literates unable to correctly write possessives of singular nouns ending in "s".
Edward's law (never heard of it having a name before) doesn't really apply here anyway... delaying email doesn't really fit any definition of the word "solution" that I have heard of. Even the word "workaround" I used seemed a bit generous. James
Quoting "Rick Moen" <rick@linuxmafia.com>:
http://linuxmafia.com/~rick/lexicon.html#edwards
Edwards's Law
"You cannot apply a technological solution to a sociological problem." Nobody seems to know who Edwards was, but pretty much the entire system administrator profession rests on the implicit assumption that he/she was egregiously mistaken.
Whoever wrote it.. but the bit over the "entire system administrator profession" is wrong. Usually the managers are the ones believing in it. (Or politicians) Maybe it is good enough to detain the e-mails of the manager in question. He believes it works, and the rest can live in peace and harmony;-) My favourite anecdote is the "nifty proxy" filtering the word sex. Well, the music journalists had their trouble to look up sextets. But that was a glitch. "We" could/have to live with it. But the final straw was the manager not being able to fill out a form with "sex(M/F)" in it;-) Regards Peter
Quoting Peter Ross (Peter.Ross@bogen.in-berlin.de):
Whoever wrote it.. but the bit over the "entire system administrator profession" is wrong.
All me to introduce myself. Hullo, I'm Rick Moen, senior system administrator. A very large percentage of my job is creating, fixing, administering, and decommissioning technical solutions to social / sociological problems. This has been the case for some decades. I'm making no comment whatsoever on the technical notion that prompted this digression, merely on Edwards's Law.
Quoting Peter Ross (Peter.Ross@bogen.in-berlin.de):
Whoever wrote it.. but the bit over the "entire system administrator profession" is wrong.
All me to introduce myself. Hullo, I'm Rick Moen, senior system administrator. A very large percentage of my job is creating, fixing, administering, and decommissioning technical solutions to social / sociological problems. This has been the case for some decades.
I'm making no comment whatsoever on the technical notion that prompted this digression, merely on Edwards's Law.
I see where you are coming from, and I understand that some sociological problems have very elegant technical solutions. I don't think this is one of them. Problem: Students are sending SMS's, distracting themselves and others. Solution: Ban SMS's (and maybe ban mobile phones altogether) Problem: Students are now communicating via facebook, distracting themselves and others. Solution: Block Facebook Problem: Students are now using other IM applications Solution: Block IM applications Problem: Students have found a way to run IM applications even though we've blocked them. Solution: Better blocking ... And now the OP is up to delaying emails. I suspect it won't end there. People love to communicate and you won't stop them without putting a significant damper on their ability to do what they are supposed to be doing. James
On 14/03/12 13:53, James Harper wrote:
Quoting Peter Ross (Peter.Ross@bogen.in-berlin.de):
Whoever wrote it.. but the bit over the "entire system administrator profession" is wrong. All me to introduce myself. Hullo, I'm Rick Moen, senior system administrator. A very large percentage of my job is creating, fixing, administering, and decommissioning technical solutions to social / sociological problems. This has been the case for some decades.
I'm making no comment whatsoever on the technical notion that prompted this digression, merely on Edwards's Law.
I see where you are coming from, and I understand that some sociological problems have very elegant technical solutions. I don't think this is one of them.
Problem: Students are sending SMS's, distracting themselves and others. Solution: Ban SMS's (and maybe ban mobile phones altogether)
Problem: Students are now communicating via facebook, distracting themselves and others. Solution: Block Facebook
Problem: Students are now using other IM applications Solution: Block IM applications
Problem: Students have found a way to run IM applications even though we've blocked them. Solution: Better blocking ...
And now the OP is up to delaying emails. I suspect it won't end there. People love to communicate and you won't stop them without putting a significant damper on their ability to do what they are supposed to be doing.
The guys have been a little cagey about the target environment being a correctional facility (ie; a prison). This is due to the security-sensitive nature of that environment, within which we are severely restricted in what technology can be deployed. Ron
On 14 March 2012 13:53, James Harper <james.harper@bendigoit.com.au> wrote:
And now the OP is up to delaying emails. I suspect it won't end there. People love to communicate and you won't stop them without putting a significant damper on their ability to do what they are supposed to be doing.
It is not just about the "love to communicate", it is also about the need to communicate just to get your work done. If you block mobile communications, it is going to make it less efficient to do that work. Instead of a quick SMS or phone call "where are you?" it will be a 5 minute walk to the nearest pay phone only to find you don't have the spare change. Or that the public phone was removed due to vandalism and lack of use. -- Brian May <brian@microcomaustralia.com.au>
Rick Moen wrote:
This plausible-sounding but empty-headed dictum is most often referred to as "Edwards' [sic] Law" -- by the depressingly huge mass of semi-literates unable to correctly write possessives of singular nouns ending in "s".
I was going to object that Fowler (1e) contradicts Strunk & White (4e) on the subject, but he doesn't.
Rick Moen wrote:
I seldom point out the fallacy of a technical workaround to a social problem these days.
Edwards's Law
"You cannot apply a technological solution to a sociological problem." Nobody seems to know who Edwards was, but pretty much the entire system administrator profession rests on the implicit assumption that he/she was egregiously mistaken.
In general I agree with you, but... I haven't pointed it out before now, but the users in question are inmates in Australian prisons. Their communications access to the outside world is (necessarily) curtailed, which is why they have no IM or SMS. They have email, but it is heavily embargoed and monitored, and the monitoring staff are getting overwhelmed by these "SMS-like" mails. I assume the prisons deploy social solutions as well as the technical solutions I've been discussing, but I suspect some of the inmates are there because they do not respond well to social solutions :-) I don't expect adding a delay will STOP inmates sending "SMS-like" emails, but I think/hope the delay will reduce their number from "overwhelming" to "manageble".
On Wed, Mar 14, 2012 at 02:04:12AM +0000, James Harper wrote:
On 14/03/12 12:32, James Harper wrote:
Jason White wrote:
Mike Fabre <mike+luv@fabre.id.au> wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter. Are you sure you have to reinvent what is already available? You could install Postgrey, which (based on reports from friends who use it) can be very effective. Some background: the users are malicious; and are leveraging high speed of modern email as a substitute for SMS (which they are not allowed). The obvious solution is to artificially delay all mail for (say) fifteen minutes. This is hoped to reduce the enormous quantity of one-line messages like "hi F, how r u" and "im ok, u". Sigh. Users. Our jobs would be a lot easier without them.
Under Exim I would set up dual spool directories, so incoming email gets dumped in Q1, but only Q2 is processed for delivery automatically. A cron job would run every few minutes and move spool files older than 5 minutes from Q1 to Q2. Maybe you can do something similar with postfix?
I am currently looking into a strategy like this. Postfix has a hold queue which seems to be able to do this, but our custom filter set-up seems to have gotten in the way of that.
I don't think the greylist solution is the right one. You still want your server to receive the email... forcing a retry could introduce a much larger delay than you want.
Have you considered charging the users department for excessive emails? ;)
What if you do really have a legitimate need to have an email sent as quickly as possible? What happens then? (For example: you are talking to someone on the phone and want a feedback on a doc while on the phone, you could legitimately want to send the doc to the person as quickly as possible). I think its a case of barking the wrong tree here.
I seldom point out the fallacy of a technical workaround to a social problem these days. I assume the OP has already thought this thing through and has already had this argument with the person who gave the instruction. The whole thing sounds like a megalomaniac manager trying to run an office like a battery hen egg farm, which never works unless your employees enjoy being treated like crap.
Unless it's a school or university of course, and the users in question are students, which was my original assumption. Then you should indeed try and make their lives as difficult as possible! <evil grin>
This is the kind of environment it is for, so teaching users, and any other social fixes won't work. -- Mike Fabre
On 13/03/12 15:17, Mike Fabre wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
The first thing we thought of was to make all users use procmail, and set up a global procmail rule with a sleep in it, while this will almost certainly work, the users must not be able to run commands on the server, which they can do with a ~/.procmailrc file. I have tried to set up a postfix filter which would delay the mail (similar to this: http://pintant.cat/2010/04/14/how-to-delay-the-mails-postfix/) but that has an issue where it will only allow 5 of these filters to be running at a time, so if I where to send 10 messages with a 5 minute delay, the first 5 will take 5 minutes and the next 5 will take 10 minutes. I can change this limit within postfix but I would prefer to use a method that is more scalable. Anyone got any ideas?
Just guessing that mailscanner might do the trick. Although its a malware scanner, it is designed to queue up mail and batch process at specified interval. (If you dont want the scanning functions, you could probably disable these). Although it probably means that if an email gets on an empty or near empty queue just before the queue is flushed, it will be processed almost immediately. Is this a problem? See: Mailscanner.info Cheers, Daniel. -- ---------------------------------------- Daniel Jitnah Melbourne, Australia e: djitnah@greenwareit.com.au w: www.greenwareit.com.au SIP: dj-git@ekiga.net ---------------------------------------- ** For All your Linux, Open Source and IT requirements visit: www.greenwareit.com.au ** -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. For All your Open Source and IT requirements see: www.greenwareit.com.au
On Tue, Mar 13, 2012 at 03:41:30PM +1100, Daniel Jitnah wrote:
On 13/03/12 15:17, Mike Fabre wrote:
Hi, I have a postfix & dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
The first thing we thought of was to make all users use procmail, and set up a global procmail rule with a sleep in it, while this will almost certainly work, the users must not be able to run commands on the server, which they can do with a ~/.procmailrc file. I have tried to set up a postfix filter which would delay the mail (similar to this: http://pintant.cat/2010/04/14/how-to-delay-the-mails-postfix/) but that has an issue where it will only allow 5 of these filters to be running at a time, so if I where to send 10 messages with a 5 minute delay, the first 5 will take 5 minutes and the next 5 will take 10 minutes. I can change this limit within postfix but I would prefer to use a method that is more scalable. Anyone got any ideas?
Just guessing that mailscanner might do the trick. Although its a malware scanner, it is designed to queue up mail and batch process at specified interval. (If you dont want the scanning functions, you could probably disable these). Although it probably means that if an email gets on an empty or near empty queue just before the queue is flushed, it will be processed almost immediately. Is this a problem?
Looks like it should do the trick, seems to have too much bloat for my use case, but I'll look into it. Thanks. -- Mike Fabre
On 13/03/12 15:17, Mike Fabre wrote:
Hi, I have a postfix& dovecot server set up, and I have been given the task of making it put a arbitrary 5-10 minute delay for every email that comes through, whether it be for sent mail or received mail doesn't matter.
The first thing we thought of was to make all users use procmail, and set up a global procmail rule with a sleep in it, while this will almost certainly work, the users must not be able to run commands on the server, which they can do with a ~/.procmailrc file. I have tried to set up a postfix filter which would delay the mail (similar to this: http://pintant.cat/2010/04/14/how-to-delay-the-mails-postfix/) but that has an issue where it will only allow 5 of these filters to be running at a time, so if I where to send 10 messages with a 5 minute delay, the first 5 will take 5 minutes and the next 5 will take 10 minutes. I can change this limit within postfix but I would prefer to use a method that is more scalable. Anyone got any ideas?
I can sell you a special, limited-edition, Slow Server (tm). Featuring the latest in recycled envirofriendly technology, this machine has 128 MByte of RAM and only uses an array of old USB keys for storage. Larger mail spools can be stored on USB 1.1 external drives or over the 10 MBit ethernet. Once you start getting it loaded up with users, I'm pretty sure you'll start seeing long delays on all email processed by it :) -Toby
Toby Corkindale wrote:
I can sell you a special, limited-edition, Slow Server (tm).
Featuring the latest in recycled envirofriendly technology, this machine has 128 MByte of RAM and only uses an array of old USB keys for storage. Larger mail spools can be stored on USB 1.1 external drives or over the 10 MBit ethernet.
Once you start getting it loaded up with users, I'm pretty sure you'll start seeing long delays on all email processed by it :)
Not "enteprisey" enough! If you can get 15k SAS drives in those USB1 enclosures, maybe we can work something out ;-)
participants (11)
-
Brian May -
Daniel Jitnah -
James Harper -
Jason White -
Mike Fabre -
Mike Fabre -
Peter Ross -
Rick Moen -
Ron Fabre -
Toby Corkindale -
Trent W. Buck