Re: Some date checking code.

At 15:29 2003-05-13 -0600, Daryle A. Tilroe did say:
> More efficient:
> >         :0
> >         * ^Date:.*\/[+-](1[4-9]|2-9][0-9])00
> Yup.  The former was just a bit more readable
Well, as written that second one has a syntax problem - it's missing the 
opening bracket before the 2-9
> I could probably tighten this up a bit too but generally I believe
> MTAs have timeouts approaching 3 days.
5 days is a common delivery failure.  OTOH, mail being delivered _to_ me 
never experiences delays that long unless someone is relaying mail through 
their own internal network and that is fscked up.  That'd be their problem 
anwyay.
Oh, I carry a pager 24/7 for a colo facility, so keeping on top of network 
outages and ensuring they are minimal is something I deal with anyway.
> If if there are mail interuptions I would not want to tag a pile of legit 
> mail as spam merely because it was a few days late.
Which is why it is fortunate that smart people _file_ their spam instead of 
dev/null'ing it.  That means that they can simply revise a rule and 
reprocess their spam mailbox with a formail split operation to reclaim 
messages which may have errantly been filed.  if you had a downtime, you 
might opt to tweak your rules anyway.
In fact, with a little bit of trickery, you could tweak your rules to 
automatically compensate for a downtime - use incoming messages as a 
"pulse" of sorts. Use the envelope timestamp from every message from the 
outside world   (versus those from the local host) and update a file with 
that.  If, upon receiving a message, you show a large difference between 
the reference pulse and this one, you must have been unreachable.  Then, 
you can update your allowed delay to compensate (perhaps emitting the value 
to a file which is includerc'd).  Automatically stepping down from the 
elveated delay would be another matter, but within a couple of hours or so 
of the connection being restored, it should be kosher.
Similarly, you could add such logic for messages relayed through your 
backup MX (which is something I elevate spammishness for, since there's NO 
reason mail should pass through my backup MX unless my host is down, and 
that's extremely rare as it is).  Everything passing through my backup MX 
is spam (spammers fail to inject spam at the regular MX, so they turn 
around and hand it to each of the backup MX until it is accepted by one, 
which being externally managed, isn't subject to the same set of DNSBLs).
Of course, spam that had a stale date on it in the first place will have an 
exceptionally stale date on it after your link is back up, so it's simply a 
sliding window.  You only lose out on dealing with spam which is dated in 
the future since if it gets delayed, it may be dated in the present by the 
time you receive it.
---
 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