Re: ATTN: Barbara Oncay
On Fri, Apr 14, 2006 at 04:04:53PM -0400, Rich Johnson wrote:
>
> On Apr 14, 2006, at 3:26 PM, Steve Lamb wrote:
>
> > Point is that there is a different condition between it being there and
> >the client failing to show it. How? Because if it wasn't there NO* client
> >would show it. Just because one, or a few, clients don't show it doesn't mean
> >all don't show it. It's called being precise in reporting problems.
> >
> >--
> > Steve C. Lamb | I'm your priest, I'm your shrink,
> >I'm your
> > PGP Key: 8B6E99C5 | main connection to the switchboard
> >of souls.
> >-------------------------------
> >+---------------------------------------------
> I'm using a different reader altogether and I sometimes see the
> unsubscribe annotation and sometimes I don't.
> The difference correlates perfectly with whether the message is
> multipart mime(rfc1341), or not.--it does not appear whenever the
> sender mails a multi-part message. For example you _WON'T_ see it
> with Steve's messages as illustrated above; you _WILL_ see it with
> this message (I hope).
>
> Taking a brief look at the specs, but not enough to grok them:
> I suspect that the problem is that the notice is tacked on _after_
> the attachments---essentially turning the notice into an "epilog''
> <i> without a content-type</i> rather than either:
> (a) placing it within the first text part; or
> (b) attaching it as a well-formed part.
>
> Since it's an ill-formed part, it's properly ignored.
Good analysis! rfc2046 seems to supersede 1341, but says the
same thing wrt epilog(ue) parts, including:
The boundary delimiter line following the last body part ...
indicates that no further body parts will follow. ...
Presumably clients that do show the unsub sig are not RFC compliant,
and the ones that are "failing to show it" are compliant.
> Bottom line: I suspect the problem lies with the mechanism used to
> append the message.
Makes sense to me.
--
Ken Irving
Reply to: