Subject: [ietf-822] message/partial - is it still a thing?

From: [email-masked]
Date: Wed, 20 Feb 2019 23:03:20 -0500

Does any software out there still do message/partial?  We've discovered
that both the line-mode nmh package and the exmh GUI claim support
but are in fact broken.

Is anything else out there able to do it, or is it time to heave it over the side?

(Probably need to double-check 'external-body' support too, but that's a different
kettle of fish...)

And if it's time to heave it over the side, should an RFC deprecating or moving
it to 'Historic' be done?

---

From: Paul Smith <[email-masked]>
Date: Thu, 21 Feb 2019 09:21:27 +0000

> Is anything else out there able to do it, or is it time to heave it over the side?

Personally, I suspect that it's time to throw it away. I know a lot of 
people block it because it can be used to bypass filtering.

On our server software it's been blocked by default for over a decade, 
and we've not had a single complaint that legitimate messages have been 
blocked because of it.

-- 

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 21 Feb 2019 13:42:02 +0100

On Thu 21/Feb/2019 05:03:20 +0100 valdis kletnieks wrote:

> Does any software out there still do message/partial?

Possibly UUdeview, according to its log:
http://www.fpx.de/fp/Software/UUDeview/HISTORY.txt

That file stops in 2004.

Best
Ale
--

---

From: Ned Freed <[email-masked]>
Date: Thu, 21 Feb 2019 09:10:43 -0800 (PST)

> Does any software out there still do message/partial?

We do. We support both creation and reassembly. Both are disabled by default.

>  We've discovered

That's what test suites are for...

> Is anything else out there able to do it, or is it time to heave it over the

It was never intended to be something that everyone does on a routine basis.
message/partial is a solution for a particular set of connectivity problems.

> (Probably need to double-check 'external-body' support too, but that's a different

Well, since every text/html part is an external-body on steroids...

> it to 'Historic' be done?

Media types don't have the same statuses as RFCs, so there's no such thing as a
"historic" media type. The most you could do is changed the intended use to
"limited" or "obsolete". I don't really object to writing an RFC that does
that, but given how often I've heard someone mention the intended use of a
media type (that would be never), I question the value.

				Ned

---

From: Russ Allbery <[email-masked]>
Date: Thu, 21 Feb 2019 10:01:49 -0800

[email-masked] writes:

> that both the line-mode nmh package and the exmh GUI claim support but
> are in fact broken.

> Is anything else out there able to do it, or is it time to heave it over

Gnus supports both sending and decoding it, and will automatically send
messages as message/partial if the size of the message is above a
configurable threshold.  I've personally disabled that, though, since I've
never had a recipient be able to deal with a message/partial message I
sent them.

-- 
Russ Allbery ([email-masked])              <http://www.eyrie.org/~eagle/>

---

From: Lyndon Nerenberg <[email-masked]>
Date: Thu, 21 Feb 2019 14:15:56 -0800

> We do. We support both creation and reassembly. Both are disabled by default.

I have code that supports both.  It's really intended for private
use cases where I'm dealing with slow unreliable links, so this
provides a form of "chunking" over email.

> > that both the line-mode nmh package and the exmh GUI claim support

Valdis, can you contact me offline with specifics?

I'm not sure the media type needs to be tossed overboard.  If you
don't generate it, it doesn't matter to you.  And if you don't deal
with it inbound, you just treat it like every other media type you
cannot handle (report and ignore it).

--lyndon

---

From: [email-masked]
Date: Thu, 21 Feb 2019 17:36:05 -0500

> Valdis, can you contact me offline with specifics?

For nmh, the issue was that the 'post' program that actually posts a mail object
to an MSA was changed to require a From: line in the headers (rather than
try to auto-create one), and the 'send' that invokes post would  
only generate a From: line for the first chunk.  Turns out that 'post' was
changed in 2012, and somebody finally noticed this week.

For exmh, the problem is that (a) it doesn't even bother trying to send
a message/partial, and (b) it will re-assemble the parts in the order they
arrived in a folder, so if the first file in the folder is part 1, the second is
part 4, the third is part 2, the fourth is part 3, and then the fifth is part 5,
it will re-combine them in order 1 4 2 3 5, not 1 2 3 4 5.

---

From: Richard Clayton <[email-masked]>
Date: Fri, 22 Feb 2019 01:04:06 +0000

In message <[email-masked]>,
[email-masked] writes

>Does any software out there still do message/partial?

mine does this just fine ... It's called Turnpike, but it's no longer
made available to new users -- it does both generating and reassembly on
receipt

>Is anything else out there able to do it, or is it time to heave it over the 

it was never widely possible to interwork with it and these days people
mail around multi-megabyte presentations without much difficulty (above
20MB you just don't reliably use email any more)

>(Probably need to double-check 'external-body' support too, but that's a 

Turnpike supports doing a fetch but cannot generate such emails ... the
only place I have ever seen this used is in IETF emails reporting the
issuing of RFCs or I-Ds ... and they seem to have stopped doing this
some years back

>it to 'Historic' be done?

I doubt anyone would implement either today, but making them Historic
would clarify that

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755