At 22:59 2003-09-11 +0200, daniel.poelzleithner wrote:
Maybe, i don't know procmail that well.
Well, hitting the list archives would net you the procmail scripts which
check date validity and skew, which coincidentally rely on only standard
system components, not on optional script languages.
I'm not off to knock your use of Python, or that you wrote a script to do
something, just pointing out that there are scripts available which can
accomplish the same thing without special requirements, and that "fixing"
the problem isn't really fixing it, it's disguising it.
I don't know if you understand that script corretly. Normaly it do not
change any headers. The script is tollerant when comparing the date and
respects the timezone the sender resists. When you manage your computer
correctly, the you shouldn't have a time that is more than a hour in the
future, not even that.
Well, my hosts all run calibrated clocks. That's totally aside from the
point - you're changing the Date: header from what the SENDER set it to,
and in the process, you're legitimizing hokey email.
I've been running the date checking recipe on ALL of my email (and I get a
LOT), and thus far, almost exclusively, the stuff that gets tagged by it is
spam (and since I don't use it as a POSITIVE identifier for spam, merely a
strong characteristic, things which merely have a boffed date don't get
trashed as spam) or mail which lags through some lists (for some reason, it
isn't uncommon for some messages through to be delayed by more than
24h). I also utilize the date at the end of the From_ header as the
comparator, which means I can run the filter against stored email at will -
versus running it against week-old saved email and having it flag
everything as goofy.
Normally a email do not need 3 days to get routet through the internet,
even with server problems in the route. Both thresholds are adjustable.
Only if one of them is surmounted, the date will be replaced by a new
one. The old is renamed to Old-Date.
At least you keep it, but the point is, if the date is far out of whack,
it's out of whack - making it _today_ doesn't make it any more right
because the sender certainly didn't send it to you right at this
instant. This is especially true if in fact the message IS old:
* 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
when I see delayed message announcements via the large discussion
lists I manage.
* messages to lists might be held for moderator approval. Passing
over a weekend and then some wouldn't be unheard of. Add to that that
a possible delay TO the list, plus a delay waiting for the moderator
(incl. possible delays delivering it to them for their approval and
delays sending it back to the list), and delays delivering it out of
the list, I could easily see the delay being amplified if something
went wrong, esp. at the common point: the list server.
This prevents your Mailbox from beeing flooded by mails from slutty users.
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?
Python is very fast.
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.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail