> > > > > Is this really a big enough problem to be worth solving? I can't > > > > > recall a single instance where I received IETF list with a problematic > > > > > attachment. > > > > i travel to places with very poor bandwidth. it is a problem. > > > > and the vast majority of users just do not get it. "we send 20mb > > > > documents around the office all the time. suck it up." > > > for who has problem in attachment downloading the solution should be > > > at the delivery Message Store level, where the strip of the attachment could be > > > done accordingly to an user configurable mailbox parameter > > > (as we do on our server, where we call it Easy Delivery). > > Or better still, don't strip anything. Use a reasonably capable client and > > that doesn't fetch attachments unless you tell it to. > Yes, I agree, but we can leave the end user to choose accordingly their own > no capable/capable clients or maybe accordingly to temporary condition. You can as long as attachments remain as attachments, which will no longer be true if this proposal is implemented. If they don't the "strip attachments" approach no longer works. You either (a) Only strip attachments, which leaves you with large messages to deal with, (b) Strip by part size, which will leave you with empty message, or (c) Cut parts down to a given size, which is guaranteed to work poorly. The two list approach, if secondary list proves popaular, may lead to the same result, BTW. As I commented previously in a private email, it never ceases to amaze me how people in this community only apply the "route around problems" mantra when it suits their purpose to do so. Ned