On Mon 2019-09-16 22:27:49 -0300, David Bremner wrote: > Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: >> If this is the case, and your server lies, and getmail is just confused, >> perhaps we need to report a bug to getmail. > >> b) i can make imap-dl avoid this checking based on option in the config >> file (options.ignore_size_mismatch). This makes the config file >> diverge a bit from getmail, but it looks like getmail is happy to >> ignore the extra config var. > >> >> I'm leaning toward (b) -- would you be willing to set that flag in your >> config file? > > I guess so, since it approximates what getmail is apparently doing
ok, in v2 of this patch, imap-dl will accept options.on_size_mismatch,
which can be either "exception" or "warn" or "none".
If you could set it to "warn" and try it out again, and show me the
statistics it produces, i'd be interested in seeing it.
>> But if the server lies about message size, then i don't really know how
>> to calculate tranche size realistically. I suppose if the user has
>> specified ignore_size_mismatch, we can do whatever we want for tranche
>> sizes, but that makes me kind of sad. If i had this tranching mechanism
>> in place, what would you want imap-dl to do when talking to such a lying
>> server?
>
> I dunno, but given the server is microsoft's, I doubt I'm going to be the
> only one.
i'm sure you won't be :( I seem to be running into all kinds of
non-standard e-mail implementations from microsoft these days! ah well,
anyway, i don't have the tranching code ready yet so it's a bit
premature to worry about that i guess.
If you could let me (and the bug report) know whether imap-dl v2 works
for you, that'd be great.
Thanks for bearing with me, and reporting what you're seeing from o365.
--dkg
signature.asc
Description: PGP signature
