Re: Mail Path MTU discovery?

Hadmut Danisch <[email protected]> Fri, 13 Feb 2004 20:50:01 +0100
Newsgroups gmane.mail.ng
Message-ID <[email protected]>
On Fri, Feb 13, 2004 at 08:38:18PM +0100, Iljitsch van Beijnum wrote:
> On 13-feb-04, at 18:56, Hadmut Danisch wrote:
>
> >Example: Before sending the 5 GByte E-Mail, a short control
> >message could be sent to the recipient, where every relay
> >can reduce the maximum Mail size. Then the message is sent back.
> >This would of course not be a guarantee, since the path can
> >change every second. But it's at least a hint and could avoid
> >the 5 GByte to be sent just for generating an error message.
> 
> This makes sense, but I think we can go a little further and see 
> whether it's necessary to push large messages and especially files out 
> to the recipient's inbox anyway, why not just send a light-weight 
> message indiciating the availability of the "real" message or the file 
> in question, and then the receiver can connect to the place where the 
> message/file is stored and then the file is transmitted to the place 
> where it needs to be directly. Additionaly, we can add an optional 
> proxy layer here, allowing for extremely efficient distribution of 
> binary information through mailinglists.
> 
> So a software maker could send out a message with attached a file that 
> contains a large update to all their customers. The customers all 
> receive the message and then proceed to download the file, if they want 
> to have it, through their ISP's proxy. This


Hey, that's a good point. I often asked several friends to 
not send monster files and jam my mailbox, but to put them on a
webserver and just sent the link.

So we should support push and pull attachments. Instead of an 
attachment a URL and a cookie is included which allows to pull
an attachment which is to be deleted after downloading. 

I think that's a good requirement.

BTW: If we are talking about large messages or attachments: 

Should we require every implementation to use 64bit integers
to avoid inherent size limits of 4 GB (or 2 GB with signed 
integers)?

Or should we have a hard size limit? When you transmit 
4 GB, and the last byte fails, you need to transmit it again.
Should we simply disallow 4GB transfers and enforce pulling
attachments?

Or should we support incremental transport? Just open another
connection and transmit just the last 1kb instead of transmitting
the 4 GB again?

regards
Hadmut