Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:
> Thanks for this, David.
>
> On Mon 2019-09-16 10:04:10 -0300, David Bremner wrote:
>> It looks like every message; see attached log. I haven't had a chance to
>> try the patched imap-dl
>
> It looks lke your server is indeed lying about the message size in the
> initial summary.
>
> It clearly says 41997 octets here:
>
>> command FETCH ('1:1', '(UID RFC822.SIZE)') response ['1 (UID 94515
>> RFC822.SIZE 41997)']
>> _parse_imapattrresponse() [_retrieverbases.py:1334] parsing attributes
>> response line 1 (UID 94515 RFC822.SIZE 41997)
>> _parse_imapattrresponse() [_retrieverbases.py:1357] got {'rfc822.size':
>> '41997', 'uid': '94515'}
>
> and then when you go to retrieve it, it gives you only 6294 octets:
>
>
> Can you verify the size of the actual message as delivered?
>
> stat "$(notmuch search --output=files id:87sgowo0w8....@tethera.net)"
It's not either, but 6376 with is closer . I can imagine the difference is
headers added
by getmail.
>
> 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
>
> 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.
d
