headers
Dallman Ross | 4 Jan 2006 12:26

Re: adding an Expires: header...

On Tue, Jan 03, 2006 at 11:11:16PM -0800, Don Russell wrote:

> It works fine, but my question is: is there a better way?

> 
> :0
> * ^From:.*notifier <at> fbo\.gov
> {
>    EXPIRE = `date --utc -R --date="+7 days"`
>    :0 wfc
>    | formail -I "Expires: $EXPIRE"
> 
>    :0 :
>    MailingLists/fbo
> }

Except for what seems to me to be an extraneous c-flag on your
nested recipe, it looks okay to me at a quick glance.  (You don't
need to copy a message in order to filter it with the f-flag.)  You
could add the h-flag to the first nested recipe, since formail is
only writing to the header.

If you define EXPIRE earlier on, you could remove the
nested recipe.  The trade-off is, you'd now be using up
env space, and, worse, running date, on every single message.
Hmm.  How about:

  :0 fw h
  * ^From:.*notifier <at> fbo\.gov
  | formail -I "Expires: `date --utc -R --date='+7 days'`"
(Continue reading)

Permalink | Reply |
headers
Google Kreme | 5 Jan 2006 16:59
Picon

Re: adding an Expires: header...

On 04 Jan 2006, at 04:26 , Dallman Ross wrote:

> On Tue, Jan 03, 2006 at 11:11:16PM -0800, Don Russell wrote:
>
>> It works fine, but my question is: is there a better way?
>
>>
>> :0
>> * ^From:.*notifier <at> fbo\.gov
>> {
>>    EXPIRE = `date --utc -R --date="+7 days"`
>>    :0 wfc
>>    | formail -I "Expires: $EXPIRE"
>>
>>    :0 :
>>    MailingLists/fbo
>> }
>
> Except for what seems to me to be an extraneous c-flag on your

I would simply add that X-Expires: or X-<user>-Expires: would be a  
better choice for an added header.

--

-- 
and I swear it happened just like this: / a sigh, a cry, a hungry  
kiss / the Gates of Love they budged an inch / I can't say much has  
happened since / but CLOSING TIME
Permalink | Reply |
headers
Don Russell | 7 Jan 2006 08:21

Re: adding an Expires: header...

Google Kreme wrote:

>I would simply add that X-Expires: or X-<user>-Expires: would be a  
>better choice for an added header.
>  
>
When I first started this, I added X-Expires:, then one day, while 
researching something unrelated I found an rfc that defined Expires: ... 
now of course I cant find that rfc again. :-(

But, why would you use X-<user>-Expires: ? I don't see an advantage of 
including the user id in the header...

Thanks,
Don
Permalink | Reply |
headers
Don Russell | 12 Jan 2006 20:39

Re: adding an Expires: header...

Don Russell wrote:

>[snip]
> 
>When I first started this, I added X-Expires:, then one day, while 
>researching something unrelated I found an rfc that defined Expires: ... 
>now of course I cant find that rfc again. :-(
>  
>
Well... I found it... RFC2156 ( http://www.faqs.org/rfcs/rfc2156.html )

Perhaps I misinterpreted what the RFC was trying to tell me... looking 
more closely at the RFC now, I see it's relating X.400 mail to RFC822 mail.
The RFC says an Expires: header may be present in an X.400 message that 
passed through a gateway to an RFC822 mail client.. (Section 2.2.2)

So... this lead me to thinking, "Why not add the same header with my 
procmail recipes, even if the message did NOT originate in an X.400 
environment? (Who cares where the message originated? It's on my system 
now, and I can programmatically predict when I no longer want it.)

I don't SEND Expires: header in any outgoing mail, I just add the header 
to INCOMING mail that meets certain criteria (news alerts, that sort of 
thing).

Of course, I don't have anything yet that actually DELETES the expired 
items... but at least the headers are there if/when I develop/find 
something... :-)

But, I also prefer to adhere to standards wherever possible...
(Continue reading)

Permalink | Reply |
headers
Michelle Konzack | 19 Jan 2006 11:28
Picon
Favicon

Re: adding an Expires: header...

Am 2006-01-12 11:39:16, schrieb Don Russell:

> Well... I found it... RFC2156 ( http://www.faqs.org/rfcs/rfc2156.html )

:-)

> So... this lead me to thinking, "Why not add the same header with my 
> procmail recipes, even if the message did NOT originate in an X.400 
> environment? (Who cares where the message originated? It's on my system 
> now, and I can programmatically predict when I no longer want it.)

I do the same, but use a realy unique Header like suggested
(X-$USER-Expires:) because I wo not want to run into trouble,
if someone sends an Expires: header.

Because I am using Maildir, it is realy easy to grep each hour all
messages and look to the Expiration Header to delete the message.

> Of course, I don't have anything yet that actually DELETES the expired 
> items... but at least the headers are there if/when I develop/find 
> something... :-)

;-)

> But, I also prefer to adhere to standards wherever possible...

You should use a REALY unique Expires: header for internal use.

> Don
(Continue reading)

Permalink | Reply |
headers
Google Kreme | 9 Jan 2006 16:25
Picon

Re: adding an Expires: header...

On 07 Jan 2006, at 00:21 , Don Russell wrote:
> Google Kreme wrote:
>
>> I would simply add that X-Expires: or X-<user>-Expires: would be a
>> better choice for an added header.
>>
>>
> When I first started this, I added X-Expires:, then one day, while
> researching something unrelated I found an rfc that defined  
> Expires: ...
> now of course I cant find that rfc again. :-(

Ah... I think Expires: is a header for USENET postings, not email,  
but I could be wrong.

> But, why would you use X-<user>-Expires: ? I don't see an advantage of
> including the user id in the header...

It is often useful to know where a message header was added.  using a  
user name or a domain name eliminates the possibility of colliding  
with someone else's header.

--

-- 
"He sees the good in every one.  No one would ever take him for a  
clergyman."
Permalink | Reply |
headers
Don Russell | 4 Jan 2006 22:48

Re: adding an Expires: header...

On 1/4/2006 3:26 AM, Dallman Ross wrote:

[snip]

> Well, that saves one nested recipe, but addes back
> in ugliness wrt the $EXPIRE thing's disappearance,
> and also eliminates the easier self-documentational
> appearance of the second nested recipe rather than the
> A-flag.  A nested brace-set is not expensive, so I'd
> go back to something very close to what you already have.
> I'd simply eliminate the c-flag and add the h-flag.

OK... Thanks, I appreciate your comments and suggestions.

Don
Permalink | Reply |

Gmane