[edbrowse-dev] batch move and batch delete

[edbrowse-dev] batch move and batch delete

[Karl Dahlke]

If any of you are brave enough to try it:   ...
Beware, a bug might delete emails you didn't expect.
I've tested it here, but I don't have hundreds of messages to move around either.
This is from the updated users guide.

If there are 300 emails in your spam folder, there is an easy way to delete them all.
Type v to view them all, just to make sure a valid email didn't wind up here.
You don't want to delete anything good by mistake.
Then type b for batch mode, then d to delete.
Poof, they're all gone.
In the same way, you can batch move all the messages to another folder.
However, move is more useful with the from clause.
If the current message is from Fred Flintstone, type f, and edbrowse will print "from Fred Flintstone".
Then type m cartoon, and all the messages from Fred Flintstone will move to the cartoon folder.

You know what's interesting?
When my friend Erwin sends me an email, and I look at it through imap, or pop3 for that matter,
there is sender and subject and size, but no date and time.
Run at db3 and you can see why.

parseHeaderDate fails on mer., 06 juin 2018 14:52:10 +0200

Oops! That's something I never thought of.
Our routine expects English day and month, not French.
So almost all the emails in Erwin's imap will show no date/time.
I could change the routine to recognize English or French, but is there a more general approach?
Not that I can think of.
Just brute force programming.
Identify the language first, which isn't trivial, then use the days and months in that language.
I'll see if there's a way to do this that isn't totally painful.

Karl Dahlke

Re: [edbrowse-dev] batch move and batch delete

[Dominique Martinet]

(resent to the list, sorry for double-mail to Karl)

Karl Dahlke wrote on Wed, Jun 06, 2018:
> You know what's interesting?
> When my friend Erwin sends me an email, and I look at it through imap, or pop3 for that matter,
> there is sender and subject and size, but no date and time.
> Run at db3 and you can see why.
> 
> parseHeaderDate fails on mer., 06 juin 2018 14:52:10 +0200
> 
> Oops! That's something I never thought of.
> Our routine expects English day and month, not French.
> So almost all the emails in Erwin's imap will show no date/time.
> I could change the routine to recognize English or French, but is there a more general approach?
> Not that I can think of.
> Just brute force programming.
> Identify the language first, which isn't trivial, then use the days and months in that language.
> I'll see if there's a way to do this that isn't totally painful.

Hm, you might be looking at it the wrong way, I think edbrowse is the
only mail client that will localize the Date: field.

RFC4021 (Registration of Mail and MIME Header Fields) through RFC822
(ARPA INTERNET TEXT MESSAGES) (and RFC2822 (Internet Message Format),
which is probably different but says the same) both specify a strict
format for date that leaves no room for translation ; so this really
should be simpler to parse.


That being said, for this particular mail my client (mutt) gave up on
parsing Date: and fell back to printing the date when the mail was
received by the server, in the most recent (first) Received: field.

That is formatted by your mail server and will always be respectin the
format described in the RFC that we can parse.
There actually is another timestamp in the mail metadata (in mbox
format, the first line "From x  Wed May  2 00:19:29 2018" ; in maildir
format the mtime of the file itself ; it's been a while since I've last
done imap but you can request "INTERNALDATE" in FETCH commands that is
the same) ; I've always thought mutt used it, but now I just checked
it's really based on first Received: field... Not sure why, but why not?


Back to edbrowse, I'm not sure what we should do - it probably won't
hurt to implement a fallback if we fail to parse Date, but we should
also make sure we format the Date properly when we send it so that would
fix your apparent bug for the forseeable future anyway.

Leaving it up to you :)

-- 
Dominique | Asmadeus

[edbrowse-dev] batch move and batch delete

[Karl Dahlke]

It all depends on what imap hands me as part of the envelope.
The example I saw today

mer., 06 juin 2018 14:52:10 +0200

Is obviously french.
I could just blindly pass it through as text,
but the software as written tries to parse it and turn it into a timestamp for the email.
For now I may just recognize the 12 french months as well, but I may need to redesign it some day.

Karl Dahlke

Re: [edbrowse-dev] batch move and batch delete

[Dominique Martinet]

Karl Dahlke wrote on Wed, Jun 06, 2018:
> It all depends on what imap hands me as part of the envelope.
> The example I saw today
> 
> mer., 06 juin 2018 14:52:10 +0200

Yes and no, I don't normally use imap but here is what it gives on a
"FETCH ... ALL" command for one of Erwin's mail:
5 FETCH 507 all
* 507 FETCH (FLAGS (\Seen \Recent) 
INTERNALDATE "07-Jun-2018 00:57:18 +0200" 
RFC822.SIZE 2162
ENVELOPE (
 "mar., 05 juin 2018 13:38:20 +0200"
 "[edbrowse-dev] imap"
 (("Erwin" NIL "erwb19" "free.fr"))
 (("Erwin" NIL "erwb19" "free.fr"))
 (("Erwin" NIL "erwb19" "free.fr"))
 ((NIL NIL edbrowse-dev" "lists.the-brannons.com"))
 NIL NIL NIL "<20180505133820.erwb19@free.fr>"
))
5 OK Fetch completed.

So, here again there are two dates:
The "internal date" I was talking about, that is formatted by the server
The "envelope" date that comes from the From litterally.

in mbox format, this is the same as the format you have in the first
line that gives an internal date (date where the mail was dropped in
your mbox) and then the Date: field in the envelope.


So the two things I said still stand:
 - in this case the From ought to be formatted in English according to
the RFC so this is a bug in edbrowse on the send side in the first
place; I would think the first thing to fix is that.
You can check RFC4021 / RFC822 yourself if you do not trust me :)
 - I think in the cases that can still happen where we cannot parse the
date that we are given, it is more reliable to ask the server for the
internaldate (or get it from the file if it is on disk)
I think it makes sense to do like mutt and look at Received because that
is the same in all formats (imap/mbox/mailbox), rather than try to
implement specifics:
7 fetch 507 (BODY[HEADER.FIELDS (RECEIVED)])
* 507 FETCH (BODY[HEADER.FIELDS (RECEIVED)] {994}
Received: by nautica.notk.org (Postfix, from userid 108)
	id 4F67EC01A; Tue,  5 Jun 2018 13:38:28 +0200 (CEST)
...
)
7 OK Fetch completed.


As you can see, it's not the same time, but this only happens for "bad"
clients and it sounds a lot better to me than trying to learn all
possible languages... :D

-- 
Dominque | Asmadeus