Professional Software Engineering wrote:
* messages get held up in the delivery system. FTR, 5d is a more
common default timeout with MTAs, at least that seems to be the
case
[...]
* messages to lists might be held for moderator approval. Passing
over a weekend and then some wouldn't be unheard of. Add to
[...]
Thats a good point. A past limit of 5 days would be better.
I prefer to filter cruft out, rather than make it appear legitimate. If
someone is such a moron that their clock is that far off, do you really
want to be reading what they've sent?
Yes, because spam is filtered seperatly.
Do you never sit on a computer without bios battery ? ;) In fact not
everyone knows how to sync the system clock with ntp servers, unfortunately.
I'll take your word for it - I'm just suggesting that you might want to
benchmark a procmailrc with and without the call to the script to see
what overhead it actually adds, esp. since you're presumably subjecting
ALL of your email to this. Also, check how much memory resource the
tool uses, since you could receive quite a bit of mail concurrently if
say, your mail host is bumped offline for a while.
[poelzi(_at_)quamquam]> bin/ $ time ./testdate2.py Thu, 14 Sep 2003 14:38 -0400
Fri, 12 Sep 2003 04:25:57 -0000
real 0m0.098s
user 0m0.070s
sys 0m0.000s
fast enough for me.
I don't think that calculating the secounds back from rfc date is in
procmail easier and faster than python. My server idles in any case :)
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail