Re: [Evolution] attachments issue

Am Donnerstag, den 16.05.2013, 17:28 -0430 schrieb Patrick O'Callaghan: 
On Thu, 2013-05-16 at 22:48 +0200, Thomas Prost wrote:
Am Donnerstag, den 16.05.2013, 13:13 -0430 schrieb Patrick O'Callaghan: 
On Thu, 2013-05-16 at 09:52 -0400, Adam Tauno Williams wrote:
On Thu, 2013-05-16 at 10:30 +0100, Pete Biggs wrote:
 the .pdf source is indeed  there (and the mail file is huge)  
Define huge.  1Mb? 5Mb? 100Mb? 10Gb?
around 15Mb 
Personally I wouldn't trust any mail system with that size of

Personally I, and 600+ other users here, deal with attachments
times that size every day all day with no issues what-so-ever.  

This is not 1991.

According to my notes I increased the maximum message size at my site
from 20Mb to 75Mb in 2003... with no measurable increase in issues.

I seem to remember a recent thread on just this topic. To recap what I
said then: your mail system may be happy with large attachments, but you
can't assume that every relay in the path to any random destination is
equally happy.

Why should they care ? Your mail doesn't come there at a stretch anyway.
Or does packet switching need a lull from time to time ;-)

Think again. "Relay" does not mean "packet switch". It means an

Sorry POC, I was thinking of those "random destinations" mentioned - and
if in any way senseful, these are packet switches ...

intermediate host which stores and forwards complete email messages.
Take a look at the headers of some message to see the relays it passes
through before getting to you. For example at a quick glance your
message passed through: (probably your own machine) (your local mail server?) (some intermediate relay)
That's all my carrier, whose policy I know ... (presumably where the evolution-list is stored)
That's no random destination - it's the final destination.

and thence via IMAP to my machine.

Each of these is administered independently and has its own idea of how
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That wouldn't make any
sense, looking at modern structures ...
Thomas Prost <thomas prost prosts info>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]