Re: Three kinds of IMAP extensions

------ Original Message ------
From: "Jayantheesh S B" <[email protected]>

>
>[Jay] I feel that having a client side prevention check is not a better 
>solution. It's not just about the mobile device's resources, here we 
>are considering the server side resources too.
>According to your input, we can even have a similar argument for ESMTP 
>SIZE extension, where clients are not allowed to exceed a certain size 
>irrespective of mobile or desktop environment.
>
>
The SMTP argument is interesting.  In my experience, the size limit on 
SMTP is a nett negative.  Due to the nature of SMTP relaying, you can 
get a bounce at any stage in a delivery path due to a local configured 
max size being set too low.

For our mail, we don't even enforce a limit on incoming from untrusted 
sources except for a very few addresses which are processed by other 
systems which do have (unfortunately) limits.  Bouncing large mails only 
ever causes us (and our customers) pain and denies legitimate mail 
causing everyone extra work.  Spam just isn't that big.

Our real limits are set only by the amount of free disk space.  We don't 
care if people use their quota in 1 message or 1M.

And in IMAP it's an even narrower case. You're dealing with 
authenticated clients only, these are people with whom there is a 
pre-existing relationship.

Also the protocol itself limits message size to 32bits.  4GB is getting 
smaller all the time.

Last time I raised that particular issue the only response I got was 
that people shouldn't send such large mails, but that train is still 
approaching us stuck in our tunnel. Our server actually uses 64bit 
unsigned and generates numeric strings accordingly, client authors would 
be well advised to make the move to 64 bit sooner rather than later.


Adrien

>

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext