Re: Maildrop delivery issue

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--===============8449991694164501488==
Content-Type: multipart/signed;
    boundary="=_ripper.email-scan.com-424537-1783635867-0001";
    micalg=pgp-sha1; protocol="application/pgp-signature"
Content-Transfer-Encoding: 8bit

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_ripper.email-scan.com-424537-1783635867-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Bernd Wurst writes:

> Hi Sam.
>
> Am 09.07.26 um 13:34 schrieb Sam Varshavchik:
>> Looking over the code I think I have a pretty good guess what's going on.  
>> Those particular messages must have broken MIME formatting, spam probably.  
>> They must be multipart MIME entities with junk after the closing MIME  
>> boundry delimiter, and maildrop ignores the extra junk when it figures out  
>> the filename.
>
> Thank you for investigating!
> Yes, the ones I looked up manually were all spam.
>
>
>> What surprises me is that anything other than Courier code is reading it,  
>> especially an IMAP server. It makes no sense, an IMAP server cannot use  
>> this, even if it was correct.
>
> I don't expect dovecot to dig that deep. Most likely it does just compare S=  
> value to stat value before even opening the file...
>
> I don't want to argue about Maildir++ format with the inventor but I'm a bit  
> irritated. The specs say "append ,S=nnnnn to the name of the file, where  
> nnnnn is the size of the file."
> If there is garbage (in terms of MIME) at the end, then you can count (and  
> write) it or not but it doesn't really make sense to write and not count it.

Oh, yes, this was wrong, and it's getting fixed. But my point is that the  
IMAP server has no use for this, whatsoever. I just have no idea why it  
cared.

The original reason was to simply have the POP3 server avoid the need to  
stat() each file when the client sent a STAT. POP3 does not require this to  
match the actual downloaded size, it's for informational purposes and this  
was a very useful optimization. Later this was also used for quota  
calculations, for the same reasons.

But that's about it, this has no practical use and I was just wondering what  
it could possibly need it for.

> I just found out that dovecot has a compatibility setting to ignore the size  
> from the file name. In the help text of the option  
> maildir_broken_filename_sizes one can read that dovecot compares the  
> *physical* size to the S= value. I'd understand that as byte length of the  
> whole file.

So this, apparently, is not even needed for any practical need. If Dovecot  
actually uses it in some way, such as actually pulling it into the  
BODYSTRUCTURE response, then I have to be the bearer of bad news: the ghost  
of MrC (RIP) will haunt Dovecot forever.

--=_ripper.email-scan.com-424537-1783635867-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCalAfmwAKCRCKYPgoojZS
4s9iAP44jMm8bnAEHPGULPcEtCIT9FX1LQGia0f4kz/UvWjUVwEAwuPTOXUE8Efc
z8Bz6N/68bmDKrk1zisbfZctQv3QUQg=
=itCI
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-424537-1783635867-0001--


--===============8449991694164501488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============8449991694164501488==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

--===============8449991694164501488==--