I'm doing some work with the OMA in the area of spam reporting. They have
developed an XML message format for reporting spam from a mobile handset.
Because SMS and MMS (and even IM) have different structure than email, they
went with something more extensible than what we currently do with DSNs. I'm
helping that group try to converge with what we do in the email world,
especially with what the MARF working group is producing (e.g., ARF, specified
by recently-published RFC5965). The first thing is to register the MIME type
they've created, and so I've crafted a template for that.
The next thing we'd like to achieve is to be able to specify multiple spam
reports in a single message, regardless of transport (they currently use HTTP
POST, but there's no reason SMTP couldn't be used). The most obvious thing to
do would be to use a multipart/mixed MIME message, and then include their MIME
type in each of "n" parts. However, this is different than what was done with
ARF, which used multipart/report. The advantage to using multipart/report,
which stipulates that it must be the outermost MIME type, is that you know
right away that you're processing a report rather than having to parse part
way
into the MIME tree to figure that out.
IMO this has always been a silly requirement because it imposes a condition
that in practice cannot possible be met. And as usual, it all boils down to
people having an idealized view of how email works and failing to take real
world conditions into account. (I did point this out at the time this was
written, but got no support and I was also the NOTARY chair, and as such my
main concern was getting the thing done, not worrying about this sort of
detail.)
While it is true that you can impose such a rule on agents sending out such
parts, you cannot possibly hope to have such a rule respected by intermediate
processors. So when, say, someone forwards a report they got to someone else
for analysis - guess what? The multipart/report ends up inside a message/rfc822
or whatever. Ditto for inclusion in multipart/digest objects.
As for the ease of processing business, you'd think that by now we'd have
learned not to do this sort of thing. The painful reality is that when it comes
to encouraging user agents to go the extra mile and do stuff like handle
reports properly, or handle alternatives properly, etc. etc., concessions to
simplicity have not helped in the slightest. User agent authors implement the
stuff they think is useful - even when it is difficult - and ignore the rest.
And for whatever reason support for processing multipart/report has not been
seen as useful, so there are very few implementations that do it. (I know of
only two, one of which I wrote and for which, BTW, the outermost part
rule didn't make things any simpler.)
(According to Tony Hansen, that's why this rule was put in place.)
RFC 3462 specifically states that this is the case.
But although multipart/report is the most obvious construct for doing this,
it doesn't lend itself to multi-report messages. So to get these to converge,
we have to be a little creative or be very creative (in the "create a lot of
documents" sense).
We could do a message/digest, each sub-part of which is message/rfc822 and
the MIME type within that is multipart/report. One could argue that this
approach conforms to the multipart/report rules by having that be the
outermost
MIME part of each constituent message in the aggregate message, but that might
be hard to defend given the spirit of that rule.
Won't fly. Again, RFC 3462 is quite specific about the purpose of the rule is
so reports can be detected by looking at the RFC 822 header. Such a purpose is
totally defeated by embedding the message inside additional MIME content.
No, if you want to get rid of this rule, you need to bite the bullet and
revise/update RFC 3462 to get rid of it. And I don't think this is that big of
a deal - this is very small beer compared to changing the no nested parts rule
in MIME, which EAI does.
There's also a stipulation that the MIME subtype of the second part in a
multipart/report message must be equal to the report-type of the outermost
part, with no other constraints. Thus to keep multipart/report at the
outermost MIME but allow multi-message reports, we could comply by using
"multipart/report; report-type=mixed" as the outermost MIME type and then use
"multipart/mixed" inside. But this also sure feels hack-ish.
I don't believe that works either, because in addition to the restriction you
note RFC 3462 requires that the content of a multipart/report be a specific
structure containing two or three parts with specific semantics. In fact I'd
say that relaxing this rule is likely to cause far more interop problems - for
example, my report processing code can handle reports not at the outermost
level, but would refuse to process what you're proposing here.
So what would be more palatable to this community? Could multipart/report be
updated to accommodate this use case? Should we register
multipart/multi-report that relaxes some of the existing restrictions without
changing the existing media type?
This would be the simplest thing to do that doesn't change anything else, but
I would prefer to get rid of the silly rule in RFC 3462.
Ned