The qpopper list archive ending on 11 Apr 2006
Topics covered in this issue include:
1. Tools for dealing with mboxes and stale .pop files?
Hugh Sasse <hgs at dmu dot ac dot uk>
Thu, 16 Mar 2006 15:36:42 +0000 (WET)
2. Re: Large spool mboxes => slow?
Alan Brown <alanb at digistar dot com>
Thu, 9 Mar 2006 17:21:42 -0500 (EST)
3. Re: Tools for dealing with mboxes and stale .pop files?
Hugh Sasse <hgs at dmu dot ac dot uk>
Mon, 20 Mar 2006 13:31:06 +0000 (WET)
4. Re: Tools for dealing with mboxes and stale .pop files?
Paul Carpenter <paul at dodgenet dot com>
Mon, 20 Mar 2006 14:51:41 -0600
5. Re: Tools for dealing with mboxes and stale .pop files?
Daniel Senie <dts at senie dot com>
Mon, 20 Mar 2006 16:22:53 -0500
6. Re: Tools for dealing with mboxes and stale .pop files?
"Jeff A dot Earickson" <jaearick at colby dot edu>
Mon, 20 Mar 2006 17:12:41 -0500 (EST)
7. Re: Tools for dealing with mboxes and stale .pop files?
Ken A <ka at pacific dot net>
Mon, 20 Mar 2006 16:22:36 -0800
8. Qpopper 4.0.9 (final) available -- fixes crash
Randall Gellens <randy at qualcomm dot com>
Mon, 20 Mar 2006 16:59:58 -0800
9. Re: Lock file permission problem
Randall Gellens <randy at qualcomm dot com>
Mon, 20 Mar 2006 17:08:33 -0800
10. Re: Large spool mboxes => slow?
Randall Gellens <randy at qualcomm dot com>
Mon, 20 Mar 2006 17:15:45 -0800
11. Re: Tools for dealing with mboxes and stale .pop files?
Hugh Sasse <hgs at dmu dot ac dot uk>
Tue, 21 Mar 2006 13:33:09 +0000 (WET)
12. Re: Tools for dealing with mboxes and stale .pop files?
Hugh Sasse <hgs at dmu dot ac dot uk>
Tue, 21 Mar 2006 13:58:33 +0000 (WET)
13. Re: Tools for dealing with mboxes and stale .pop files?
Paul Carpenter <paul at dodgenet dot com>
Wed, 22 Mar 2006 09:38:42 -0600
14. spam city...
James Medley <jmedley at aesrg dot tamu dot edu>
Wed, 5 Apr 2006 10:34:30 -0500
15. Re: spam city...
Alan Brown <alanb at digistar dot com>
Thu, 6 Apr 2006 06:15:20 -0400 (EDT)
16. Re: spam city...
Joseph S D Yao <jsdy at center dot osis dot gov>
Thu, 6 Apr 2006 15:23:09 -0400
17. Re: spam city...
Alan Brown <alanb at digistar dot com>
Fri, 7 Apr 2006 08:26:06 -0400 (EDT)
18. quota issues solved? (was RE: Large spool mboxes => slow?)
"Edward Chase" <echase at studentweb dot providence dot edu>
Fri, 7 Apr 2006 11:52:54 -0400
19. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Hugh Sasse <hgs at dmu dot ac dot uk>
Fri, 7 Apr 2006 17:24:26 +0100 (WEST)
20. Re: spam city...
Joseph S D Yao <jsdy at center dot osis dot gov>
Fri, 7 Apr 2006 12:10:54 -0400
21. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Fri, 07 Apr 2006 20:07:13 +0300
22. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Randall Gellens <randy at qualcomm dot com>
Fri, 7 Apr 2006 11:39:37 -0700
23. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Randall Gellens <randy at qualcomm dot com>
Fri, 7 Apr 2006 11:37:20 -0700
24. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Fri, 07 Apr 2006 23:23:04 +0300
25. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Clifton Royston <cliftonr at lava dot net>
Fri, 7 Apr 2006 11:46:58 -1000
26. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Sat, 08 Apr 2006 12:37:01 +0300
27. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Randall Gellens <randy at qualcomm dot com>
Mon, 10 Apr 2006 13:30:27 -0700
28. Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Tue, 11 Apr 2006 15:53:07 +0300
Date: Thu, 16 Mar 2006 15:36:42 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Tools for dealing with mboxes and stale .pop files?
On Thu, 9 Mar 2006, Randall Gellens wrote:
> There are scripts that have been posted in the past that let you cull old
> mail. Something else to think about.
I've failed to find anything with google. I've just checked a stale
temp-drop file (breaking it into messages, and using SHA256 sums to
compare) against the corresponding inbox, and have found messages
not in the inbox. They may have been deleted intentionally of
course, but since the temp-drop was not cleaned up I'm not sure what
I can say about its state. Where would be a good place to look for
tools to cull old messages, give people back messages they seem to
be missing (from inbox, found in temp-drop), etc?
I'm sure there are better tools than what I have hacked with ruby,
(designed with more edge cases in mind, used more often, better tested).
Thank you,
Hugh
Date: Thu, 9 Mar 2006 17:21:42 -0500 (EST)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: Large spool mboxes => slow?
On Thu, 9 Mar 2006, Hugh Sasse wrote:
> > Also enable server mode. enable caching of temp dir
>
> Enabling server mode is not possible given some types of client (from
> my reading of the docs). I don't know all the clients people use, so
> I must err on the side of caution. Or is that paranoid in 2006?
Server mode is only risky under the following circumstrances:
1: Access is made via POP3 and local disk (or a non-compatible imap3 server)
which use non-compatible locking methods.
2: Clients _simultaneously_ access using both methods.
I used server mode for many years in a mixed environment with no
problemss - by ensuring the lock mechanisms used were compatible.
Even without that, it is highly unusual for users to use both pop3 and
local disk access methods - those that do are usually technically savvy
enough to understand the corruption risk and not use both methods
simultaneously once it is explained to them.
> Thanks. I'm not au fait with disk internals, and thought that some
> disks may have many heads
They do (one per platter), but....
>, not just to read one cylinder at a time,
Only one head is ever active at one time with current commonly available
commercial available disk techmology.
The only way to achieve what you want is to use a suitable hardware
controller capable of simultaneously addressing multiple drive busses
(despite the other advantages of scsi, only one drive can be addressed
at a time on any given physical scsi bus.
Large scale (S)ATA or SASI raid controllers give better results most of
the time in terms of overall bandwidth. Latencies cannot be redcued
below seek+rotation times even with fancy controllers.
For ultimate bandwidth andlatencies, suitable solid state arrays are the
only way to go - but are extremely expensive.
--
If a person, or organisation, starts to play on your fears
it may be that person or organisation that you should fear.
Date: Mon, 20 Mar 2006 13:31:06 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Tools for dealing with mboxes and stale .pop files?
On Sat, 18 Mar 2006, Gregory Hicks wrote:
>
> > Date: Thu, 16 Mar 2006 15:36:42 +0000 (WET)
> > From: Hugh Sasse <hgs@dmu.ac.uk>
> > To: Subscribers of Qpopper <qpopper@lists.pensive.org>
> > Subject: Tools for dealing with mboxes and stale .pop files?
> >
> > On Thu, 9 Mar 2006, Randall Gellens wrote:
> >
> > > There are scripts that have been posted in the past that let you
> cull old
> > > mail. Something else to think about.
> >
> > I've failed to find anything with google. I've just checked a stale
> > temp-drop file (breaking it into messages, and using SHA256 sums to
>
> Try looking for "prunemail"... (prunemail was used to delete email
> older than $DATE...) After reading the rest of your message, though,
> not sure if this is what you're looking for...
I found this:
http://www.google.co.uk/url?sa=U&start=2&q=http://ftp.nluug.nl/mail/mh/contrib/9302/prunemail.shar&e=42
which seems to depend on a command called scan which I don't have.
If anyone else is interested in my ruby iterator for mboxes, it is here:
http://www.eng.cse.dmu.ac.uk/~hgs/ruby/mbox_each.rb
and used in this to split mailboxes into chunks:
http://www.eng.cse.dmu.ac.uk/~hgs/ruby/split_mbox.rb
But I'm not absolutely sure of its reliablility.
>
> Regards,
> Gregory Hicks
Thank you,
Hugh
Subject: Re: Tools for dealing with mboxes and stale .pop files?
From: Paul Carpenter <paul at dodgenet dot com>
Date: Mon, 20 Mar 2006 14:51:41 -0600
Google for a python script called "garbmail". I use it to scan
mailboxes for mail over a set age and delete just the old messages.
> > On Thu, 9 Mar 2006, Randall Gellens wrote:
> >
> > > There are scripts that have been posted in the past that let you
> cull old
> > > mail. Something else to think about.
Date: Mon, 20 Mar 2006 16:22:53 -0500
From: Daniel Senie <dts at senie dot com>
Subject: Re: Tools for dealing with mboxes and stale .pop files?
At 03:51 PM 3/20/2006, Paul Carpenter wrote:
>Google for a python script called "garbmail". I use it to scan
>mailboxes for mail over a set age and delete just the old messages.
I use garbmail. Sure wish it were in Perl. Lots of things I'd like to
tweak. Mostly, I'd like it to do a lot less at a given time (I'd
prefer to run it individually for mailboxes, rather than having it
sweep for me). I don't particularly enjoy working in Python though.
One of these days I'll rewrite what I need in Perl or C I suppose.
> > > On Thu, 9 Mar 2006, Randall Gellens wrote:
> > >
> > > > There are scripts that have been posted in the past that let you
> > cull old
> > > > mail. Something else to think about.
Date: Mon, 20 Mar 2006 17:12:41 -0500 (EST)
From: "Jeff A dot Earickson" <jaearick at colby dot edu>
Subject: Re: Tools for dealing with mboxes and stale .pop files?
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---559023410-570397931-1142892761=:13046
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Try the following perl script. Not by me, but modified to some
extent by me.
Jeff Earickson
Colby College
On Mon, 20 Mar 2006, Daniel Senie wrote:
> Date: Mon, 20 Mar 2006 16:22:53 -0500
> From: Daniel Senie <dts@senie.com>
> To: Paul Carpenter <paul@dodgenet.com>,
> Subscribers of Qpopper <qpopper@lists.pensive.org>
> Subject: Re: Tools for dealing with mboxes and stale .pop files?
>
> At 03:51 PM 3/20/2006, Paul Carpenter wrote:
>> Google for a python script called "garbmail". I use it to scan
>> mailboxes for mail over a set age and delete just the old messages.
>
> I use garbmail. Sure wish it were in Perl. Lots of things I'd like to tweak.
> Mostly, I'd like it to do a lot less at a given time (I'd prefer to run it
> individually for mailboxes, rather than having it sweep for me). I don't
> particularly enjoy working in Python though. One of these days I'll rewrite
> what I need in Perl or C I suppose.
>
>
>
>> > > On Thu, 9 Mar 2006, Randall Gellens wrote:
>> > >
>> > > > There are scripts that have been posted in the past that let you
>> > cull old
>> > > > mail. Something else to think about.
>
---559023410-570397931-1142892761=:13046
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=expire_mail
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.GSO.4.64.0603201712410.13046@emerald>
Content-Description:
Content-Disposition: attachment; filename=expire_mail
IyEvdXNyL2Jpbi9wZXJsIC0tCQkJCQkgICAgIC0qLXBlcmwtKi0NCiMNCiMh
L29wdC9wZXJsNS5kZWJ1Zy9iaW4vcGVybCAtLQkJCQkJICAgICAtKi1wZXJs
LSotDQojDQojIENvcHlyaWdodCAoYykgSW5mb3JtYXRpb24gU3lzdGVtcywg
VGhlIFByZXNzIEFzc29jaWF0aW9uIExpbWl0ZWQgMTk5Mw0KIyBQb3J0aW9u
cyBDb3B5cmlnaHQgKGMpIENvbXB1dGVyIE5ld3NwYXBlciBTZXJ2aWNlcyBM
aW1pdGVkIDE5OTMNCiMgQWxsIHJpZ2h0cyByZXNlcnZlZC4NCiMgDQojIExp
Y2Vuc2UgdG8gdXNlLCBjb3B5LCBtb2RpZnksIGFuZCBkaXN0cmlidXRlIHRo
aXMgd29yayBhbmQgaXRzDQojIGRvY3VtZW50YXRpb24gZm9yIGFueSBwdXJw
b3NlIGFuZCB3aXRob3V0IGZlZSBpcyBoZXJlYnkgZ3JhbnRlZCwNCiMgcHJv
dmlkZWQgdGhhdCB5b3UgYWxzbyBlbnN1cmUgbW9kaWZpZWQgZmlsZXMgY2Fy
cnkgcHJvbWluZW50IG5vdGljZXMNCiMgc3RhdGluZyB0aGF0IHlvdSBjaGFu
Z2VkIHRoZSBmaWxlcyBhbmQgdGhlIGRhdGUgb2YgYW55IGNoYW5nZSwgZW5z
dXJlDQojIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYXBwZWFy
IGluIGFsbCBjb3BpZXMsIHRoYXQgYm90aCB0aGUNCiMgY29weXJpZ2h0IG5v
dGljZSBhbmQgdGhpcyBwZXJtaXNzaW9uIG5vdGljZSBhcHBlYXIgaW4gc3Vw
cG9ydGluZw0KIyBkb2N1bWVudGF0aW9uLCBhbmQgdGhhdCB0aGUgbmFtZSBv
ZiBDb21wdXRlciBOZXdzcGFwZXIgU2VydmljZXMgbm90DQojIGJlIHVzZWQg
aW4gYWR2ZXJ0aXNpbmcgb3IgcHVibGljaXR5IHBlcnRhaW5pbmcgdG8gZGlz
dHJpYnV0aW9uIG9yIHVzZQ0KIyBvZiB0aGUgd29yayB3aXRob3V0IHNwZWNp
ZmljLCB3cml0dGVuIHByaW9yIHBlcm1pc3Npb24gZnJvbSBDb21wdXRlcg0K
IyBOZXdzcGFwZXIgU2VydmljZXMuDQojIA0KIyBCeSBjb3B5aW5nLCBkaXN0
cmlidXRpbmcgb3IgbW9kaWZ5aW5nIHRoaXMgd29yayAob3IgYW55IGRlcml2
ZWQgd29yaykNCiMgeW91IGluZGljYXRlIHlvdXIgYWNjZXB0YW5jZSBvZiB0
aGlzIGxpY2Vuc2UgYW5kIGFsbCBpdHMgdGVybXMgYW5kDQojIGNvbmRpdGlv
bnMuDQojIA0KIyBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEICJBUyBJUyIs
IFdJVEhPVVQgQU5ZIFdBUlJBTlRJRVMgT0YgQU5ZIEtJTkQsDQojIEVJVEhF
UiBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J
VEVEIFRPIEFOWSBJTVBMSUVEDQojIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRB
QklMSVRZLCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSwgQU5E
DQojIE5PTklORlJJTkdFTUVOVCBPRiBUSElSRCBQQVJUWSBSSUdIVFMuICBU
SEUgRU5USVJFIFJJU0sgQVMgVE8gVEhFIFFVQUxJVFkNCiMgQU5EIFBFUkZP
Uk1BTkNFIE9GIFRIRSBTT0ZUV0FSRSwgSU5DTFVESU5HIEFOWSBEVVRZIFRP
IFNVUFBPUlQgT1INCiMgTUFJTlRBSU4sIEJFTE9OR1MgVE8gVEhFIExJQ0VO
U0VFLiAgU0hPVUxEIEFOWSBQT1JUSU9OIE9GIFRIRSBTT0ZUV0FSRQ0KIyBQ
Uk9WRSBERUZFQ1RJVkUsIFRIRSBMSUNFTlNFRSAoTk9UIFRIRSBDT1BZUklH
SFQgT1dORVIpIEFTU1VNRVMgVEhFDQojIEVOVElSRSBDT1NUIE9GIEFMTCBT
RVJWSUNJTkcsIFJFUEFJUiBBTkQgQ09SUkVDVElPTi4gIElOIE5PIEVWRU5U
IFNIQUxMDQojIFRIRSBDT1BZUklHSFQgT1dORVIgQkUgTElBQkxFIEZPUiBB
TlkgU1BFQ0lBTCwgSU5ESVJFQ1QgT1IgQ09OU0VRVUVOVElBTA0KIyBEQU1B
R0VTIE9SIEFOWSBEQU1BR0VTIFdIQVRTT0VWRVIgUkVTVUxUSU5HIEZST00g
TE9TUyBPRiBVU0UsIERBVEEgT1INCiMgUFJPRklUUywgV0hFVEhFUiBJTiBB
TiBBQ1RJT04gT0YgQ09OVFJBQ1QsIE5FR0xJR0VOQ0UgT1IgT1RIRVIgVE9S
VElPVVMNCiMgQUNUSU9OLCBBUklTSU5HIE9VVCBPRiBPUiBJTiBDT05ORUNU
SU9OIFdJVEggVEhFIFVTRSBPUiBQRVJGT1JNQU5DRSBPRg0KIyBUSElTIFNP
RlRXQVJFLg0KIw0KIw0KIyAkSWQ6IGV4cGlyZV9tYWlsLHYgMS4xIDE5OTMv
MDYvMDMgMTA6NDM6MjYgcGhpbCBFeHAgJA0KIw0KDQojDQojIEluZm9ybWF0
aW9uIFN5c3RlbXMgRW5naW5lZXJpbmcgR3JvdXANCiMgUGhpbCBNYWxlDQoj
DQoNCmxvY2FsKCRfZXhwaXJlX21haWxfcmNzaWQpID0gJyRJZDogZXhwaXJl
X21haWwsdiAxLjEgMTk5My8wNi8wMyAxMDo0MzoyNiBwaGlsIEV4cCAkJzsN
CmxvY2FsKCRfY29weXJpZ2h0KSA9ICdDb3B5cmlnaHQgKGMpIEluZm9ybWF0
aW9uIFN5c3RlbXMsIFRoZSBQcmVzcyBBc3NvY2lhdGlvbiBMaW1pdGVkIDE5
OTMnOw0KDQpyZXF1aXJlICJnZXRvcHRzLnBsIjsJCQkjIG9wdGlvbiBoYW5k
bGluZw0KcmVxdWlyZSAidGltZWxvY2FsLnBsIjsJCQkjIHRpbWUgY29udmVy
c2lvbg0KcmVxdWlyZSAiY3RpbWUucGwiOwkJCSMgY3RpbWUgZm9yIHBzZXVk
by1tYWlsaW5nDQpyZXF1aXJlICJzdGF0LnBsIjsJCQkjIGZpbGUgc3RhdHVz
DQoNCiMgUGVybCBtYWlsIGV4cGlyZS4NCiMgVGhpcyBwcm9ncmFtIHJlbW92
ZXMgb2xkIG1lc3NhZ2VzIGZyb20gc3lzdGVtIG1haWxib3hlcy4NCiMgSXQg
YXNzdW1lcyB0aGUgZm9ybWF0IG9mIG1haWxib3hlcyB0byBiZSBzdGFuZGFy
ZA0KIyBzZW5kbWFpbCBmb3JtYXQgbWFpbCB3aXRoIGEgYmxhbmsgbGluZSBm
b2xsb3dlZCBieSBhIGBGcm9tICcgbGluZQ0KIyBzdGFydGluZyBlYWNoIGFu
ZCBldmVyeSBtZXNzYWdlLiBNYWlsYm94IGxvY2tpbmcgaXMgdmlhIGZsb2Nr
Lg0KIyBXb3JrcyB1bmRlciBTdW5PUy4NCiMNCiMgT3B0aW9ucyBhcyBmb2xs
b3dzOg0KIyAtdiAJCQl2ZXJib3NlIG91dHB1dA0KIyAtVgkJCWRpc3BsYXkg
dmVyc2lvbiBpbmZvcm1hdGlvbiBhbmQgcXVpdA0KIyAtZCAJCQlkZWJ1ZyBt
b2RlIChubyBjaGFuZ2UgdG8gbWFpbGJveCkNCiMgLWwJCQlkaXNwbGF5IG1l
c3NhZ2VzIGZvciBjcm9udGFiIG91dHB1dA0KIyAtegkJCWRvIG5vdCBkZWxl
dGUgemVybyBsZW5ndGggbWFpbGJveGVzDQojIC10CQkJZG8gbm90IHJlc2V0
IGFjY2VzcyBhbmQgbW9kaWZpY2F0aW9uIHRpbWVzIG9uIG1haWxib3gNCiMg
LW8gCQkJYWx3YXlzIG9wZW4gbWFpbGJveCwgbmV2ZXIganVzdCB0ZXN0IG1v
ZGlmaWNhdGlvbiBkYXRlDQojIC1NCQkJYXBwZW5kIGEgbWVzc2FnZSBkZXRh
aWxpbmcgZGVsZXRlZCBtZXNzYWdlcyBmb3IgdGhlIHVzZXINCiMgLVQJCQlk
byBub3QgcmVjb3JkIGRlbGl2ZXJ5IG9mIG1haWwgc3VtbWFyeSBvbiBtYWls
Ym94IGRhdGUNCiMgLVcJCQlhcHBlbmQgd2FybmluZyBhYm91dCB3aGF0IHdv
dWxkIGJlIGRlbGV0ZWQgKGltcGxlcyBkZWJ1ZykNCiMgLWEgZGF5cwkJbWVz
c2FnZXMgd2hvc2UgYWdlIGlzIGdyZWF0ZXIgdGhhbiBkYXlzIGFyZSBleHBp
cmVkDQojIC1PIGRheXMJCW1lc3NhZ2VzIHdob3NlIGFnZSBpcyBncmVhdGVy
IHRoYW4gZGF5cyBhcmUgZXhwaXJlZA0KIyAtdSB1c2VyCQlvbmx5IGNvbnNp
ZGVyIG1lc3NhZ2VzIGZyb20gdXNlciAocmVnZXhwKQ0KIyAtUyByZWFkfG9s
ZAlvbmx5IGNvbnNpZGVyIG1lc3NhZ2VzIHdpdGggc3RhdHVzIGBvbGQnLCBv
ciBgcmVhZCcNCiMgLVggZGVsZXRlZAlvbmx5IGNvbnNpZGVyIG1lc3NhZ2Vz
IHdpdGggWC1zdGF0dXMgYGRlbGV0ZWQnDQojIC1zIHN1YmplY3QJCW9ubHkg
Y29uc2lkZXIgbWVzc2FnZXMgd2l0aCBzdWJqZWN0IChyZWdleHApDQojDQoj
IEJhc2VkIG9uIGV4cGlyZV9tYWlsIGJ5IFN0ZXZlIE1pdGNoZWxsIChzdGV2
ZV9taXRjaGVsbEBjc3VmcmVzbm8uZWR1KQ0KIw0KIyBDaGFuZ2VzOiANCiMg
ICJzdGF0dXMgZGVsZXRlZCIgYWRkZWQgYnkgSmVmZiBFYXJpY2tzb24sIDEw
LzIyLzIwMDQNCiMgIHNraXAgZGVsZXRpb24gb2YgUElORS9JTUFQIEZPTERF
UiBJTlRFUk5BTCBEQVRBIG1zZ3MsIDExLzgvMjAwNQ0KDQoNCiMjIyMjDQoj
DQojIERlZmluaXRpb25zDQojDQojIyMjIw0KDQojIHNpdGUgcG9zdG1hc3Rl
ciAtIFhYWCBjaGFuZ2UgdGhpcyBhcyByZXF1aXJlZA0KJHBvc3RtYXN0ZXIg
PSAicG9zdG1hc3RlclxAY29sYnkuZWR1IjsNCg0KIyBjdXJyZW50IHVzZXIN
CiRtZSA9IGdldGxvZ2luIHx8IChnZXRwd3VpZCgkPCkpWzBdIHx8ICJ1bmtu
b3duIjsNCiRob21lID0gJEVOVnsnSE9NRSd9Ow0KDQojIGRlZmF1bHQgbWFp
bGJveCBmb3IgYSB1c2VyIC0gWFhYIGNoYW5nZSB0aGlzIGFzIHJlcXVpcmVk
DQokZGVmYXVsdF9tYWlsYm94ID0gJEVOVnsnTUFJTEJPWCd9IHx8ICIvdmFy
L21haWwvJG1lIjsNCg0KIy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiMg
bm90aWNlIHRvIGFwcGVuZCB0byBsaXN0IG9mIGRlbGV0ZWQgbWVzc2FnZXMN
CiMtLS1tb2RpZmllZCBmb3IgQ29sYnkNCiRub3RpY2UgPSAiDQpIZWxsbywN
Cg0KVGhlIG1lc3NhZ2VzIGxpc3RlZCBiZWxvdywgd2hpY2ggeW91IGhhZCBw
cmV2aW91c2x5IHJlYWQgYW5kIHdoaWNoIHdlcmUNCm1vcmUgdGhhbiAkYWdl
IGRheXMgb2xkLCBoYXZlIGJlZW4gZGVsZXRlZCBmcm9tIHlvdXIgc3lzdGVt
IG1haWxib3ggDQpvbiBDb2xieSdzIG1haWwgc2VydmVyIGJ5IHRoZSBzeXN0
ZW0ncyBtYWlsIGV4cGlyeSBhZ2VudC4gIElmIHlvdSBhY2Nlc3NlZA0KeW91
ciBtYWlsYm94IHZpYSBQT1AgKGVnLCBFdWRvcmEgb3IgT3V0bG9vaykgd2l0
aGluIHRoZSBsYXN0IHdlZWsgdGhlbiBhbnkNCmVtYWlsIG1vcmUgdGhhbiA3
IGRheXMgb2xkIGhhcyBiZWVuIGRlbGV0ZWQuICBGb3IgaW5mb3JtYXRpb24N
CmFib3V0IENvbGJ5J3MgcG9saWN5IG9uIG9sZCBlbWFpbCwgcGxlYXNlIHNl
ZSBzZWN0aW9uIDE0IG9mIHRoZSB3ZWJwYWdlOg0KDQogICBodHRwOi8vd3d3
LmNvbGJ5LmVkdS9pbmZvLnRlY2gvcG9saWNpZXMvaHRtbC9lbWFpbC5wb2xp
Y3kuaHRtbA0KDQpJZiB5b3UgYXJlIGEgUE9QIHVzZXIsIHRoaXMgd2VicGFn
ZSB3aWxsIGV4cGxhaW4gd2h5IG1lc3NhZ2VzIHlvdQ0KdGhvdWdodCB0aGF0
IHlvdSBoYWQgYWxyZWFkeSBkZWxldGVkIGFyZSBsaXN0ZWQgYmVsb3cuICBQ
bGVhc2Ugbm90ZSB0aGUNCmRpc2N1c3Npb24gYWJvdXQgdGhlIFwiTGVhdmUg
TWFpbCBvbiBTZXJ2ZXJcIiBvcHRpb247IHR1cm4gdGhpcyBvcHRpb24gb2Zm
DQppZiB5b3UgZG8gbm90IG5lZWQgaXQuDQoNCkZvciBmdXJ0aGVyIGluZm9y
bWF0aW9uIGFib3V0IHRoZSBNYWlsIEV4cGlyeSBBZ2VudCBzZWU6DQoNCiAg
IGh0dHA6Ly93d3cuY29sYnkuZWR1L2FkbWluaXN0cmF0aW9uX2NzL2l0cy9z
dXBwb3J0L2VtYWlsL2V4cGlyeV9hZ2VudC5jZm0NCg0KQW55IG1lc3NhZ2Ug
ZGVsZXRlZCBieSB0aGUgTWFpbCBFeHBpcnkgQWdlbnQgaXMgR09ORS4gIERv
IG5vdCBhc2sgZm9yIGl0IGJhY2suDQpTYXZlIGltcG9ydGFudCBtZXNzYWdl
cyBlbHNld2hlcmUuICBEbyBub3QgbGVhdmUgdGhlbSBpbiB5b3VyIElOQk9Y
Lg0KDQpGaWdodCBtYWlsYm94IGJsb2F0ISAgQSBiaWcgSU5CT1ggc2xvd3Mg
ZG93biB5b3VyIGVtYWlsIHJlYWRpbmcgYWJpbGl0eQ0KYnkgY29uc3VtaW5n
IG1vcmUgY29tcHV0ZXIgcmVzb3VyY2VzLiAgU2F2ZSBtZXNzYWdlcyB5b3Ug
d2FudCB0byBrZWVwDQp0byBhbHRlcm5hdGUgZm9sZGVycyBpZiB5b3UgYXJl
IGEgd2VibWFpbCB1c2VyLiAgRGVsZXRlIHVud2FudGVkIG1lc3NhZ2VzLg0K
VHVybiBvZmYgdGhlIFwiTGVhdmUgTWFpbCBvbiBTZXJ2ZXJcIiBvcHRpb24g
aWYgeW91IGFyZSBhIEV1ZG9yYSB1c2VyLg0KDQpJZiB5b3UgZG9uJ3Qgd2Fu
dCB0byBzZWUgdGhpcyBtZXNzYWdlIGV2ZXJ5IGRheSwga2VlcCB5b3VyIG1h
aWxib3gNCnNtYWxsZXIgdGhhbiA1MCBtZWdhYnl0ZXMhIQ0KDQogICBUaGFu
ayBZb3UsIA0KICAgVGhlIEZvbGtzIGluIEluZm9ybWF0aW9uIFRlY2hub2xv
Z3kgU2VydmljZXMiOw0KDQojLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K
IyB3YXJuaW5nIGFib3V0IG9sZCBtYWlsIG1lc3NhZ2VzDQojLS0tbW9kaWZp
ZWQgZm9yIENvbGJ5DQokd2FybmluZz0gIg0KSGVsbG8sDQoNClRoZSBtZXNz
YWdlcyBsaXN0ZWQgYmVsb3csIHdoaWNoIHlvdSBoYXZlIHByZXZpb3VzbHkg
cmVhZCBhbmQgd2hpY2ggaGF2ZQ0KZGVsaXZlcnkgZGF0ZXMgbW9yZSB0aGFu
IDMwIGRheXMgb2xkLCBzaG91bGQgYmUgZGVsZXRlZCBmcm9tIHlvdXIgc3lz
dGVtIA0KbWFpbGJveCBvbiBDb2xieSdzIG1haWwgc2VydmVyLg0KDQpBZnRl
ciBKYW51YXJ5IDEsIDE5OTksIGFueSBtYWlsIG1lc3NhZ2Ugb24gdGhlIENv
bGJ5IG1haWwgc2VydmVyDQpwcmV2aW91c2x5IG1hcmtlZCBhcyBcInJlYWRc
IiBieSB0aGUgbWFpbGVyIHNvZnR3YXJlLCBhbmQgZ3JlYXRlciB0aGFuIA0K
MzAgZGF5cyBvbGQgd2lsbCBiZSBhdXRvbWF0aWNhbGx5IGRlbGV0ZWQgZnJv
bSB5b3VyIHN5c3RlbSBtYWlsYm94LiAgDQpBIGNvcHkgd2lsbCAqbm90KiBi
ZSBzYXZlZCBhbnl3aGVyZSAtLSB0aGUgbWVzc2FnZSB3aWxsIGJlIEdPTkUu
ICANClVucmVhZCBtZXNzYWdlcywgbm8gbWF0dGVyIGhvdyBvbGQsIHdpbGwg
bm90IGJlIGRlbGV0ZWQuDQoNClBsZWFzZSBzZWUgdGhlIHdlYnBhZ2U6DQoN
CiAgIGh0dHA6Ly93d3cuY29sYnkuZWR1L2luZm8udGVjaC9wb2xpY2llcy9l
bWFpbC5wb2xpY3kuaHRtbA0KDQpmb3IgZnVydGhlciBpbmZvcm1hdGlvbiBh
Ym91dCBDb2xieSdzIHBvbGljeSBvbiBvbGQgZW1haWwuICBJZiB5b3UgYXJl
IGEgDQpFdWRvcmEgdXNlciwgdGhpcyB3ZWJwYWdlIHdpbGwgZXhwbGFpbiB3
aHkgbWVzc2FnZXMgeW91IHRob3VnaHQgdGhhdCB5b3UgDQpoYWQgYWxyZWFk
eSBkZWxldGVkIGFyZSBsaXN0ZWQgYmVsb3cuICBQbGVhc2Ugbm90ZSB0aGUg
ZGlzY3Vzc2lvbiBhYm91dCB0aGUgDQpcIkxlYXZlIE1haWwgb24gU2VydmVy
XCIgb3B0aW9uOyB0dXJuIHRoaXMgb3B0aW9uIG9mZiBpZiB5b3UgZG8gbm90
IG5lZWQgaXQuDQoNCklmIHlvdSByZWFkIHlvdXIgbWFpbCBvbiBjb2xieTAs
IHBsZWFzZSBkZWxldGUgb2xkIG1haWwgb3IgZmlsZSBpdCBpbiANCnlvdXIg
cGVyc29uYWwgbWFpbCBmb2xkZXJzLiAgQW5kIHBsZWFzZSByZWFkIHlvdXIg
ZS1tYWlsIG9uIGEgcmVndWxhcg0KYmFzaXMgc28gaXQgZG9lc24ndCBzdGFj
ayB1cC4NCg0KICAgVGhhbmsgWW91LCANCiAgIFRoZSBGb2xrcyBpbiBJbmZv
cm1hdGlvbiBUZWNobm9sb2d5IFNlcnZpY2VzIjsNCg0KIy0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KIyBzZXQgdGhlIHVtYXNrIGZvciB0ZW1wIGZp
bGVzDQp1bWFzayggMDcwMCApOw0KDQojIG1ha2Ugc3Rkb3V0IHVuYnVmZmVy
ZWQNCnNlbGVjdChTVERPVVQpOyAkfCA9IDE7DQoNCiRMT0NLX0VYID0gMjsJ
CQkJIyBsb2NrDQokTE9DS19VTiA9IDg7CQkJCSMgdW5sb2NrDQokU1RBUlRf
VElNRSA9IHRpbWU7CQkJIyB0aW1lIHJpZ2h0IG5vdw0KJFNFQ19QRVJfREFZ
ID0gMjQgKiA2MCAqIDYwOwkJIyBzZWNvbmRzIGluIGEgZGF5DQokbGluZV9i
dWZmZXIgPSAiIjsJCQkjIGVtcHR5IGxpbmUgYnVmZmVyDQoNCiMgbW9udGgg
bnVtYmVycw0KJG1vbl9udW17J0phbid9ID0gMDsNCiRtb25fbnVteydGZWIn
fSA9IDE7DQokbW9uX251bXsnTWFyJ30gPSAyOw0KJG1vbl9udW17J0Fwcid9
ID0gMzsNCiRtb25fbnVteydNYXknfSA9IDQ7DQokbW9uX251bXsnSnVuJ30g
PSA1Ow0KJG1vbl9udW17J0p1bCd9ID0gNjsNCiRtb25fbnVteydBdWcnfSA9
IDc7DQokbW9uX251bXsnU2VwJ30gPSA4Ow0KJG1vbl9udW17J09jdCd9ID0g
OTsNCiRtb25fbnVteydOb3YnfSA9IDEwOw0KJG1vbl9udW17J0RlYyd9ID0g
MTE7DQoNCiMjIyMjDQojDQojIFN1cHBvcnQNCiMNCiMjIyMjDQoNCiMgbGlu
ZSBidWZmZXIgZm9yIGxvb2stYWhlYWQNCg0Kc3ViIGdldF9saW5lDQp7DQoJ
bG9jYWwoICRsaW5lICkgPSAiIjsJCQkjIGxpbmUgdG8gcmV0dXJuDQoNCglp
ZiggISAoJGxpbmVfYnVmZmVyIGVxICIiKSApIHsNCgkJJGxpbmUgPSAkbGlu
ZV9idWZmZXI7DQoJCSRsaW5lX2J1ZmZlciA9ICIiOw0KCX0gZWxzZSB7DQoJ
CSRsaW5lID0gPE1CT1g+Ow0KCX0NCglyZXR1cm4gJGxpbmU7DQp9DQoNCiMg
cmVhZCBtZXNzYWdlIGZyb20gbWFpbGJveA0KDQpzdWIgcmVhZF9tZXNzYWdl
DQp7DQoJbG9jYWwoICRtc2cgKSA9ICIiOwkJCSMgbWVzc2FnZSB0byBzZW5k
IGJhY2sNCglsb2NhbCggJHByZXZfYmxhbmsgKSA9IDE7CQkjIGFzc3VtZSBw
cmV2aW91cyBsaW5lIGJsYW5rDQoJbG9jYWwoICRzZWVuX2Zyb20gKSA9IDA7
CQkjIHNlZW4gYSBmcm9tIGxpbmUNCglsb2NhbCggJGxpbmUgKSA9ICIiOwkJ
CSMgY3VycmVudCBsaW5lDQoNCgkjIHJlc2V0IHNvbWUgZ2xvYmFscw0KCSRt
c2dfc3RhdHVzID0gIiI7DQoJJG1zZ194c3RhdHVzID0gIiI7DQoJJG1zZ19z
dWJqZWN0ID0gIiI7DQoJJG1zZ19kYXRlID0gIiI7DQoNCgl3aGlsZSggJGxp
bmUgPSAmZ2V0X2xpbmUgKSB7DQogICAgDQoJCWlmKCAkbGluZSA9fiAvXkZy
b21ccysoW15cc10rKVxzKyguKikkLyApIHsNCgkJCSMgaWYgcHJldmlvdXMg
bGluZSB3YXMgYmxhbmssIHRoZW4gbGVnYWwgZnJvbSBsaW5lDQoJCQlpZigg
JHByZXZfYmxhbmsgKSB7DQoJCQkJIyBpZiBhbHJlYWR5IHNlZW4gYSBsZWdh
bCBmcm9tIGxpbmUsIHRoZW4gdGhpcyBpcyBuZXh0IG1lc3NhZ2UNCgkJCQlp
ZiggJHNlZW5fZnJvbSApIHsNCgkJCQkJIyBwdXNoYmFjayB0aGlzIGZyb20g
bGluZQ0KCQkJCQkkbGluZV9idWZmZXIgPSAkbGluZTsNCgkJCQkJcmV0dXJu
ICRtc2c7DQoJCQkJfQ0KCQkJCSRzZWVuX2Zyb20rKzsNCgkJCQkjIEZyb20g
bGluZSBmb3VuZCwgZXh0cmFjdCBpbmZvcm1hdGlvbg0KCQkJCSggJG1zZ19m
cm9tLCAkbXNnX2RhdGUgKSA9ICggJDEsICQyICk7DQoJCQkJJG1zZ19zdGFt
cCA9ICZyY3RpbWUoICRtc2dfZGF0ZSApOw0KCQkJCSRtc2dfYWdlID0gJmRh
eXNfb2xkKCAkbXNnX3N0YW1wICk7DQoJCQkJI3ByaW50IFNUREVSUiAibXNn
X2RhdGUgPSAkbXNnX2RhdGUsIG1zZ19zdGFtcCA9ICRtc2dfc3RhbXAsIG1z
Z19hZ2UgPSAkbXNnX2FnZVxuIjsNCgkJCX0NCgkJfSBlbHNpZiggJGxpbmUg
PX4gL15bU3NddGF0dXM6IChbQS1aYS16XSspLyApIHsNCgkJCSggJG1zZ19z
dGF0dXMgKSA9ICggJDEgKTsNCgkJfSBlbHNpZiggJGxpbmUgPX4gL15YLVtT
c110YXR1czogKFtBLVphLXpdKykvICkgew0KCQkJKCAkbXNnX3hzdGF0dXMg
KSA9ICggJDEgKTsNCgkJfSBlbHNpZiggJGxpbmUgPX4gL15bU3NddWJqZWN0
OiAoLiopJC8gKSB7DQoJCQkoICRtc2dfc3ViamVjdCApID0gKCAkMSApOw0K
CQl9DQoNCgkJIyBzZXQgcHJldmlvdXMgbGluZQ0KCQlpZiggJGxpbmUgPX4g
L14kLyApIHsNCgkJCSRwcmV2X2JsYW5rID0gMTsNCgkJfSBlbHNlIHsNCgkJ
CSRwcmV2X2JsYW5rID0gMDsNCgkJfQ0KDQoJCSRtc2cgLj0gJGxpbmU7DQoJ
fQ0KDQoJcmV0dXJuICRtc2c7DQp9DQoNCiMgd3JpdGUgYSBtZXNzYWdlIGlu
dG8gYSBtYWlsYm94DQpzdWIgd3JpdGVfbWVzc2FnZQ0Kew0KCXByaW50IFRN
UEYgIkBfIjsNCn0NCg0KIyBwYXJzZSB0aGUgY3RpbWUgc3RyaW5nIGludG8g
YSB0aW1lIHZhbHVlDQojIEZyb20gbGluZSBjb250YWlucyBsb2NhbCB0aW1l
DQoNCnN1YiByY3RpbWUNCnsNCglsb2NhbCggJHB0ICkgPSBAXzsJCQkjIHRp
bWUgdG8gY29udmVydA0KCWxvY2FsKCAkY3QgKSA9IC0xOwkJCSMgY29udmVy
dGVkIHRpbWUNCg0KCWlmKCRwdCA9fiAvXihbQS1aYS16XSspXHMrKFtBLVph
LXpdKylccysoWzAtOV0rKVxzKyhbMC05Ol0rKVxzKyhbMC05XSspLyApIHsN
CgkJKCAkZGF5LCAkbW9uLCAkbWRheSwgJHRpbWUsICR5ZWFyICkgPSAoICQx
LCAkMiwgJDMsICQ0LCAkNSApOw0KCQkoICRob3VyLCAkbWluLCAkc2VjICkg
PSBzcGxpdCggJzonLCAkdGltZSApOw0KCQlpZiggJHllYXIgPiAxOTAwICkg
eyAkeWVhciAtPSAxOTAwOyB9DQoJCSRjdCA9ICZ0aW1lbG9jYWwoJHNlYywk
bWluLCRob3VyLCRtZGF5LCRtb25fbnVteyRtb259LCR5ZWFyKTsNCgl9DQoJ
cmV0dXJuICRjdDsNCn0NCg0KIyBhZ2UgaW4gZGF5cw0Kc3ViIGRheXNfb2xk
DQp7DQoJbG9jYWwoICRhZ2V2ICkgPSBAXzsJCQkjIHRpbWUgdG8gY29udmVy
dA0KDQoJcmV0dXJuKCAoICRTVEFSVF9USU1FIC0gJGFnZXYgKSAvICRTRUNf
UEVSX0RBWSApOw0KfQ0KDQojIGJhc2VuYW1lDQpzdWIgYmFzZW5hbWUNCnsN
Cglsb2NhbCggJHBhdGggKSA9IEBfOwkJCSMgcGF0aCB0byBmaW5kIHRoZSBi
YXNlIG9mDQoJbG9jYWwoICRiYXNlICkgPSByaW5kZXgoICRwYXRoLCAiLyIg
KTsNCg0KCWlmKCAkYmFzZSA8IDAgKSB7DQoJCSRiYXNlID0gJHBhdGg7DQoJ
fSBlbHNlIHsNCgkJJGJhc2UgPSBzdWJzdHIoJHBhdGgsICRiYXNlICsgMSk7
DQoJfQ0KDQoJcmV0dXJuICRiYXNlOw0KfQ0KDQojIHVzYWdlIG1lc3NhZ2UN
CnN1YiB1c2FnZQ0Kew0KCXByaW50IFNUREVSUiAidXNhZ2U6IGV4cGlyZV9t
YWlsIFstdmxWXSBbLXpvdFRNV10gWy1kXSBcbiI7DQoJcHJpbnQgU1RERVJS
ICJ7IFstTyBkYXlzXSBbLXUgdXNlcl0gWy1TIHJlYWR8b2xkXSBbLXMgc3Vi
amVjdF0gWy1YIGRlbGV0ZWRdfSBtYWlsYm94Li4uXG4iOw0KCWV4aXQgMDsN
Cn0NCg0KIyMjIyMNCiMNCiMgTWFpbg0KIw0KIyMjIyMNCg0KJkdldG9wdHMo
ICdWdk86YTpvdTp6ZFM6czpNdFRsV1g6JyApIHx8ICZ1c2FnZTsNCg0KIyBj
b21wYXQNCiRvcHRfYSA9ICRvcHRfTyBpZiAoJG9wdF9PICYmICEkb3B0X2Ep
Ow0KDQojIGNoZWNrIHZlcnNpb24NCmlmKCAkb3B0X1YgKSB7DQoJcHJpbnQg
ImV4cGlyZV9tYWlsOiBtYWlsIGV4cGlyeSBhZ2VudFxuIjsNCglwcmludCAi
ZXhwaXJlX21haWw6ICRfZXhwaXJlX21haWxfcmNzaWRcbiI7DQoJJnVzYWdl
Ow0KfQ0KDQojIHVzZSBkZWZhdWx0IG1haWxib3ggaWYgbm9uIHN1cHBsaWVk
DQppZiggJCNBUkdWIDwgJFsgKSB7DQoJJEFSR1ZbMF0gPSAiJGRlZmF1bHRf
bWFpbGJveCI7DQp9DQoNCiMgZGVjb2RlIHN0YXR1cyBvcHRpb24NCmlmKCAk
b3B0X1MgKSB7DQoJaWYoICRvcHRfUyBlcSAib2xkIiApIHsNCgkJJG9wdF9T
ID0gIk8iOw0KCX0gZWxzaWYoICRvcHRfUyBlcSAicmVhZCIgKSB7DQoJCSRv
cHRfUyA9ICJSIjsNCgl9IGVsc2Ugew0KCQlwcmludCBTVERFUlIgImV4cGly
ZV9tYWlsOiBzdGF0dXMgbWF5IG9ubHkgYmUgb25lIG9mIGBvbGQnLCBgdW5y
ZWFkJ1xuIjsNCgkJJnVzYWdlOw0KCX0NCn0NCg0KIyBkZWNvZGUgWC1zdGF0
dXMgb3B0aW9uDQppZiggJG9wdF9YICkgew0KCWlmKCAkb3B0X1ggZXEgImRl
bGV0ZWQiICkgew0KCQkkb3B0X1ggPSAiRCI7DQoJfSBlbHNlIHsNCgkJcHJp
bnQgU1RERVJSICJleHBpcmVfbWFpbDogWC1zdGF0dXMgbWF5IG9ubHkgYmUg
YGRlbGV0ZWQnXG4iOw0KCQkmdXNhZ2U7DQoJfQ0KfQ0KDQojIGNoZWNrIHdl
IGFyZSBhY3R1YWxseSBkb2luZyBzb21lIHByb2Nlc3NpbmcNCmlmKCAhJG9w
dF9hICYmICEkb3B0X3UgJiYgISRvcHRfUyAmJiAhJG9wdF9zICYmICEkb3B0
X1gpIHsNCglwcmludCBTVERFUlIgImV4cGlyZV9tYWlsOiBtdXN0IHNwZWNp
ZnkgYXQgbGVhc3Qgb25lIG9mIC1PLCAtdSwgLVMsIC1zIG9yIC1YXG4iOw0K
CSZ1c2FnZTsNCn0NCg0KIyB3YXJuaW5nIG1vZGUgaW1wbGVzIGRlYnVnIG1v
ZGUNCmlmKCAkb3B0X1cgKSB7ICRvcHRfZCA9IDE7IH0NCg0KIyBkZWJ1ZyBt
b2RlIGltcGxpZXMgdmVyYm9zZSBtb2RlDQppZiggJG9wdF9kICkgeyAkb3B0
X3YgPSAxOyB9DQoNCiMgZm9yZWFjaCBtYWlsYm94Li4uDQp3aGlsZSggJG1h
aWxib3ggPSBzaGlmdCApIHsNCg0KCWlmKCAkb3B0X3YgJiYgISRvcHRfVyAp
IHsgcHJpbnQgU1RET1VUICJDaGVja2luZyBtYWlsYm94ICRtYWlsYm94XG4i
OyB9DQoNCgkjIGRvZXMgbWFpbGJveCBleGlzdA0KCWlmKCAhIC1mICRtYWls
Ym94ICkgeyBuZXh0OyB9DQoNCgkjIHN0YXQgdGhlIG1haWxib3gNCglAc2Ig
PSAmU3RhdCgkbWFpbGJveCk7DQoNCgkjIGNhbiBpdCBiZSBkZWxldGVkIG5v
dz8NCglpZiggISRvcHRfbyAmJiAkb3B0X2EgKSB7DQoJCSMgY2hlY2sgdGhl
IG1vZGlmaWNhdGlvbiBkYXRlDQoJCSRhZ2UgPSAmZGF5c19vbGQoQHNiWyRT
VF9NVElNRV0pOw0KCQlpZiggJGFnZSA+ICRvcHRfYSApIHsNCgkJCWlmKCAk
b3B0X3YgKSB7IHByaW50IFNURE9VVCAiRXhwaXJpbmcgbWFpbGJveCAkbWFp
bGJveFxuIjsgfQ0KCQkJaWYoICEkb3B0X2QgKSB7DQoJCQkJaWYoICRvcHRf
eiApIHsNCgkJCQkJb3BlbiggTUJPWCwgIj4kbWFpbGJveCIgKSB8fCANCgkJ
CQkJcHJpbnQgU1RERVJSICJleHBpcmVfbWFpbDogZmFpbGVkIHRvIHRydW5j
YXRlICRtYWlsYm94XG4iOw0KCQkJCQljbG9zZSggTUJPWCApOw0KCQkJCX0g
ZWxzZSB7DQoJCQkJCXVubGluayggJG1haWxib3ggKSB8fA0KCQkJCQlwcmlu
dCBTVERFUlIgImV4cGlyZV9tYWlsOiBmYWlsZWQgdG8gcmVtb3ZlICRtYWls
Ym94XG4iOw0KCQkJCX0NCgkJCX0NCgkJCW5leHQ7DQoJCX0NCgl9DQoNCgkj
IG9wZW4gdGhlIG1haWxib3gNCglpZiggIW9wZW4oIE1CT1gsICIrPCRtYWls
Ym94IiApICkgew0KCQlwcmludCBTVERFUlIgImV4cGlyZV9tYWlsOiB1bmFi
bGUgdG8gb3BlbiAkbWFpbGJveFxuIjsNCgkJbmV4dDsNCgl9DQoNCgkjIGxv
Y2sgdGhlIG1haWxib3gNCglpZiggIWZsb2NrKCBNQk9YLCAkTE9DS19FWCAp
ICkgew0KCQlwcmludCBTVERFUlIgImV4cGlyZV9tYWlsOiB1bmFibGUgdG8g
bG9jayAkbWFpbGJveFxuIjsNCgkJY2xvc2UoIE1CT1ggKTsNCgkJbmV4dDsN
Cgl9DQoNCgkjIG9wZW4gdGhlIHRlbXBvcmFyeSBmaWxlDQoJJHRtcG5hbWUg
PSAiJG1haWxib3guZXhwJCQiOw0KCWlmKCAhb3BlbiggVE1QRiwgIis+JHRt
cG5hbWUiICkgKSB7DQoJCXByaW50IFNUREVSUiAiZXhwaXJlX21haWw6IHVu
YWJsZSB0byBjcmVhdGUgdGVtcG9yYXJ5IGZpbGUgZm9yICRtYWlsYm94XG4i
Ow0KCQljbG9zZSggTUJPWCApOw0KCQluZXh0Ow0KCX0NCgl1bmxpbmsoICR0
bXBuYW1lICk7DQoNCgkjIGluaXQgY291bnRlcnMNCgkkY291bnQgPSAwOw0K
CSRleHAgPSAwOw0KDQoJIyByZWFkIGVhY2ggbWVzc2FnZSBpbiB0dXJuDQoJ
d2hpbGUoICRtc2cgPSAmcmVhZF9tZXNzYWdlICkgew0KDQoJCSRjb3VudCsr
Ow0KDQoJCSMtLS1za2lwIElNQVAvUElORSBGT0xERVIgSU5URVJOQUwgREFU
QSBtZXNzYWdlcw0KCQlpZigkbXNnX2Zyb20gPX4gL01BSUxFUl9EQUVNT04v
ICYmDQoJCSAgICRtc2dfc3ViamVjdCA9fiAvRE9OXCdUIERFTEVURSBUSElT
IE1FU1NBR0UgLS0gRk9MREVSIElOVEVSTkFMIERBVEEvKQ0KCQl7DQoJCQlp
ZiggJG9wdF92ICYmICEkb3B0X1cgKSB7DQoJCQkJI3ByaW50IFNURE9VVCAi
XHRNc2cgIyRjb3VudDogSU5URVJOQUwgREFUQVxyIjsNCgkJCQlwcmludCBT
VERPVVQgIlx0TXNnICMkY291bnQ6IElOVEVSTkFMIERBVEEgXG4iOw0KCQkJ
fQ0KCQkJJndyaXRlX21lc3NhZ2UoICRtc2cgKTsNCgkJCW5leHQ7DQoJCX0N
Cg0KCQkjIGxvb2tpbmcgZm9yIHNwZWNpZmljIGZyb20gdXNlcnMNCgkJaWYo
ICRvcHRfdSApIHsNCgkJCWlmKCAhICgkbXNnX2Zyb20gPX4gLyRvcHRfdS8p
ICkgew0KCQkJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJCQkJI3By
aW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogZnJvbSAgIFxyIjsNCgkJCQkJ
cHJpbnQgU1RET1VUICJcdE1zZyAjJGNvdW50OiBmcm9tICAgXG4iOw0KCQkJ
CX0NCgkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNnICk7DQoJCQluZXh0Ow0KCQkJ
fQ0KCQl9DQoNCgkJIyBjaGVjayBtZXNzYWdlIHN0YXR1cw0KCQlpZiggJG9w
dF9TICkgew0KCQkJaWYoICEoJG1zZ19zdGF0dXMgPX4gLyRvcHRfUy8pICkg
ew0KCQkJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJCQkJI3ByaW50
IFNURE9VVCAiXHRNc2cgIyRjb3VudDogc3RhdHVzICAgXHIiOw0KCQkJCQlw
cmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IHN0YXR1cyAgIFxuIjsNCgkJ
CQl9DQoJCQkJJndyaXRlX21lc3NhZ2UoICRtc2cgKTsNCgkJCQluZXh0Ow0K
CQkJfQ0KCQl9DQoNCgkJIyBjaGVjayBtZXNzYWdlIFgtc3RhdHVzDQoJCWlm
KCAkb3B0X1ggKSB7DQoJCQlpZiggISgkbXNnX3hzdGF0dXMgPX4gLyRvcHRf
WC8pICkgew0KCQkJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJCQkJ
I3ByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogc3RhdHVzICAgXHIiOw0K
CQkJCQlwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IHhzdGF0dXMgICBc
biI7DQoJCQkJfQ0KCQkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNnICk7DQoJCQkJ
bmV4dDsNCgkJCX0NCgkJfQ0KDQoJCSMgY2hlY2sgbWVzc2FnZSBzdWJqZWN0
DQoJCWlmKCAkb3B0X3MgKSB7DQoJCQlpZiggISAoJG1zZ19zdWJqZWN0ID1+
IC8kb3B0X3MvKSApIHsNCgkJCQlpZiggJG9wdF92ICYmICEkb3B0X1cgKSB7
DQoJCQkJCSNwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IHN1YmplY3Qg
ICBcciI7DQoJCQkJCXByaW50IFNURE9VVCAiXHRNc2cgIyRjb3VudDogc3Vi
amVjdCAgIFxuIjsNCgkJCQl9DQoJCQkmd3JpdGVfbWVzc2FnZSggJG1zZyAp
Ow0KCQkJbmV4dDsNCgkJCX0NCgkJfQ0KDQoJCSMgb25seSBvdGhlciB0aGlu
ZyB0byBjaGVjayBpcyBtZXNzYWdlIGFnZQ0KCQlpZiggJG9wdF9hICkgew0K
CQkJaWYoICRtc2dfYWdlIDw9ICRvcHRfYSApIHsNCgkJCQlpZiggJG9wdF92
ICYmICEkb3B0X1cgKSB7DQoJCQkJCSNwcmludCBTVERPVVQgIlx0TXNnICMk
Y291bnQ6IG5ld2VyICAgXHIiOw0KCQkJCQlwcmludCBTVERPVVQgIlx0TXNn
ICMkY291bnQ6IG5ld2VyICAgXG4iOw0KCQkJCX0NCgkJCQkmd3JpdGVfbWVz
c2FnZSggJG1zZyApOw0KCQkJCW5leHQ7DQoJCQl9DQoJCX0NCg0KCQkjIGxv
ZyB0aGUgZXhwaXJ5DQoJCWlmKCAkb3B0X3YgJiYgISRvcHRfVyApIHsNCgkJ
CSNwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IGV4cGlyZWQgICBcciI7
DQoJCQlwcmludCBTVERPVVQgIlx0TXNnICMkY291bnQ6IGV4cGlyZWQgICBc
biI7DQoJCX0NCg0KCQkjIGNvcHkgbWVzc2FnZSBhY3Jvc3MgaWYgaW4gZGVi
dWcNCgkJaWYoICRvcHRfZCApIHsNCgkJCSZ3cml0ZV9tZXNzYWdlKCAkbXNn
ICk7DQoJCQlpZigkb3B0X1cpIHsNCgkJCQkjIHJlY29yZCB0aGUgbWFpbCBt
ZXNzYWdlIGZyb20gYW5kIHN1YmplY3QgbGluZQ0KCQkJCSRwYWQgPSAnICcg
eCAoMjUgLSBsZW5ndGgoJG1zZ19mcm9tKSApOw0KCQkJCSRucGFkID0gJyAn
IHggKCA0IC0gbGVuZ3RoKCRjb3VudCkgKTsNCgkJCQkkc3ViamVjdHNbJGV4
cF0gPSAiJG5wYWQkY291bnQgJG1zZ19mcm9tJHBhZCAkbXNnX2RhdGVcbiAg
ICAgJG1zZ19zdWJqZWN0XG4iOw0KCQkJfQ0KCQl9IGVsc2Ugew0KCQkJIyBy
ZWNvcmQgdGhlIG1haWwgbWVzc2FnZSBmcm9tIGFuZCBzdWJqZWN0IGxpbmUN
CgkJCSRwYWQgPSAnICcgeCAoMjUgLSBsZW5ndGgoJG1zZ19mcm9tKSApOw0K
CQkJJG5wYWQgPSAnICcgeCAoIDQgLSBsZW5ndGgoJGNvdW50KSApOw0KCQkJ
JHN1YmplY3RzWyRleHBdID0gIiRucGFkJGNvdW50ICRtc2dfZnJvbSRwYWQg
JG1zZ19kYXRlXG4gICAgICRtc2dfc3ViamVjdFxuIjsNCgkJfQ0KDQoJCSMg
aW5jcmVtZW50IHRoZSBleHBpcmVkIG1lc3NhZ2UgY291bnQNCgkJJGV4cCsr
Ow0KCX0NCg0KCWlmKCAhJG9wdF9kICkgew0KDQoJCSMgaWYgc2VuZGluZyBt
YWlsIHRvIHRoZSBvd25lciBvZiB0aGUgbWFpbGJveCwgYXBwZW5kIG1lc3Nh
Z2Ugb24gdGhlIGVuZA0KCQlpZiggJG9wdF9NICYmICRleHAgPiAwICkgew0K
CQkJY2hvcCggJGN0ID0gJmN0aW1lKHRpbWUpICk7DQoJCQkkdG8gPSAmYmFz
ZW5hbWUoICRtYWlsYm94ICk7DQoJCQljaG9wKCAkZnJvbWRhdGUgPSBgZGF0
ZSArXCIlYSAlYiAlZCAlWCAlWVwiYCApOw0KCQkJcHJpbnQgVE1QRiAiRnJv
bSAkcG9zdG1hc3RlciAgJGZyb21kYXRlXG4iOw0KCQkJcHJpbnQgVE1QRiAi
RGF0ZTogJGN0XG4iOw0KCQkJcHJpbnQgVE1QRiAiRnJvbTogJHBvc3RtYXN0
ZXIgKE1haWwgRXhwaXJ5IEFnZW50KVxuIjsNCgkJCXByaW50IFRNUEYgIlJl
cGx5LVRvOiAkcG9zdG1hc3RlclxuIjsNCgkJCXByaW50IFRNUEYgIlRvOiAk
dG9cbiI7DQoJCQlwcmludCBUTVBGICJTdWJqZWN0OiBFeHBpcmVkIE1haWwg
U3VtbWFyeVxuXG4iOw0KCQkJcHJpbnQgVE1QRiAiJG5vdGljZVxuXG4iOw0K
CQkJIyBmaXR0ZWQgdG8gJHN1YmplY3RzIGxheW91dA0KCQkJcHJpbnQgVE1Q
RiAiIE1zZyBGcm9tICYgU3ViamVjdCAgICAgICAgICAgIERhdGVkXG5cbiI7
DQoJCQlmb3JlYWNoICRtc2cgKCBAc3ViamVjdHMgKSB7DQoJCQkJcHJpbnQg
VE1QRiAiJG1zZ1xuIjsNCgkJCX0NCg0KCQkJaWYoICEkb3B0X1QgKSB7DQoJ
CQkJIyBzZXQgdGhlIG1vZGlmaWNhdGlvbiB0aW1lIGZvciB0aGUgbWFpbGJv
eCB0byBiZSBub3cNCgkJCQlAc2JbJFNUX01USU1FXSA9IHRpbWU7DQoJCQl9
DQoJCX0NCg0KCQkjIGNvcHkgZGF0YSBiYWNrIGludG8gbWFpbGJveCB0byBw
cmVzZXJ2ZSBwZXJtaXNzaW9ucywgY3JlYXRpb24gdGltZQ0KCQkjIGFuZCB1
c2VyIGFuZCBncm91cCBpZA0KDQoJCSMgemVybyBsZW5ndGggdGhlIG1haWxi
b3gNCgkJdHJ1bmNhdGUoIE1CT1gsIDAgKTsNCgkJIyAqKiogU1RBUlQgQ3Jp
dGljYWwNCgkJIyBhbnkgZGF0YSB0byBjb3B5Pw0KCQlpZiggJGV4cCA8PSAk
Y291bnQgKSB7DQoJCQkjIHJlc3RhcnQgYm90aCBmaWxlcw0KCQkJc2VlayhN
Qk9YLCAwLCAwKTsNCgkJCXNlZWsoVE1QRiwgMCwgMCk7DQoJCQkjIGNvcHkg
ZmlsZSBpbnRvIG1haWxib3gsIGJldHRlciB3aXRoIHN5c3JlYWQvc3lzd3Jp
dGU/DQoJCQl3aGlsZSggPFRNUEY+ICkgew0KCQkJCXByaW50IE1CT1ggJF87
DQoJCQl9DQoJCX0gZWxzaWYoICEkb3B0X3ogKSB7DQoJCQl1bmxpbmsoICRt
YWlsYm94ICk7DQoJCX0NCgkJIyAqKiogRU5EIENyaXRpY2FsDQoNCgl9IGVs
c2Ugew0KCQkjIGlmIHNlbmRpbmcgd2FybmluZyB0byB0aGUgb3duZXIgb2Yg
dGhlIG1haWxib3gsIGFwcGVuZCB3YXJuaW5nDQoJCWlmKCAkb3B0X1cgJiYg
JGV4cCA+IDAgKSB7DQoJCQljaG9wKCAkY3QgPSAmY3RpbWUodGltZSkgKTsN
CgkJCSR0byA9ICZiYXNlbmFtZSggJG1haWxib3ggKTsNCgkJCWNob3AoICRm
cm9tZGF0ZSA9IGBkYXRlICtcIiVhICViICVkICVYICVZXCJgICk7DQpwcmlu
dGYoImZyb21kYXRlID0gJGZyb21kYXRlXG4iKTsNCgkJCXByaW50IFRNUEYg
IkZyb20gJHBvc3RtYXN0ZXIgICRmcm9tZGF0ZVxuIjsNCgkJCXByaW50IFRN
UEYgIkRhdGU6ICRjdFxuIjsNCgkJCXByaW50IFRNUEYgIkZyb206ICRwb3N0
bWFzdGVyIChNYWlsIEV4cGlyeSBBZ2VudClcbiI7DQoJCQlwcmludCBUTVBG
ICJSZXBseS1UbzogJHBvc3RtYXN0ZXJcbiI7DQoJCQlwcmludCBUTVBGICJU
bzogJHRvXG4iOw0KCQkJcHJpbnQgVE1QRiAiU3ViamVjdDogUGxlYXNlIGRl
bGV0ZSBvbGQgbWFpbCBmcm9tIHN5c3RlbSBtYWlsYm94XG5cbiI7DQoJCQlw
cmludCBUTVBGICIkd2FybmluZ1xuXG4iOw0KCQkJIyBmaXR0ZWQgdG8gJHN1
YmplY3RzIGxheW91dA0KCQkJcHJpbnQgVE1QRiAiIE1zZyBGcm9tICYgU3Vi
amVjdCAgICAgICAgICAgIERhdGVkXG5cbiI7DQoJCQlmb3JlYWNoICRtc2cg
KCBAc3ViamVjdHMgKSB7DQoJCQkJcHJpbnQgVE1QRiAiJG1zZ1xuIjsNCgkJ
CX0NCg0KCQkJaWYoICEkb3B0X1QgKSB7DQoJCQkJIyBzZXQgdGhlIG1vZGlm
aWNhdGlvbiB0aW1lIGZvciB0aGUgbWFpbGJveCB0byBiZSBub3cNCgkJCQlA
c2JbJFNUX01USU1FXSA9IHRpbWU7DQoJCQl9DQoNCgkJCSMgY29weSBkYXRh
IGJhY2sgaW50byBtYWlsYm94IHRvIHByZXNlcnZlIHBlcm1pc3Npb25zLCBj
cmVhdGlvbiB0aW1lDQoJCQkjIGFuZCB1c2VyIGFuZCBncm91cCBpZA0KCQ0K
CQkJIyB6ZXJvIGxlbmd0aCB0aGUgbWFpbGJveA0KCQkJdHJ1bmNhdGUoIE1C
T1gsIDAgKTsNCgkJCSMgKioqIFNUQVJUIENyaXRpY2FsDQoJCQkjIGFueSBk
YXRhIHRvIGNvcHk/DQoJCQlpZiggJGV4cCA8PSAkY291bnQgKSB7DQoJCQkJ
IyByZXN0YXJ0IGJvdGggZmlsZXMNCgkJCQlzZWVrKE1CT1gsIDAsIDApOw0K
CQkJCXNlZWsoVE1QRiwgMCwgMCk7DQoJCQkJIyBjb3B5IGZpbGUgaW50byBt
YWlsYm94LCBiZXR0ZXIgd2l0aCBzeXNyZWFkL3N5c3dyaXRlPw0KCQkJCXdo
aWxlKCA8VE1QRj4gKSB7DQoJCQkJCXByaW50IE1CT1ggJF87DQoJCQkJfQ0K
CQkJfSBlbHNpZiggISRvcHRfeiApIHsNCgkJCQl1bmxpbmsoICRtYWlsYm94
ICk7DQoJCQl9DQoJCQkjICoqKiBFTkQgQ3JpdGljYWwNCgkJfQ0KCX0NCg0K
CSMgdW5sb2NrIG1haWxib3gNCglmbG9jayggTUJPWCwgJExPQ0tfVU4gKTsN
Cg0KCSMgY2xvc2UgZmlsZXMNCgljbG9zZSggTUJPWCApOw0KCWNsb3NlKCBU
TVBGICk7DQoNCgkjIHJlc2V0IGFjY2VzcyBhbmQgbW9kaWZpY2F0aW9uIGRh
dGVzDQoJIyBpZiB3ZSBoYXZlIHNlbnQgbWFpbCwgdGhlbiB0aGUgbW9kaWZp
Y2F0aW9uIHRpbWUgaXMgdGhlIHRpbWUgb2YgdGhlIG1haWwNCglpZiggISRv
cHRfdCApIHsNCgkJdXRpbWUoIEBzYlskU1RfQVRJTUVdLCBAc2JbJFNUX01U
SU1FXSwgJG1haWxib3ggKTsNCgl9DQoNCgkjIHNob3cgY291bnRlcnMNCglp
ZiggJG9wdF92IHx8ICggJG9wdF9sICYmICRleHAgKSApIHsNCgkJcHJpbnQg
IiRtYWlsYm94IGNvbnRhaW5lZCAkY291bnQgbWVzc2FnZXMsIGV4cGlyZWQg
JGV4cCBtZXNzYWdlc1xuIjsNCgl9DQp9DQo
---559023410-570397931-1142892761=:13046--
Date: Mon, 20 Mar 2006 16:22:36 -0800
From: Ken A <ka at pacific dot net>
Subject: Re: Tools for dealing with mboxes and stale .pop files?
http://adc-archmbox.sourceforge.net/ is a nice tool for this sort of
thing too, and it's perl as well.
Ken A
Pacific.Net
Jeff A. Earickson wrote:
> Try the following perl script. Not by me, but modified to some
> extent by me.
>
> Jeff Earickson
> Colby College
>
> On Mon, 20 Mar 2006, Daniel Senie wrote:
>
>> Date: Mon, 20 Mar 2006 16:22:53 -0500
>> From: Daniel Senie <dts@senie.com>
>> To: Paul Carpenter <paul@dodgenet.com>,
>> Subscribers of Qpopper <qpopper@lists.pensive.org>
>> Subject: Re: Tools for dealing with mboxes and stale .pop files?
>>
>> At 03:51 PM 3/20/2006, Paul Carpenter wrote:
>>> Google for a python script called "garbmail". I use it to scan
>>> mailboxes for mail over a set age and delete just the old messages.
>>
>> I use garbmail. Sure wish it were in Perl. Lots of things I'd like to
>> tweak. Mostly, I'd like it to do a lot less at a given time (I'd
>> prefer to run it individually for mailboxes, rather than having it
>> sweep for me). I don't particularly enjoy working in Python though.
>> One of these days I'll rewrite what I need in Perl or C I suppose.
>>
>>
>>
>>> > > On Thu, 9 Mar 2006, Randall Gellens wrote:
>>> > >
>>> > > > There are scripts that have been posted in the past that let you
>>> > cull old
>>> > > > mail. Something else to think about.
>>
>
> ------------------------------------------------------------------------
>
> #!/usr/bin/perl -- -*-perl-*-
> #
> #!/opt/perl5.debug/bin/perl -- -*-perl-*-
> #
> # Copyright (c) Information Systems, The Press Association Limited 1993
> # Portions Copyright (c) Computer Newspaper Services Limited 1993
> # All rights reserved.
> #
> # License to use, copy, modify, and distribute this work and its
> # documentation for any purpose and without fee is hereby granted,
> # provided that you also ensure modified files carry prominent notices
> # stating that you changed the files and the date of any change, ensure
> # that the above copyright notice appear in all copies, that both the
> # copyright notice and this permission notice appear in supporting
> # documentation, and that the name of Computer Newspaper Services not
> # be used in advertising or publicity pertaining to distribution or use
> # of the work without specific, written prior permission from Computer
> # Newspaper Services.
> #
> # By copying, distributing or modifying this work (or any derived work)
> # you indicate your acceptance of this license and all its terms and
> # conditions.
> #
> # THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT ANY WARRANTIES OF ANY KIND,
> # EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO ANY IMPLIED
> # WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND
> # NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE ENTIRE RISK AS TO THE QUALITY
> # AND PERFORMANCE OF THE SOFTWARE, INCLUDING ANY DUTY TO SUPPORT OR
> # MAINTAIN, BELONGS TO THE LICENSEE. SHOULD ANY PORTION OF THE SOFTWARE
> # PROVE DEFECTIVE, THE LICENSEE (NOT THE COPYRIGHT OWNER) ASSUMES THE
> # ENTIRE COST OF ALL SERVICING, REPAIR AND CORRECTION. IN NO EVENT SHALL
> # THE COPYRIGHT OWNER BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
> # DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
> # PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
> # ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> # THIS SOFTWARE.
> #
> #
> # $Id: expire_mail,v 1.1 1993/06/03 10:43:26 phil Exp $
> #
>
> #
> # Information Systems Engineering Group
> # Phil Male
> #
>
> local($_expire_mail_rcsid) = '$Id: expire_mail,v 1.1 1993/06/03 10:43:26 phil Exp $';
> local($_copyright) = 'Copyright (c) Information Systems, The Press Association Limited 1993';
>
> require "getopts.pl"; # option handling
> require "timelocal.pl"; # time conversion
> require "ctime.pl"; # ctime for pseudo-mailing
> require "stat.pl"; # file status
>
> # Perl mail expire.
> # This program removes old messages from system mailboxes.
> # It assumes the format of mailboxes to be standard
> # sendmail format mail with a blank line followed by a `From ' line
> # starting each and every message. Mailbox locking is via flock.
> # Works under SunOS.
> #
> # Options as follows:
> # -v verbose output
> # -V display version information and quit
> # -d debug mode (no change to mailbox)
> # -l display messages for crontab output
> # -z do not delete zero length mailboxes
> # -t do not reset access and modification times on mailbox
> # -o always open mailbox, never just test modification date
> # -M append a message detailing deleted messages for the user
> # -T do not record delivery of mail summary on mailbox date
> # -W append warning about what would be deleted (imples debug)
> # -a days messages whose age is greater than days are expired
> # -O days messages whose age is greater than days are expired
> # -u user only consider messages from user (regexp)
> # -S read|old only consider messages with status `old', or `read'
> # -X deleted only consider messages with X-status `deleted'
> # -s subject only consider messages with subject (regexp)
> #
> # Based on expire_mail by Steve Mitchell (steve_mitchell@csufresno.edu)
> #
> # Changes:
> # "status deleted" added by Jeff Earickson, 10/22/2004
> # skip deletion of PINE/IMAP FOLDER INTERNAL DATA msgs, 11/8/2005
>
>
> #####
> #
> # Definitions
> #
> #####
>
> # site postmaster - XXX change this as required
> $postmaster = "postmaster\@colby.edu";
>
> # current user
> $me = getlogin || (getpwuid($<))[0] || "unknown";
> $home = $ENV{'HOME'};
>
> # default mailbox for a user - XXX change this as required
> $default_mailbox = $ENV{'MAILBOX'} || "/var/mail/$me";
>
> #----------------------------------------------------------------------
> # notice to append to list of deleted messages
> #---modified for Colby
> $notice = "
> Hello,
>
> The messages listed below, which you had previously read and which were
> more than $age days old, have been deleted from your system mailbox
> on Colby's mail server by the system's mail expiry agent. If you accessed
> your mailbox via POP (eg, Eudora or Outlook) within the last week then any
> email more than 7 days old has been deleted. For information
> about Colby's policy on old email, please see section 14 of the webpage:
>
> http://www.colby.edu/info.tech/policies/html/email.policy.html
>
> If you are a POP user, this webpage will explain why messages you
> thought that you had already deleted are listed below. Please note the
> discussion about the \"Leave Mail on Server\" option; turn this option off
> if you do not need it.
>
> For further information about the Mail Expiry Agent see:
>
> http://www.colby.edu/administration_cs/its/support/email/expiry_agent.cfm
>
> Any message deleted by the Mail Expiry Agent is GONE. Do not ask for it back.
> Save important messages elsewhere. Do not leave them in your INBOX.
>
> Fight mailbox bloat! A big INBOX slows down your email reading ability
> by consuming more computer resources. Save messages you want to keep
> to alternate folders if you are a webmail user. Delete unwanted messages.
> Turn off the \"Leave Mail on Server\" option if you are a Eudora user.
>
> If you don't want to see this message every day, keep your mailbox
> smaller than 50 megabytes!!
>
> Thank You,
> The Folks in Information Technology Services";
>
> #----------------------------------------------------------------------
> # warning about old mail messages
> #---modified for Colby
> $warning= "
> Hello,
>
> The messages listed below, which you have previously read and which have
> delivery dates more than 30 days old, should be deleted from your system
> mailbox on Colby's mail server.
>
> After January 1, 1999, any mail message on the Colby mail server
> previously marked as \"read\" by the mailer software, and greater than
> 30 days old will be automatically deleted from your system mailbox.
> A copy will *not* be saved anywhere -- the message will be GONE.
> Unread messages, no matter how old, will not be deleted.
>
> Please see the webpage:
>
> http://www.colby.edu/info.tech/policies/email.policy.html
>
> for further information about Colby's policy on old email. If you are a
> Eudora user, this webpage will explain why messages you thought that you
> had already deleted are listed below. Please note the discussion about the
> \"Leave Mail on Server\" option; turn this option off if you do not need it.
>
> If you read your mail on colby0, please delete old mail or file it in
> your personal mail folders. And please read your e-mail on a regular
> basis so it doesn't stack up.
>
> Thank You,
> The Folks in Information Technology Services";
>
> #----------------------------------------------------------------------
>
> # set the umask for temp files
> umask( 0700 );
>
> # make stdout unbuffered
> select(STDOUT); $| = 1;
>
> $LOCK_EX = 2; # lock
> $LOCK_UN = 8; # unlock
> $START_TIME = time; # time right now
> $SEC_PER_DAY = 24 * 60 * 60; # seconds in a day
> $line_buffer = ""; # empty line buffer
>
> # month numbers
> $mon_num{'Jan'} = 0;
> $mon_num{'Feb'} = 1;
> $mon_num{'Mar'} = 2;
> $mon_num{'Apr'} = 3;
> $mon_num{'May'} = 4;
> $mon_num{'Jun'} = 5;
> $mon_num{'Jul'} = 6;
> $mon_num{'Aug'} = 7;
> $mon_num{'Sep'} = 8;
> $mon_num{'Oct'} = 9;
> $mon_num{'Nov'} = 10;
> $mon_num{'Dec'} = 11;
>
> #####
> #
> # Support
> #
> #####
>
> # line buffer for look-ahead
>
> sub get_line
> {
> local( $line ) = ""; # line to return
>
> if( ! ($line_buffer eq "") ) {
> $line = $line_buffer;
> $line_buffer = "";
> } else {
> $line = <MBOX>;
> }
> return $line;
> }
>
> # read message from mailbox
>
> sub read_message
> {
> local( $msg ) = ""; # message to send back
> local( $prev_blank ) = 1; # assume previous line blank
> local( $seen_from ) = 0; # seen a from line
> local( $line ) = ""; # current line
>
> # reset some globals
> $msg_status = "";
> $msg_xstatus = "";
> $msg_subject = "";
> $msg_date = "";
>
> while( $line = &get_line ) {
>
> if( $line =~ /^From\s+([^\s]+)\s+(.*)$/ ) {
> # if previous line was blank, then legal from line
> if( $prev_blank ) {
> # if already seen a legal from line, then this is next message
> if( $seen_from ) {
> # pushback this from line
> $line_buffer = $line;
> return $msg;
> }
> $seen_from++;
> # From line found, extract information
> ( $msg_from, $msg_date ) = ( $1, $2 );
> $msg_stamp = &rctime( $msg_date );
> $msg_age = &days_old( $msg_stamp );
> #print STDERR "msg_date = $msg_date, msg_stamp = $msg_stamp, msg_age = $msg_age\n";
> }
> } elsif( $line =~ /^[Ss]tatus: ([A-Za-z]+)/ ) {
> ( $msg_status ) = ( $1 );
> } elsif( $line =~ /^X-[Ss]tatus: ([A-Za-z]+)/ ) {
> ( $msg_xstatus ) = ( $1 );
> } elsif( $line =~ /^[Ss]ubject: (.*)$/ ) {
> ( $msg_subject ) = ( $1 );
> }
>
> # set previous line
> if( $line =~ /^$/ ) {
> $prev_blank = 1;
> } else {
> $prev_blank = 0;
> }
>
> $msg .= $line;
> }
>
> return $msg;
> }
>
> # write a message into a mailbox
> sub write_message
> {
> print TMPF "@_";
> }
>
> # parse the ctime string into a time value
> # From line contains local time
>
> sub rctime
> {
> local( $pt ) = @_; # time to convert
> local( $ct ) = -1; # converted time
>
> if($pt =~ /^([A-Za-z]+)\s+([A-Za-z]+)\s+([0-9]+)\s+([0-9:]+)\s+([0-9]+)/ ) {
> ( $day, $mon, $mday, $time, $year ) = ( $1, $2, $3, $4, $5 );
> ( $hour, $min, $sec ) = split( ':', $time );
> if( $year > 1900 ) { $year -= 1900; }
> $ct = &timelocal($sec,$min,$hour,$mday,$mon_num{$mon},$year);
> }
> return $ct;
> }
>
> # age in days
> sub days_old
> {
> local( $agev ) = @_; # time to convert
>
> return( ( $START_TIME - $agev ) / $SEC_PER_DAY );
> }
>
> # basename
> sub basename
> {
> local( $path ) = @_; # path to find the base of
> local( $base ) = rindex( $path, "/" );
>
> if( $base < 0 ) {
> $base = $path;
> } else {
> $base = substr($path, $base + 1);
> }
>
> return $base;
> }
>
> # usage message
> sub usage
> {
> print STDERR "usage: expire_mail [-vlV] [-zotTMW] [-d] \n";
> print STDERR "{ [-O days] [-u user] [-S read|old] [-s subject] [-X deleted]} mailbox...\n";
> exit 0;
> }
>
> #####
> #
> # Main
> #
> #####
>
> &Getopts( 'VvO:a:ou:zdS:s:MtTlWX:' ) || &usage;
>
> # compat
> $opt_a = $opt_O if ($opt_O && !$opt_a);
>
> # check version
> if( $opt_V ) {
> print "expire_mail: mail expiry agent\n";
> print "expire_mail: $_expire_mail_rcsid\n";
> &usage;
> }
>
> # use default mailbox if non supplied
> if( $#ARGV < $[ ) {
> $ARGV[0] = "$default_mailbox";
> }
>
> # decode status option
> if( $opt_S ) {
> if( $opt_S eq "old" ) {
> $opt_S = "O";
> } elsif( $opt_S eq "read" ) {
> $opt_S = "R";
> } else {
> print STDERR "expire_mail: status may only be one of `old', `unread'\n";
> &usage;
> }
> }
>
> # decode X-status option
> if( $opt_X ) {
> if( $opt_X eq "deleted" ) {
> $opt_X = "D";
> } else {
> print STDERR "expire_mail: X-status may only be `deleted'\n";
> &usage;
> }
> }
>
> # check we are actually doing some processing
> if( !$opt_a && !$opt_u && !$opt_S && !$opt_s && !$opt_X) {
> print STDERR "expire_mail: must specify at least one of -O, -u, -S, -s or -X\n";
> &usage;
> }
>
> # warning mode imples debug mode
> if( $opt_W ) { $opt_d = 1; }
>
> # debug mode implies verbose mode
> if( $opt_d ) { $opt_v = 1; }
>
> # foreach mailbox...
> while( $mailbox = shift ) {
>
> if( $opt_v && !$opt_W ) { print STDOUT "Checking mailbox $mailbox\n"; }
>
> # does mailbox exist
> if( ! -f $mailbox ) { next; }
>
> # stat the mailbox
> @sb = &Stat($mailbox);
>
> # can it be deleted now?
> if( !$opt_o && $opt_a ) {
> # check the modification date
> $age = &days_old(@sb[$ST_MTIME]);
> if( $age > $opt_a ) {
> if( $opt_v ) { print STDOUT "Expiring mailbox $mailbox\n"; }
> if( !$opt_d ) {
> if( $opt_z ) {
> open( MBOX, ">$mailbox" ) ||
> print STDERR "expire_mail: failed to truncate $mailbox\n";
> close( MBOX );
> } else {
> unlink( $mailbox ) ||
> print STDERR "expire_mail: failed to remove $mailbox\n";
> }
> }
> next;
> }
> }
>
> # open the mailbox
> if( !open( MBOX, "+<$mailbox" ) ) {
> print STDERR "expire_mail: unable to open $mailbox\n";
> next;
> }
>
> # lock the mailbox
> if( !flock( MBOX, $LOCK_EX ) ) {
> print STDERR "expire_mail: unable to lock $mailbox\n";
> close( MBOX );
> next;
> }
>
> # open the temporary file
> $tmpname = "$mailbox.exp$$";
> if( !open( TMPF, "+>$tmpname" ) ) {
> print STDERR "expire_mail: unable to create temporary file for $mailbox\n";
> close( MBOX );
> next;
> }
> unlink( $tmpname );
>
> # init counters
> $count = 0;
> $exp = 0;
>
> # read each message in turn
> while( $msg = &read_message ) {
>
> $count++;
>
> #---skip IMAP/PINE FOLDER INTERNAL DATA messages
> if($msg_from =~ /MAILER_DAEMON/ &&
> $msg_subject =~ /DON\'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA/)
> {
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: INTERNAL DATA\r";
> print STDOUT "\tMsg #$count: INTERNAL DATA \n";
> }
> &write_message( $msg );
> next;
> }
>
> # looking for specific from users
> if( $opt_u ) {
> if( ! ($msg_from =~ /$opt_u/) ) {
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: from \r";
> print STDOUT "\tMsg #$count: from \n";
> }
> &write_message( $msg );
> next;
> }
> }
>
> # check message status
> if( $opt_S ) {
> if( !($msg_status =~ /$opt_S/) ) {
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: status \r";
> print STDOUT "\tMsg #$count: status \n";
> }
> &write_message( $msg );
> next;
> }
> }
>
> # check message X-status
> if( $opt_X ) {
> if( !($msg_xstatus =~ /$opt_X/) ) {
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: status \r";
> print STDOUT "\tMsg #$count: xstatus \n";
> }
> &write_message( $msg );
> next;
> }
> }
>
> # check message subject
> if( $opt_s ) {
> if( ! ($msg_subject =~ /$opt_s/) ) {
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: subject \r";
> print STDOUT "\tMsg #$count: subject \n";
> }
> &write_message( $msg );
> next;
> }
> }
>
> # only other thing to check is message age
> if( $opt_a ) {
> if( $msg_age <= $opt_a ) {
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: newer \r";
> print STDOUT "\tMsg #$count: newer \n";
> }
> &write_message( $msg );
> next;
> }
> }
>
> # log the expiry
> if( $opt_v && !$opt_W ) {
> #print STDOUT "\tMsg #$count: expired \r";
> print STDOUT "\tMsg #$count: expired \n";
> }
>
> # copy message across if in debug
> if( $opt_d ) {
> &write_message( $msg );
> if($opt_W) {
> # record the mail message from and subject line
> $pad = ' ' x (25 - length($msg_from) );
> $npad = ' ' x ( 4 - length($count) );
> $subjects[$exp] = "$npad$count $msg_from$pad $msg_date\n $msg_subject\n";
> }
> } else {
> # record the mail message from and subject line
> $pad = ' ' x (25 - length($msg_from) );
> $npad = ' ' x ( 4 - length($count) );
> $subjects[$exp] = "$npad$count $msg_from$pad $msg_date\n $msg_subject\n";
> }
>
> # increment the expired message count
> $exp++;
> }
>
> if( !$opt_d ) {
>
> # if sending mail to the owner of the mailbox, append message on the end
> if( $opt_M && $exp > 0 ) {
> chop( $ct = &ctime(time) );
> $to = &basename( $mailbox );
> chop( $fromdate = `date +\"%a %b %d %X %Y\"` );
> print TMPF "From $postmaster $fromdate\n";
> print TMPF "Date: $ct\n";
> print TMPF "From: $postmaster (Mail Expiry Agent)\n";
> print TMPF "Reply-To: $postmaster\n";
> print TMPF "To: $to\n";
> print TMPF "Subject: Expired Mail Summary\n\n";
> print TMPF "$notice\n\n";
> # fitted to $subjects layout
> print TMPF " Msg From & Subject Dated\n\n";
> foreach $msg ( @subjects ) {
> print TMPF "$msg\n";
> }
>
> if( !$opt_T ) {
> # set the modification time for the mailbox to be now
> @sb[$ST_MTIME] = time;
> }
> }
>
> # copy data back into mailbox to preserve permissions, creation time
> # and user and group id
>
> # zero length the mailbox
> truncate( MBOX, 0 );
> # *** START Critical
> # any data to copy?
> if( $exp <= $count ) {
> # restart both files
> seek(MBOX, 0, 0);
> seek(TMPF, 0, 0);
> # copy file into mailbox, better with sysread/syswrite?
> while( <TMPF> ) {
> print MBOX $_;
> }
> } elsif( !$opt_z ) {
> unlink( $mailbox );
> }
> # *** END Critical
>
> } else {
> # if sending warning to the owner of the mailbox, append warning
> if( $opt_W && $exp > 0 ) {
> chop( $ct = &ctime(time) );
> $to = &basename( $mailbox );
> chop( $fromdate = `date +\"%a %b %d %X %Y\"` );
> printf("fromdate = $fromdate\n");
> print TMPF "From $postmaster $fromdate\n";
> print TMPF "Date: $ct\n";
> print TMPF "From: $postmaster (Mail Expiry Agent)\n";
> print TMPF "Reply-To: $postmaster\n";
> print TMPF "To: $to\n";
> print TMPF "Subject: Please delete old mail from system mailbox\n\n";
> print TMPF "$warning\n\n";
> # fitted to $subjects layout
> print TMPF " Msg From & Subject Dated\n\n";
> foreach $msg ( @subjects ) {
> print TMPF "$msg\n";
> }
>
> if( !$opt_T ) {
> # set the modification time for the mailbox to be now
> @sb[$ST_MTIME] = time;
> }
>
> # copy data back into mailbox to preserve permissions, creation time
> # and user and group id
>
> # zero length the mailbox
> truncate( MBOX, 0 );
> # *** START Critical
> # any data to copy?
> if( $exp <= $count ) {
> # restart both files
> seek(MBOX, 0, 0);
> seek(TMPF, 0, 0);
> # copy file into mailbox, better with sysread/syswrite?
> while( <TMPF> ) {
> print MBOX $_;
> }
> } elsif( !$opt_z ) {
> unlink( $mailbox );
> }
> # *** END Critical
> }
> }
>
> # unlock mailbox
> flock( MBOX, $LOCK_UN );
>
> # close files
> close( MBOX );
> close( TMPF );
>
> # reset access and modification dates
> # if we have sent mail, then the modification time is the time of the mail
> if( !$opt_t ) {
> utime( @sb[$ST_ATIME], @sb[$ST_MTIME], $mailbox );
> }
>
> # show counters
> if( $opt_v || ( $opt_l && $exp ) ) {
> print "$mailbox contained $count messages, expired $exp messages\n";
> }
> }
Date: Mon, 20 Mar 2006 16:59:58 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Qpopper 4.0.9 (final) available -- fixes crash
Qpopper 4.0.9 (final) is available at
<ftp://ftp.qualcomm.com/eudora/servers/unix/popper/>.
The full list of changes from one release to the next is on the FTP
site, at <ftp://ftp.qualcomm.com/eudora/servers/unix/popper/Changes>.
Note that this release fixes a potential crash (from authenticated
users). All users of Qpopper are encouraged to upgrade to this
release.
Changes from 4.0.8 to 4.0.9:
-----------------------------
1. Fix crash if too many MDEF commands entered.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
There is a life-size picture of a dogcow conveniently located in the
Finder. Look under "Page Setup..." Now look under "Options." Like
any talented dog, it can do flips. Like any talented cow, it can do
precision bitmap alignment. --Apple Tech Note #31
Date: Mon, 20 Mar 2006 17:08:33 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Lock file permission problem
At 9:49 AM -0800 3/9/06, Lee Terrell wrote:
> Hi All,
>
> I recently set up qpopper 4.0.8 on a new machine and I have been seeing
> new errors in regards to username.lock files. This problem isn't
> affecting every users, but I am getting a fair amount of the following
> error message:
>
> -ERR [SYS/TEMP] maillock error 'Unable to create lockfile' (2) on
> '/var/spool/mail/u1/u2/user': Permission denied (13)
>
> I do have the enable-temp-drop option active so we can see when users
> last popped their mail spool, but it's not a pop.lock error message.
You mean the 'keep-temp-drop' option?
> When I check, I can easily see the problem is that the user.lock file is
> set to root:root for ownership, so the user's pop session can't
> overwrite the lock file.
That's weird.
>
> I've been reading past posts from the list to try and get a handle on
> the lock file situation. I thought my understanding was that qpopper
> makes the lock file at the beginning of the session, and if the user's
> session is interrupted, the lock file is removed after a few minutes. I
> have found several lock files that are lingering for more than several
> hours though, and a few more than a day.
The .lock file should go away when the popper process cleans up
before exiting, which it will do as soon as it is aware the user has
disconnected. Are you sure you are seeing .lock files linger, and
not .pop files? If so, is the popper process still active?
>
> I've been comparing my old server configuration and setup with the new
> one, and I don't see any glaring differences. What are some possible
> areas I can investigate regarding these errors? I'm going through the
> manual performance tuning section again currently to see if anything
> sticks out to me.
There shouldn't be anything you can do to Qpopper to make this
happen. Could it be some other process doing it?
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
I hate mankind, for I think myself one of the best of them,
and I know how bad I am." --Samuel Johnson
Date: Mon, 20 Mar 2006 17:15:45 -0800
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: Large spool mboxes => slow?
At 5:21 PM -0500 3/9/06, Alan Brown wrote:
> Server mode is only risky under the following circumstrances:
>
> 1: Access is made via POP3 and local disk (or a non-compatible imap3 server)
> which use non-compatible locking methods.
>
> 2: Clients _simultaneously_ access using both methods.
I think server mode is potentially risky if the spool is modified by
local processes other than popper or the local delivery agent during
a pop session. Even if the locking mechanisms are compatible, since
Qpopper unlocks the spool during the session anyway. The key is that
the spool has to be modified during the pop session, which is your #2
point.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Experience is that marvelous thing that enables you recognize a
mistake when you make it again.
Date: Tue, 21 Mar 2006 13:33:09 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Tools for dealing with mboxes and stale .pop files?
On Mon, 20 Mar 2006, Paul Carpenter wrote:
> Google for a python script called "garbmail". I use it to scan
> mailboxes for mail over a set age and delete just the old messages.
I tried the first 3 pages of google and found a lot of dead links,
and a lot of places telling one to google for it. It seems to
have vanished.
Thanks
Hugh
Date: Tue, 21 Mar 2006 13:58:33 +0000 (WET)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: Tools for dealing with mboxes and stale .pop files?
On Mon, 20 Mar 2006, Ken A wrote:
> http://adc-archmbox.sourceforge.net/ is a nice tool for this sort of thing
> too, and it's perl as well.
Thank you. Seems nicely split into functions and doesn't assume
that the mbox will fit in memory. It doesn't do everything I need,
but it's given me a few ideas to improve my Ruby code. I'll give
this more thought later.
> Ken A
> Pacific.Net
Thank you,
Hugh
Subject: Re: Tools for dealing with mboxes and stale .pop files?
From: Paul Carpenter <paul at dodgenet dot com>
Date: Wed, 22 Mar 2006 09:38:42 -0600
I've posted a copy of garbmail.tgz at
www.dodgenet.com/~paul/garbmail.tgz
I don't remember where I originally got it but I think there is some
info in the README.
On Tue, 2006-03-21 at 13:33 +0000, Hugh Sasse wrote:
> On Mon, 20 Mar 2006, Paul Carpenter wrote:
>
> > Google for a python script called "garbmail". I use it to scan
> > mailboxes for mail over a set age and delete just the old messages.
>
> I tried the first 3 pages of google and found a lot of dead links,
> and a lot of places telling one to google for it. It seems to
> have vanished.
>
> Thanks
> Hugh
>
From: James Medley <jmedley at aesrg dot tamu dot edu>
Subject: spam city...
Date: Wed, 5 Apr 2006 10:34:30 -0500
Hello All,
Lately my mail queue has been getting a much higher number of queued
messages, mainly from spam. Apparently someone is sending spam and
using my server as a return address. This has in turn stopped some of
our legitimate mail from going through and some showing a reason as
temporarily greylisted. I am running sendmail 8.12.9/ qpopper 4.0.5
on a Mac G4, OS 10.2.8. If someone can please point me in the right
direction I would appreciate it.
Jim
Date: Thu, 6 Apr 2006 06:15:20 -0400 (EDT)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: spam city...
Start by setting a SPF v1 record in your DNS.
Then look at inbound mail filters and possibly joining the spam-l list.
This is really the wrong list to discuss spam control and reactions.
On Wed, 5 Apr 2006, James Medley wrote:
> Hello All,
>
> Lately my mail queue has been getting a much higher number of queued
> messages, mainly from spam. Apparently someone is sending spam and
> using my server as a return address. This has in turn stopped some of
> our legitimate mail from going through and some showing a reason as
> temporarily greylisted. I am running sendmail 8.12.9/ qpopper 4.0.5
> on a Mac G4, OS 10.2.8. If someone can please point me in the right
> direction I would appreciate it.
>
> Jim
>
>
>
--
If a person, or organisation, starts to play on your fears
it may be that person or organisation that you should fear.
Date: Thu, 6 Apr 2006 15:23:09 -0400
From: Joseph S D Yao <jsdy at center dot osis dot gov>
Subject: Re: spam city...
On Wed, Apr 05, 2006 at 10:34:30AM -0500, James Medley wrote:
> Hello All,
>
> Lately my mail queue has been getting a much higher number of queued
> messages, mainly from spam. Apparently someone is sending spam and
> using my server as a return address. This has in turn stopped some of
> our legitimate mail from going through and some showing a reason as
> temporarily greylisted. I am running sendmail 8.12.9/ qpopper 4.0.5
> on a Mac G4, OS 10.2.8. If someone can please point me in the right
> direction I would appreciate it.
Greylisting MEANS that mail from your site [or any site] is temporarily
not accepted. When your mail site tries again, it will be accepted by
the recipient site. This works because Spam sites typically do not try
again.
This is not directed towards you, and probably has nothing at all to do
with the spam you are receiving, and everything to do with the spam the
recipient sites are receiving.
If it is vital that mail from your site gets to the recipient site
immediately, you must contact the recipient site and ask them to
whitelist you.
IF what you mean is that Spam sites are using you as a third-party
relay, then for heaven's sakes, turn off third-party relaying!!! ;-)
Please see also:
<http://projects.puremagic.com/greylisting/>
<http://hcpnet.free.fr/milter-greylist/>
<http://www.postfix.org/SMTPD_POLICY_README.html>
[Google is your friend!]
--
Joe Yao
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
Date: Fri, 7 Apr 2006 08:26:06 -0400 (EDT)
From: Alan Brown <alanb at digistar dot com>
Subject: Re: spam city...
On Thu, 6 Apr 2006, Joseph S D Yao wrote:
> Greylisting MEANS that mail from your site [or any site] is temporarily
> not accepted.
Or mail claiming to be from that domain.
From: "Edward Chase" <echase at studentweb dot providence dot edu>
Subject: quota issues solved? (was RE: Large spool mboxes => slow?)
Date: Fri, 7 Apr 2006 11:52:54 -0400
The snippet below from a previous email gives me the impression that it
could help me with with an issue I'm having here with users quotas.
My current scenario...
* /var/mail holds the users mailboxes (and is it's own filesystem).
* /var/spool/poptemp is qpopper's scratch area, I'm assuming this is the
"temp-drop".
* My users have a quota on /var/mail.
* Assume a user is at his limit then check email.
* /var/mail/user is moved to /var/spool/poptemp/.user.pop by qpopper
(filesytem quota on /var/mail is now zero)
* sendmail now moves email from delivery queue into /var/mail/user
* qpopper is done and attempts to move /var/spool/poptemp/.user.pop back
to
/var/mail/user, but can't because the new mail that is in /var/mail/user
plus the old mail in /var/spool/poptemp/.user.pop is too much for the
quota
on /var/mail. Yes, the user is leaving mail on server (grrrr...)
* now the user has mail data in two places and the thing just keeps
getting
worse as the user checking email will allow the file in the temp-drop to
grow. (Now I'm thinking to myself, why didn't I put user quotas on
/var?)
Assuming you follow that... Should I be able to fix this problem by
putting
the temp-drop in the /var/mail filesystem and use the -fast-io switch?
> -----Original Message-----
> From: Randall Gellens [mailto:randy@qualcomm.com]
> Sent: Thursday, March 09, 2006 3:13 PM
> To: Hugh Sasse; Gregory Hicks
> Cc: qpopper@lists.pensive.org
> Subject: Re: Large spool mboxes => slow?
[snip]
> You might also want to think about using the fast-io option, which
> renames the temp-drop to the spool instead of copying it. This only
> works if the temp drop and spool are on the same filesystem.
[snip]
Date: Fri, 7 Apr 2006 17:24:26 +0100 (WEST)
From: Hugh Sasse <hgs at dmu dot ac dot uk>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
On Fri, 7 Apr 2006, Edward Chase wrote:
> The snippet below from a previous email gives me the impression that it
> could help me with with an issue I'm having here with users quotas.
It was my problem, and it doesn't seem to be as bad as it was.
>
> My current scenario...
>
> * /var/mail holds the users mailboxes (and is it's own filesystem).
> * /var/spool/poptemp is qpopper's scratch area, I'm assuming this is the
> "temp-drop".
Is this actually on another spindle/drive altogether? If it's on the
same one then it offers no advantage, in terms of head seeks.
Discussed in that thread.
> * My users have a quota on /var/mail.
> * Assume a user is at his limit then check email.
> * /var/mail/user is moved to /var/spool/poptemp/.user.pop by qpopper
> (filesytem quota on /var/mail is now zero)
> * sendmail now moves email from delivery queue into /var/mail/user
Ouch.
> * qpopper is done and attempts to move /var/spool/poptemp/.user.pop back to
> /var/mail/user, but can't because the new mail that is in /var/mail/user
> plus the old mail in /var/spool/poptemp/.user.pop is too much for the quota
> on /var/mail. Yes, the user is leaving mail on server (grrrr...)
> * now the user has mail data in two places and the thing just keeps getting
> worse as the user checking email will allow the file in the temp-drop to
> grow. (Now I'm thinking to myself, why didn't I put user quotas on /var?)
user quota on var sounds like a good idea.
>
> Assuming you follow that... Should I be able to fix this problem by putting
> the temp-drop in the /var/mail filesystem
Yes, that should be easy, because it is the default.
> and use the -fast-io switch?
and remember (from the same thread) that you can do it on a per user basis.
HTH,
Hugh
Date: Fri, 7 Apr 2006 12:10:54 -0400
From: Joseph S D Yao <jsdy at center dot osis dot gov>
Subject: Re: spam city...
On Fri, Apr 07, 2006 at 08:26:06AM -0400, Alan Brown wrote:
> On Thu, 6 Apr 2006, Joseph S D Yao wrote:
>
> > Greylisting MEANS that mail from your site [or any site] is temporarily
> > not accepted.
>
> Or mail claiming to be from that domain.
What I meant was that when your site [or any site] goes connect(25),
HELO, MAIL FROM, then it is temporarily not accepted. I was not
referring to real or spoofed content; it DOES NOT MATTER.
--
Joe Yao
-----------------------------------------------------------------------
This message is not an official statement of OSIS Center policies.
Date: Fri, 07 Apr 2006 20:07:13 +0300
From: Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
I have a patch for this, see here:
http://www.mail-archive.com/qpopper@lists.pensive.org/msg05281.html
and here:
http://image.ntua.gr/~sivann/test/popper-ntua.tar.gz
The patch keeps the spool lock active while the mail is in the temp. New mail
waits for the spool to unlock. I can't understand why this is not default/option.
-S
Edward Chase wrote:
> The snippet below from a previous email gives me the impression that it
> could help me with with an issue I'm having here with users quotas.
>
> My current scenario...
>
> * /var/mail holds the users mailboxes (and is it's own filesystem).
> * /var/spool/poptemp is qpopper's scratch area, I'm assuming this is the
> "temp-drop".
> * My users have a quota on /var/mail.
> * Assume a user is at his limit then check email.
> * /var/mail/user is moved to /var/spool/poptemp/.user.pop by qpopper
> (filesytem quota on /var/mail is now zero)
> * sendmail now moves email from delivery queue into /var/mail/user
> * qpopper is done and attempts to move /var/spool/poptemp/.user.pop back to
> /var/mail/user, but can't because the new mail that is in /var/mail/user
> plus the old mail in /var/spool/poptemp/.user.pop is too much for the quota
> on /var/mail. Yes, the user is leaving mail on server (grrrr...)
> * now the user has mail data in two places and the thing just keeps getting
> worse as the user checking email will allow the file in the temp-drop to
> grow. (Now I'm thinking to myself, why didn't I put user quotas on /var?)
>
> Assuming you follow that... Should I be able to fix this problem by putting
> the temp-drop in the /var/mail filesystem and use the -fast-io switch?
>
>
>
>
>
>> -----Original Message-----
>> From: Randall Gellens [mailto:randy@qualcomm.com]
>> Sent: Thursday, March 09, 2006 3:13 PM
>> To: Hugh Sasse; Gregory Hicks
>> Cc: qpopper@lists.pensive.org
>> Subject: Re: Large spool mboxes => slow?
>
> [snip]
>
>> You might also want to think about using the fast-io option, which
>> renames the temp-drop to the spool instead of copying it. This only
>> works if the temp drop and spool are on the same filesystem.
>
> [snip]
>
Date: Fri, 7 Apr 2006 11:39:37 -0700
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
At 8:07 PM +0300 4/7/06, Spiros Ioannou wrote:
> The patch keeps the spool lock active while the mail is in the
> temp. New mail waits for the spool to unlock. I can't understand
> why this is not default/option.
If people find this useful, I'd be happy to make the option available
in the standard distribution, but I disagree with it being on by
default. Keeping the spool locked for extended periods can interfere
with mail delivery.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
There are two ways of constructing a software design: One way
is to make is so simple that there are obviously no
deficiencies, and the other way is to make it so complicated
that there are no obvious deficiencies." --C. A. R. Hoare
Date: Fri, 7 Apr 2006 11:37:20 -0700
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
At 11:52 AM -0400 4/7/06, Edward Chase wrote:
> The snippet below from a previous email gives me the impression that it
> could help me with with an issue I'm having here with users quotas.
>
> My current scenario...
>
> * /var/mail holds the users mailboxes (and is it's own filesystem).
> * /var/spool/poptemp is qpopper's scratch area, I'm assuming this is the
> "temp-drop".
> * My users have a quota on /var/mail.
> * Assume a user is at his limit then check email.
> * /var/mail/user is moved to /var/spool/poptemp/.user.pop by qpopper
> (filesytem quota on /var/mail is now zero)
> * sendmail now moves email from delivery queue into /var/mail/user
> * qpopper is done and attempts to move /var/spool/poptemp/.user.pop back to
> /var/mail/user, but can't because the new mail that is in /var/mail/user
> plus the old mail in /var/spool/poptemp/.user.pop is too much for the quota
This is the classic problem with using filesystem quotas to enforce
mailbox size limits. It's been discussed on the lists for years,
because there is no really good solution. Personally, I think it is
better to enforce mailbox size limits using another mechanism, such
as scripts that run periodically and can use whatever enforcement
methods are desired, such as sending warning mail to the user,
disabling the account from receiving mail, etc.
> Should I be able to fix this problem by putting
> the temp-drop in the /var/mail filesystem and use the -fast-io switch?
No, because fast-update only uses rename() instead of copying at the
end of the session. And it can only do that if the no new mail
arrived during the session.
By the way, the option is 'fast-update' not 'fast-io' -- I used the
wrong name in an earlier email. Sorry for misleading you.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
For best results, be sure to double clutch when you paradigm shift.
Date: Fri, 07 Apr 2006 23:23:04 +0300
From: Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Randall Gellens wrote:
> If people find this useful, I'd be happy to make the option available in
> the standard distribution, but I disagree with it being on by default.
> Keeping the spool locked for extended periods can interfere with mail
> delivery.
I have it running for some years now (with sendmail) in high traffic with no
problems.
When the local mailer sees the locked spool, it should return with an lmtp
error, and keep the mail in queue.
I believe that the only relevant sendmail timeout settings are
confTO_QUEUERETURN (The timeout before a message is returned as
undeliverable, default=5days) and confTO_QUEUEWARN (default=4hours).
-S
Date: Fri, 7 Apr 2006 11:46:58 -1000
From: Clifton Royston <cliftonr at lava dot net>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
On Fri, Apr 07, 2006 at 08:07:13PM +0300, Spiros Ioannou wrote:
> The patch keeps the spool lock active while the mail is in the temp. New
> mail waits for the spool to unlock. I can't understand why this is not
> default/option.
Because if a user is constantly checking mail, the end result could
be that mail backs up in the MTA's queue, and/or that mail to their
account starts bouncing. (The exact behavior will be highly
MTA-dependent.)
-- Clifton
--
Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net
President - I and I Computing * http://www.iandicomputing.com/
Custom programming, network design, systems and network consulting services
Date: Sat, 08 Apr 2006 12:37:01 +0300
From: Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
Clifton Royston wrote:
> On Fri, Apr 07, 2006 at 08:07:13PM +0300, Spiros Ioannou wrote:
>> The patch keeps the spool lock active while the mail is in the temp. New
> Because if a user is constantly checking mail, the end result could
> be that mail backs up in the MTA's queue, and/or that mail to their
> account starts bouncing. (The exact behavior will be highly
> MTA-dependent.)
> -- Clifton
Having a large queue is much preferable than having corrupt mailboxes
due to hard quotas and having to delete mail by hand for the users from
their tempdrop.
As for the mail bouncing, if a system has some bad MTA/LDA, a lot of
mail would bounce anyway, since the spool gets locked anyway with the
current implementation (for less time though). The mail should stay on
queue.
-Spiros
--
Image Video & Multimedia Systems Lab.
Department of Electrical & Computer Eng.
National Technical University of Athens
http://www.image.ece.ntua.gr
Date: Mon, 10 Apr 2006 13:30:27 -0700
From: Randall Gellens <randy at qualcomm dot com>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
At 12:37 PM +0300 4/8/06, Spiros Ioannou wrote:
> corrupt mailboxes due to hard quotas
How are the mailboxes getting corrupted? Qpopper should handle the
quota error by leaving the temp drop in place, not by corrupting the
mailbox. If there is a bug that causes mailboxes to get corrupted, I
want to know about it.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Demagogue: One who preaches doctrines he knows to be untrue to men he
knows to be idiots. --H.L. Mencken
Date: Tue, 11 Apr 2006 15:53:07 +0300
From: Spiros Ioannou <sivann at image dot ece dot ntua dot gr>
Subject: Re: quota issues solved? (was RE: Large spool mboxes => slow?)
It is not corrupt in the unparseable sense, but the following was happening
(I quote from a previous post):
When the user starts his mail client and his spool was left at the
temp file due to overquota problem, his client re-gets all the
mail in the temp file along with the new in the spool.
But the mail in the temp file was already downloaded to the client and old
mail appears now duplicate and new mail once normal. The next time he checks,
mail is duplicated again , old-old messages exist now 3 times, old 2 times
and new just appended from spool 1 time. And so on. We assume he has "leave
messages on server".
This behaviour was observed on at least one brand of MUA (one of them being
netscape 4.x) on 2003. Your reply was that the msg-ids were the same so the
clients should download each message once, but since we changed the locking
mechanism we were no longer able to confirm this problem with modern client
versions, so it may still exist or not. I am sorry but I can't be of more
help on this.
Randall Gellens wrote:
> At 12:37 PM +0300 4/8/06, Spiros Ioannou wrote:
> How are the mailboxes getting corrupted? Qpopper should handle the
> quota error by leaving the temp drop in place, not by corrupting the
> mailbox. If there is a bug that causes mailboxes to get corrupted, I
> want to know about it.
Last updated on 11 Apr 2006 by Pensive Mailing List Admin