Hi Michael,
> I find myself making todo notes for emails that I need to send after
> Jan. 1.
...
> I was thinking whether it was worth having some mechanism where I
> would write an email, get it all ready to send (including GPG signing
> it in mh-e), but keep in a numbered/dated draft directory a
Ralph Corderoy wrote:
>> I find myself making todo notes for emails that I need to send after
>> Jan. 1.
> ...
>> I was thinking whether it was worth having some mechanism where I
>> would write an email, get it all ready to send (including GPG signing
>> it in mh-e), but
>I occasionally do this by combing at(1) with mhmail(1) or send(1). MH
>is designed to integrate with the Unix shell so instead of MH growing
>features, I'd initially look more at combining cron(8) with a shell
>script that sends email whose time has come. Perhaps that's detected
>by the name of
>
On Dec 26, I asked:
>Is there any way to scan all folders at once to determine which have new
>unseen messages or am I reduced to going into each folder individually
>in which case I may scrap procmail and just have everything go into
>inbox?
I would just like to thank Conrad and Robert for tak
Ken Hornstein wrote:
>> I occasionally do this by combing at(1) with mhmail(1) or send(1). MH
>> is designed to integrate with the Unix shell so instead of MH growing
>> features, I'd initially look more at combining cron(8) with a shell
>> script that sends email whose time has
David Levine writes:
>I wrote:
>
>> How about this:
>>
>> echo hello norm|mhmail -to norm\@dad.org -subject 'Fetch Errors' -snoop \
>> -profile -sasl -tls -server smtp.gmail.com
>
>Just adding -profile should be sufficient, because the other additions are
>in the send component value of yo
>One of the things I think we lack of a message-ID -> message map. We
>have discussed ways to store per-message meta-data outside of the
>message file many times, and I don't think we ever came to a conclusion
>here.
Weee ... I mean, we have the command-line INTERFACE for that, I
think; pick(
Ken Hornstein wrote:
>> One of the things I think we lack of a message-ID -> message map. We
>> have discussed ways to store per-message meta-data outside of the
>> message file many times, and I don't think we ever came to a
>> conclusion here.
> Weee ... I mean, we have