headers
John C Klensin | 5 May 2012 17:04

Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)

Hi.

I've been trying to watch the discussion, rather than
participating in it, in the hope that I could instead summarize
conclusions and get us moving forward.   Note that the comments
and conclusions below are my summaries and extrapolations from
what has been said on the list and are tentative: if anyone
disagrees in any substantive way, speak up.  Circa 50 messages
in the last couple of weeks later...

(1) I infer that we have general agreement on the basic EAI IMAP
and POP specs.   If we do not, people had better speak up
quickly.  We will review those documents quickly on the interim
meeting Jabber chat, but, in the absence of significant issues
then, I assume that the WG thinks the drafts are ready to go to
the IESG and will start doing my final WG Chair
(pre-Shepherd-writeup) check.

(2) A separate note will follow about the other downgrade spec
(draft-ietf-eai-popimap-downgrade).

(3) Re the Simple Downgrade draft, I believe that, with the
possible exception of one or two people or issues in the rough,
the WG has concluded:

(3.1) The Security Considerations should mention issues that are
specific to receiver-end downgrading and to this spec.  John
Levine's request to include a DKIM pointer along with "signed
body parts" falls into that category, but note that there is
already text suggesting that the implementer better be really
(Continue reading)

Permalink | Reply |
headers
John Levine | 5 May 2012 21:43

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)

> That is ultimately the argument in favor of popimap-downgrade over
> simpledowngrade: if it is worth going to the trouble of downgrading
> at all, one might as well exert the extra effort to do it
> comprehensively.

That's the argument, but it's one that I don't find at all persuasive.

If a user has a non-EAI MUA, the most a downgrade can realistically do
to create something the MUA can display is what simpledowngrade
describes.  Anything beyond that is a quality of implementation issue
that has nothing to do with interoperability.  As soon as you rewrite
anything, signatures break, heuristics that look for patterns in the
header lines don't work any more, and it's just a losing battle to try
to make it look like a real non-EAI message.

If a message's headers contain EAI addresses, there's no no way a
non-EAI MUA can respond to them directly, so there's nothing to
standardize with addresses beyond ensuring that one can't reply to
them.  I'm not aware of any MUA that would do anything useful with
Downgraded-Something headers, and I believe I am far from alone in
thinking that any work that might be invested in making a MUA use them
would be far better spent making the MUA handle native EAI.

R's,
John
Permalink | Reply |
headers
John C Klensin | 5 May 2012 23:05

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)


--On Saturday, May 05, 2012 19:43 +0000 John Levine
<johnl <at> taugh.com> wrote:

>> That is ultimately the argument in favor of popimap-downgrade
>> over simpledowngrade: if it is worth going to the trouble of
>> downgrading at all, one might as well exert the extra effort
>> to do it comprehensively.
> 
> That's the argument, but it's one that I don't find at all
> persuasive.
> 
> If a user has a non-EAI MUA, the most a downgrade can
> realistically do to create something the MUA can display is
> what simpledowngrade describes.  Anything beyond that is a
> quality of implementation issue that has nothing to do with
> interoperability.  As soon as you rewrite anything, signatures
> break, heuristics that look for patterns in the header lines
> don't work any more, and it's just a losing battle to try to
> make it look like a real non-EAI message.
>...

John (and others),

(Co-Chair hat pulled firmly over ears)

Let me be blunt, with the understanding that I agreed to take on
this WG because there seemed to be general agreement that one of
our major shared goals was to move this work forward
efficiently, much more efficiently than we have been doing
(Continue reading)

Permalink | Reply |
headers
John R Levine | 5 May 2012 23:42

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)

> Second, people who implement and deploy these things are thoroughly 
> likely to do what they think is right, regardless of what the IETF 
> predicts or thinks is good for them.

Of course.  To restate the obvious, standards tell how to write 
independent subsystems so they interoperate with each other.  Your alarm 
scenario is entirely within one system, so it presents nothing to 
standardize.

If people concretely expect to write MUAs that do something useful with 
the Downgraded-foo headers, then we might as well publish a document that 
says what those headers should contain.  But it's my impression that the 
plan is to add them just in case anyone is interested, which strikes me as 
mildly counterproductive.

R's,
John
Permalink | Reply |
headers
John C Klensin | 6 May 2012 01:36

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)


--On Saturday, May 05, 2012 17:42 -0400 John R Levine
<johnl <at> taugh.com> wrote:

>> Second, people who implement and deploy these things are
>> thoroughly  likely to do what they think is right, regardless
>> of what the IETF  predicts or thinks is good for them.
> 
> Of course.  To restate the obvious, standards tell how to
> write independent subsystems so they interoperate with each
> other.  Your alarm scenario is entirely within one system, so
> it presents nothing to standardize.

To restate the equally obvious, the thing that is important
about that scenario is that it represents a case in which no
downgrading at all is needed or likely to be useful, making both
of our downgrading specs irrelevant.

> If people concretely expect to write MUAs that do something
> useful with the Downgraded-foo headers, then we might as well
> publish a document that says what those headers should
> contain.  But it's my impression that the plan is to add them
> just in case anyone is interested, which strikes me as mildly
> counterproductive.

Kazunori Fujiwara and his colleagues can (and should) speak for
themselves, but I suspect that they already have such MUAs
implemented.  Certainly they had those MUAs when the
experimental specs specified very similar downgrading in
transit.  It would be quite easy to modify an MUA, and to move
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 6 May 2012 10:10
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)

On 05/06/2012 01:36 AM, John C Klensin wrote:
> Kazunori Fujiwara and his colleagues can (and should) speak for
> themselves, but I suspect that they already have such MUAs
> implemented.  Certainly they had those MUAs when the
> experimental specs specified very similar downgrading in
> transit.

This makes sense. A great deal of sense.

> It would be quite easy to modify an MUA, and to move
> the downgrading code from an MTA to a POP/IMAP server, if one
> had that code already. 

The conditions and O() expectations differ. In one case, the code is
expected to store and forward a single message. In the other, it's
expected to open up to around 10-20k messages, sometimes with read-only
access.

Creating Downgraded-Cc is easy if you store and forward. Less so if you
have read-only write access to the mailbox and the client expects you to
do it for 10k messages, fast. UID FETCH 1:* (RFC822.SIZE FLAGS) for
instance. Servers commonly have to do that for datasets which won't fit
in available RAM.

BTW, I don't think popimap-downgrade discusses what happens if a
mischievous sender already adds downgraded-* fields?

Arnt
Permalink | Reply |
headers
fujiwara | 7 May 2012 07:50
Picon
Favicon

Re: Status summary on SimpleDowngrade

> From: Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no>
> BTW, I don't think popimap-downgrade discusses what happens if a
> mischievous sender already adds downgraded-* fields?

"message/global" messages should not contain "Downgraded-*" header
fields.

If an message contains both non-ASCII header value and Downgraded-*
header fields, the message is broken.

A senario which show the broken case:
  - a user uses fetchmail and procmail to retreive messages from pop servers
  - and forward them to non-ASCII e-mail address.
  - where fetchmail does not know UTF8 capability

 ->  The forwarded message contains both
     - Downgraded header fields
     - non-ASCII header fields (Received, Return-Path, Delivered-To, ...)
       which came from non-ASCII RCPT TO in SMTP.

Otherwise, the broken case came from malicious entities.

--
Kazunori Fujiwara, JPRS <fujiwara <at> jprs.co.jp>
Permalink | Reply |
headers
Arnt Gulbrandsen | 7 May 2012 08:45
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade

On 05/07/2012 07:50 AM, fujiwara <at> jprs.co.jp wrote:
> If an message contains both non-ASCII header value and Downgraded-*
> header fields, the message is broken.

Yes. But what should happen?

Should the message be stripped of its wrongness at delivery time? In
that case popimap-downgrade cannot apply to mail stored before it was
deployed, or an time-consuming migration is required to deploy it.

Should the message be edited on disk when popimap-downgrade sees it? In
that case popimap-downgrade can only be deployed for mailboxes to which
the server has write access. Further, if that's done for IMAP, the
document needs to specify that the server issue a new UIDVALIDITY.

The third alternative is to keep th message in RAM and discard it at the
end of the mailbox session. But in that case even frequent and until now
cheap operations like UID FETCH 1:* RFC822.SIZE become expensive.

Arnt
Permalink | Reply |
headers
fujiwara | 7 May 2012 13:17
Picon
Favicon

Re: Status summary on SimpleDowngrade

> From: Arnt Gulbrandsen <arnt <at> gulbrandsen.priv.no>
>> If an message contains both non-ASCII header value and Downgraded-*
>> header fields, the message is broken.
> 
> Yes. But what should happen?
> 
> Should the message be stripped of its wrongness at delivery time?

It is out of scope of pop/imap.
Bogus messages are delivered to pop/imap mailboxes as is.

> In
> that case popimap-downgrade cannot apply to mail stored before it was
> deployed, or an time-consuming migration is required to deploy it.

POP server or IMAP server shuold not change messages when a client
support UTF8 capability. It is out of scope of pop/imap downgrading.

> Should the message be edited on disk when popimap-downgrade sees it?

A user may use multiple POP/IMAP clients. Some clients may support
UTF8 capability, and others may not support UTF8 capability.

Then, the POP/IMAP server must keep the messages as is.
And the server may have downgraded version additonally (as a cache).

> In
> that case popimap-downgrade can only be deployed for mailboxes to which
> the server has write access. Further, if that's done for IMAP, the
> document needs to specify that the server issue a new UIDVALIDITY.
(Continue reading)

Permalink | Reply |
headers
Alexey Melnikov | 14 May 2012 16:04
Favicon

Re: Status summary on SimpleDowngrade

On 07/05/2012 12:17, fujiwara <at> jprs.co.jp wrote:
>> From: Arnt Gulbrandsen<arnt <at> gulbrandsen.priv.no>
>>> If an message contains both non-ASCII header value and Downgraded-*
>>> header fields, the message is broken.
>> Yes. But what should happen?
>>
>> Should the message be stripped of its wrongness at delivery time?
> It is out of scope of pop/imap.
> Bogus messages are delivered to pop/imap mailboxes as is.
>
>> In
>> that case popimap-downgrade cannot apply to mail stored before it was
>> deployed, or an time-consuming migration is required to deploy it.
> POP server or IMAP server shuold not change messages when a client
> support UTF8 capability. It is out of scope of pop/imap downgrading.
>
>> Should the message be edited on disk when popimap-downgrade sees it?
> A user may use multiple POP/IMAP clients. Some clients may support
> UTF8 capability, and others may not support UTF8 capability.
>
> Then, the POP/IMAP server must keep the messages as is.
> And the server may have downgraded version additonally (as a cache).
>
>> In
>> that case popimap-downgrade can only be deployed for mailboxes to which
>> the server has write access. Further, if that's done for IMAP, the
>> document needs to specify that the server issue a new UIDVALIDITY.
> The UIDVALIDITY value should be calculated by the original message.
>
> Is the UIDVALIDITY for the original message same as the UIDVALIDITY
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 14 May 2012 17:02

Re: Status summary on SimpleDowngrade


--On Monday, May 14, 2012 15:04 +0100 Alexey Melnikov
<alexey.melnikov <at> isode.com> wrote:

> A message in IMAP is immutable (i.e. it can't change its basic
> properties, other than IMAP flags/annotations). The message is
> uniquely identified by UIDVALIDITY (per mailbox value) + its
> UID.
> So if the message changes in the IMAP mailstore, it has to get
> a new UID, or the UIDVALIDITY for the mailbox has to change.
> The latter signals clients that all of its cached messages are
> no longer available and have to be purged from the cache.

Right.  I think that, among other things that means that, if I'm
a server and I try the strategy of converting/downgrading the
message when it enters the mail store and then keeping both
versions and deciding which one to deliver based on what the
client asks for, I'd better be _really_ alert and careful about
the above.  I'm not even certain it is possible to get right, at
least while preserving UIDVALIDITY at all.

I started thinking about a slightly different, but related,
problem over the weekend having to do with what happens when a
user accesses a mail store with an EAI-compliant IMAP client, an
EAI non-compliant IMAP client, a webmail client (probably
compliant), and compliant and non-complaint POP clients that use
the notorious "leave mail on server" option and that do so in
different orders.  One can get a bad headache rather easily.  My
use of the term "variant of message" rather than "downgraded
message" in my "critical path issues" note earlier today was a
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 14 May 2012 17:10
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade

On 05/14/2012 05:02 PM, John C Klensin wrote:
> I'm not even certain it is possible to get right, at
> least while preserving UIDVALIDITY at all.

I think simpledowngrade gets it right, since it doesn't touch any
non-EAI message at all. popimap-downgrade has a bit of a problem, since
it depends on downgraded-* not being there for non-EAI input messages.

I think that perhaps the IMAP EAI document should say something like:

 A client which is updated to add UTF8=* should be aware that if it
 has cached any part of an internationalized message before
 it was extended with UTF8=* support, then that part may be
 some sort of compatibility rendering by the server. Clearing the
 cache when the upgrade is deployed may be advisable.

Arnt
Permalink | Reply |
headers
ned+ima | 14 May 2012 17:29

Re: Status summary on SimpleDowngrade

> On 05/14/2012 05:02 PM, John C Klensin wrote:
> > I'm not even certain it is possible to get right, at
> > least while preserving UIDVALIDITY at all.

> I think simpledowngrade gets it right, since it doesn't touch any
> non-EAI message at all. popimap-downgrade has a bit of a problem, since
> it depends on downgraded-* not being there for non-EAI input messages.

It's more than a problem, it's a disaster in the making.

The problem is that you cannot make *any* assumptions about the presence or
absence of downgraded-* fields. This is because they're certain to leak - 
consider the case of a non-EAI client that resends a message (an operation
that's likely to retain these headers) to an EAI client that resends the
message again, this time adding resent-* fields that contain EAI addresses.
Now you have a perfectly legitimate EAI message that contains downgraded-*
fields.

And simpledowngrade doesn't really do much better, because you now end up
with invalid addresses in the regular from and to fields.

This is why I continue to believe that all of this stuff is not only
going to generate support calls, they're going to be the sort of calls where
figuring out what happened requires real expertise.

> I think that perhaps the IMAP EAI document should say something like:

>  A client which is updated to add UTF8=* should be aware that if it
>  has cached any part of an internationalized message before
>  it was extended with UTF8=* support, then that part may be
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 14 May 2012 18:51
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade

On 05/14/2012 05:29 PM, Ned Freed wrote:
>> On 05/14/2012 05:02 PM, John C Klensin wrote:
>>> I'm not even certain it is possible to get right, at
>>> least while preserving UIDVALIDITY at all.
> 
>> I think simpledowngrade gets it right, since it doesn't touch any
>> non-EAI message at all. popimap-downgrade has a bit of a problem, since
>> it depends on downgraded-* not being there for non-EAI input messages.
> 
> It's more than a problem, it's a disaster in the making.

Perhaps.

> The problem is that you cannot make *any* assumptions about the presence or
> absence of downgraded-* fields. [...]

OK for me — I don't.

> And simpledowngrade doesn't really do much better, because you now end up
> with invalid addresses in the regular from and to fields.

IMO, that's the irreducible minimum problem. It's a nasty one, no
question, but if we're going to have EAI, we have to pay that price.

> This is why I continue to believe that all of this stuff is not only
> going to generate support calls, they're going to be the sort of calls where
> figuring out what happened requires real expertise.

Yes.
(Continue reading)

Permalink | Reply |
headers
ned+ima | 14 May 2012 20:01

Re: Status summary on SimpleDowngrade

> On 05/14/2012 05:29 PM, Ned Freed wrote:
> >> On 05/14/2012 05:02 PM, John C Klensin wrote:
> >>> I'm not even certain it is possible to get right, at
> >>> least while preserving UIDVALIDITY at all.
> >
> >> I think simpledowngrade gets it right, since it doesn't touch any
> >> non-EAI message at all. popimap-downgrade has a bit of a problem, since
> >> it depends on downgraded-* not being there for non-EAI input messages.
> >
> > It's more than a problem, it's a disaster in the making.

> Perhaps.

> > The problem is that you cannot make *any* assumptions about the presence or
> > absence of downgraded-* fields. [...]

> OK for me — I don't.

> > And simpledowngrade doesn't really do much better, because you now end up
> > with invalid addresses in the regular from and to fields.

> IMO, that's the irreducible minimum problem. It's a nasty one, no
> question, but if we're going to have EAI, we have to pay that price.

Not if you eliminate as many downgrade scenarios as possible.

> > This is why I continue to believe that all of this stuff is not only
> > going to generate support calls, they're going to be the sort of calls where
> > figuring out what happened requires real expertise.
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 14 May 2012 21:40
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade

On 05/14/2012 08:01 PM, Ned Freed wrote:
> I'm sorry, but I strongly disagree. It's absolutely vital that these
> specifications list all the known consequences of their use, *especially*
> those consequences that cannot be mitigated, so that people deploying
> this stuff can make informed choices about how to set things up, and indeed,
> whether or not to deploy it at all.

All of the documents from this WG are going to be read mostly by people
who are implementing some EAI thing or another, or are already
implementing. You're talking about people who might/will deploy, which
is a different audience.

I'm not at all opposed to having a document about deployment issues, I
think it would be a fine thing, but I'm definitely not volunteering to
write that.

Arnt
Permalink | Reply |
headers
ned+ima | 14 May 2012 22:56

Re: Status summary on SimpleDowngrade

> On 05/14/2012 08:01 PM, Ned Freed wrote:
> > I'm sorry, but I strongly disagree. It's absolutely vital that these
> > specifications list all the known consequences of their use, *especially*
> > those consequences that cannot be mitigated, so that people deploying
> > this stuff can make informed choices about how to set things up, and indeed,
> > whether or not to deploy it at all.

> All of the documents from this WG are going to be read mostly by people
> who are implementing some EAI thing or another, or are already
> implementing. You're talking about people who might/will deploy, which
> is a different audience.

I'm doing nothing of the sort. There are *implementation* choices to be
made here, including but not limited to which downgrade approach to use.

This was actually the case even with one downgrade mechanism: Implementations
choices don't stop at simply writing a module that performs a downgrade
operation. There are a myriad of choices and tradeoffs as to how this interacts
with the server, and the consequences of downgrade, including the
non-mitigatable ones, are absolutely a part of that.

But even that weren't the case, the minute you proposed an alternative
downgrade mechanism, you bought in to all of this stuff. And with all due
respect, I suggest you start dealing with that reality.

				Ned
Permalink | Reply |
headers
Arnt Gulbrandsen | 15 May 2012 09:14
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade

On 05/14/2012 10:56 PM, ned+ima <at> mrochek.com wrote:
>> On 05/14/2012 08:01 PM, Ned Freed wrote:
>>> I'm sorry, but I strongly disagree. It's absolutely vital that these
>>> specifications list all the known consequences of their use, *especially*
>>> those consequences that cannot be mitigated, so that people deploying
>>> this stuff can make informed choices about how to set things up, and indeed,
>>> whether or not to deploy it at all.
> 
>> All of the documents from this WG are going to be read mostly by people
>> who are implementing some EAI thing or another, or are already
>> implementing. You're talking about people who might/will deploy, which
>> is a different audience.
> 
> I'm doing nothing of the sort. There are *implementation* choices to be
> made here, including but not limited to which downgrade approach to use.

Sorry, I guess I misunderstood.

> This was actually the case even with one downgrade mechanism: Implementations
> choices don't stop at simply writing a module that performs a downgrade
> operation. There are a myriad of choices and tradeoffs as to how this interacts
> with the server, and the consequences of downgrade, including the
> non-mitigatable ones, are absolutely a part of that.
> 
> But even that weren't the case, the minute you proposed an alternative
> downgrade mechanism, you bought in to all of this stuff. And with all due
> respect, I suggest you start dealing with that reality.

Do you have more concrete suggestions? Because I've thought about
implementation discussion and advice and in the case of simpledowngrade
(Continue reading)

Permalink | Reply |
headers
John Levine | 15 May 2012 16:26

Re: Status summary on SimpleDowngrade

>> But even that weren't the case, the minute you proposed an alternative
>> downgrade mechanism, you bought in to all of this stuff. And with all due
>> respect, I suggest you start dealing with that reality.

I have to agree with Arnt, all approaches to dealing with EAI mail to
non-EAI recipients are horrible.  If you do something different the
horror changes but doesn't go away.

If you reject EAI messages to non-EAI recipients, people will
complain.  If you deliver downgraded messages, they're not repliable
and people will complain.  If you hide them or deliver placeholders
saying to upgrade your MUA, people will complain.  If your MDAs notice
EAI mail to non-EAI users and your concierge service goes out to
upgrade the user's mail software, they'll complain that it's not a
convenient time, my mail works fine, what are you doing, go away.

I suppose some webmail systems will be able to upgrade their entire
infrastructure, and only then globally set the EAI flag on all their
incoming MTAs, but short of that, what do you suggest?

R's,
John
Permalink | Reply |
headers
John C Klensin | 15 May 2012 23:21

Re: Status summary on SimpleDowngrade


--On Tuesday, May 15, 2012 14:26 +0000 John Levine
<johnl <at> taugh.com> wrote:

>>> But even that weren't the case, the minute you proposed an
>>> alternative downgrade mechanism, you bought in to all of
>>> this stuff. And with all due respect, I suggest you start
>>> dealing with that reality.
> 
> I have to agree with Arnt, all approaches to dealing with EAI
> mail to non-EAI recipients are horrible.  If you do something
> different the horror changes but doesn't go away.

I think we have consensus on that.  Does anyone significantly
disagree?  If not, can we stop repeating it?

> If you reject EAI messages to non-EAI recipients, people will
> complain.  If you deliver downgraded messages, they're not
> repliable and people will complain.  If you hide them or
> deliver placeholders saying to upgrade your MUA, people will
> complain.  If your MDAs notice EAI mail to non-EAI users and
> your concierge service goes out to upgrade the user's mail
> software, they'll complain that it's not a convenient time, my
> mail works fine, what are you doing, go away.

Sure.  Such is life.  And I haven't seen any recent disagreement
about this either.

> I suppose some webmail systems will be able to upgrade their
> entire infrastructure, and only then globally set the EAI flag
(Continue reading)

Permalink | Reply |
headers
Claudio Allocchio | 15 May 2012 23:39
Picon

Re: Status summary on SimpleDowngrade


On Tue, 15 May 2012, John C Klensin wrote:

>
>
> --On Tuesday, May 15, 2012 14:26 +0000 John Levine
> <johnl <at> taugh.com> wrote:
>
>>>> But even that weren't the case, the minute you proposed an
>>>> alternative downgrade mechanism, you bought in to all of
>>>> this stuff. And with all due respect, I suggest you start
>>>> dealing with that reality.
>>
>> I have to agree with Arnt, all approaches to dealing with EAI
>> mail to non-EAI recipients are horrible.  If you do something
>> different the horror changes but doesn't go away.
>
> I think we have consensus on that.  Does anyone significantly
> disagree?  If not, can we stop repeating it?

correct, we all agree.

>> If you reject EAI messages to non-EAI recipients, people will
>> complain.  If you deliver downgraded messages, they're not
>> repliable and people will complain.  If you hide them or
>> deliver placeholders saying to upgrade your MUA, people will
>> complain.  If your MDAs notice EAI mail to non-EAI users and
>> your concierge service goes out to upgrade the user's mail
>> software, they'll complain that it's not a convenient time, my
>> mail works fine, what are you doing, go away.
(Continue reading)

Permalink | Reply |
headers
Douglas Otis | 15 May 2012 20:12

Re: Status summary on SimpleDowngrade

On 5/14/12 11:01 AM, ned+ima <at> mrochek.com wrote:
> > On 05/14/2012 05:29 PM, Ned Freed wrote:
> >>> On 05/14/2012 05:02 PM, John C Klensin wrote:
> >>>> I'm not even certain it is possible to get right, at least
> >>>> while preserving UIDVALIDITY at all.
> >>>>
> >>> I think simpledowngrade gets it right, since it doesn't touch
> >>> any non-EAI message at all. popimap-downgrade has a bit of a
> >>> problem, since it depends on downgraded-* not being there for
> >>> non-EAI input messages.
> >>
> >> It's more than a problem, it's a disaster in the making.
> >>
> > Perhaps.
Dear Ned,

One of the problems with EAI is many expect to leverage 
From-header-field domains to reference "authorization" records.  IMHO, 
that approach has serious problems.   Sources can still be authenticated 
via HELO/EHLO or StartTLS as a means to exclude phishing sources that 
otherwise place this type of email at extreme risk.  The HELO/EHLO must 
be encoded using A-Labels so in that sense it is immune to change.  As 
insurance against spoofing, conversion symmetry should be checked.

> >> The problem is that you cannot make *any* assumptions about the
> >> presence or absence of downgraded-* fields. [...]
>
> > OK for me — I don't.
>
> >> And simpledowngrade doesn't really do much better, because you
(Continue reading)

Permalink | Reply |
headers
SM | 15 May 2012 20:39

Re: Status summary on SimpleDowngrade

Hi Doug,
At 11:12 15-05-2012, Douglas Otis wrote:
>One of the problems with EAI is many expect to leverage 
>From-header-field domains to reference "authorization" 
>records.  IMHO, that approach has serious problems.   Sources can 
>still be authenticated via HELO/EHLO or StartTLS as a means to 
>exclude phishing sources that otherwise place this type of email at 
>extreme risk.  The HELO/EHLO must be encoded using A-Labels so in 
>that sense it is immune to change.  As insurance against spoofing, 
>conversion symmetry should be checked.

One of the problems is that there are problems outside the realm of 
EAI which are taken to EAI to resolve an issue outside EAI.

>Ensure possible solutions are not prevented.  Reluctance to 
>implement dual identities within the From header field is 
>understandable.  It breaks things like DKIM.  IMHO, EHLO in 
>conjunction with ATPS type of authorization scheme provides a 
>strategy that can adapt to the current email infrastructure as a 
>reasonable means to mitigate risk.  It seems

I am aware that someone else was, in my opinion, selectively quoting 
RFC 5321. :-)

Regards,
-sm
Permalink | Reply |
headers
Douglas Otis | 16 May 2012 00:09

Re: Status summary on SimpleDowngrade

On 5/15/12 11:39 AM, SM wrote:
> Hi Doug,
> At 11:12 15-05-2012, Douglas Otis wrote:
>> One of the problems with EAI is many expect to leverage 
>> From-header-field domains to reference "authorization" records.  
>> IMHO, that approach has serious problems.   Sources can still be 
>> authenticated via HELO/EHLO or StartTLS as a means to exclude 
>> phishing sources that otherwise place this type of email at extreme 
>> risk.  The HELO/EHLO must be encoded using A-Labels so in that sense 
>> it is immune to change.  As insurance against spoofing, conversion 
>> symmetry should be checked.
> One of the problems is that there are problems outside the realm of 
> EAI which are taken to EAI to resolve an issue outside EAI.
Dear SM,

Agreed.  Which is why leaving options open as simpledowngrade has done 
is likely the best approach.
>> Ensure possible solutions are not prevented.  Reluctance to implement 
>> dual identities within the From header field is understandable.  It 
>> breaks things like DKIM.  IMHO, EHLO in conjunction with ATPS type of 
>> authorization scheme provides a strategy that can adapt to the 
>> current email infrastructure as a reasonable means to mitigate risk.  
>> It seems
> I am aware that someone else was, in my opinion, selectively quoting 
> RFC 5321. :-)
I suspect those concerned about security need to carefully consider how 
EHLO/HELO SMTP parameters/StartTLS/etc might be used to secure email.  
While ESPs may not relish this challenge, it can be made to work in a 
fashion similar to that of early UUCP, which should not prove disruptive.
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 17 May 2012 03:59

Re: Status summary on SimpleDowngrade

Doug and SM,

This note is written as co-chair in the hope of focusing the
discussion...

--On Tuesday, May 15, 2012 15:09 -0700 Douglas Otis
<dotis <at> mail-abuse.org> wrote:

>...
>> One of the problems is that there are problems outside the
>> realm of  EAI which are taken to EAI to resolve an issue
>> outside EAI.

> Agreed.  Which is why leaving options open as simpledowngrade
> has done is likely the best approach.

I don't know what SM's intent was, but mine is to say "not our
problem, please take it elsewhere" every time an issue comes up
that exists independent of the EAI work.

I'm sorry you weren't able to make the interim meeting/ call on
Monday, but I think there is reasonable agreement within the WG
that the only way were are going to make progress toward getting
things wrapped up and to the IETF is to avoid debates about
"best approaches" where legacy POP or IMAP clients are accessing
upgraded servers and trying to access SMTPUTF8 messages.  We
seem to be in agreement that all solutions to that problem other
than upgrading the clients are bad enough that "best" is not
meaningful.  Please see and, if appropriate, comment on, the
proposed new text I posted a short time ago.
(Continue reading)

Permalink | Reply |
headers
Douglas Otis | 18 May 2012 00:17

Re: Status summary on SimpleDowngrade

On 5/16/12 6:59 PM, John C Klensin wrote:
> Doug and SM,
>
> This note is written as co-chair in the hope of focusing the
> discussion...
>
> --On Tuesday, May 15, 2012 15:09 -0700 Douglas Otis
> <dotis <at> mail-abuse.org>  wrote:
>
>> ...
>>> One of the problems is that there are problems outside the
>>> realm of  EAI which are taken to EAI to resolve an issue
>>> outside EAI.
>>>
>> Agreed.  Which is why leaving options open as simpledowngrade
>> has done is likely the best approach.
> I don't know what SM's intent was, but mine is to say "not our
> problem, please take it elsewhere" every time an issue comes up
> that exists independent of the EAI work.
>
> I'm sorry you weren't able to make the interim meeting/ call on
> Monday, but I think there is reasonable agreement within the WG
> that the only way were are going to make progress toward getting
> things wrapped up and to the IETF is to avoid debates about
> "best approaches" where legacy POP or IMAP clients are accessing
> upgraded servers and trying to access SMTPUTF8 messages.  We
> seem to be in agreement that all solutions to that problem other
> than upgrading the clients are bad enough that "best" is not
> meaningful.  Please see and, if appropriate, comment on, the
> proposed new text I posted a short time ago.
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 14 May 2012 19:00
Picon
Favicon
Gravatar

Re: Status summary on SimpleDowngrade

On 05/14/2012 05:29 PM, ned+ima <at> mrochek.com wrote:
> And what about download-and-delete clients (which exist for both POP and IMAP)?
> Yes, such clients won't suffer from UIDVALIDITY issues, but the messages are
> essentially irreversibly corrupt at this point. 

I have a feeling that during this transition, the late implementers are
going to feel more pain than the early ones.

Arnt
Permalink | Reply |
headers
John C Klensin | 14 May 2012 19:32

Re: Status summary on SimpleDowngrade


--On Monday, May 14, 2012 19:00 +0200 Arnt Gulbrandsen
<arnt <at> gulbrandsen.priv.no> wrote:

> On 05/14/2012 05:29 PM, ned+ima <at> mrochek.com wrote:
>> And what about download-and-delete clients (which exist for
>> both POP and IMAP)? Yes, such clients won't suffer from
>> UIDVALIDITY issues, but the messages are essentially
>> irreversibly corrupt at this point. 
> 
> I have a feeling that during this transition, the late
> implementers are going to feel more pain than the early ones.

That is both poetic justice (for a change) and implies
accelerating pressure to upgrade (probably A Good Thing).

   john
Permalink | Reply |
headers
ned+ima | 14 May 2012 20:18

Re: Status summary on SimpleDowngrade


> --On Monday, May 14, 2012 19:00 +0200 Arnt Gulbrandsen
> <arnt <at> gulbrandsen.priv.no> wrote:

> > On 05/14/2012 05:29 PM, ned+ima <at> mrochek.com wrote:
> >> And what about download-and-delete clients (which exist for
> >> both POP and IMAP)? Yes, such clients won't suffer from
> >> UIDVALIDITY issues, but the messages are essentially
> >> irreversibly corrupt at this point.
> >
> > I have a feeling that during this transition, the late
> > implementers are going to feel more pain than the early ones.

> That is both poetic justice (for a change) and implies
> accelerating pressure to upgrade (probably A Good Thing).

I'm not sure this is really relevant, but FWIW...

I don't see how this is really any different from the deployment of MIME,
or ESMTP, or many other things.

It's been my experience that the main factor isn't when, but who. If you're an
open source developer, for example, you're not under direct financial
pressure... And you don't have to care about customer support if you don't want
to. So you have a lot of control over your pain level, and most (wisely) choose
to keep that level low.

The same goes for the commercial entities whose software runs on vast numbers
of deployed systems. You're in the envious position of having your stuff be
treated as the defacto standard more often than not. You can release
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 14 May 2012 21:08

Re: Status summary on SimpleDowngrade


--On Monday, May 14, 2012 11:18 -0700 Ned Freed
<ned.freed <at> mrochek.com> wrote:

>...
>> That is both poetic justice (for a change) and implies
>> accelerating pressure to upgrade (probably A Good Thing).
> 
> I'm not sure this is really relevant, but FWIW...
> 
> I don't see how this is really any different from the
> deployment of MIME, or ESMTP, or many other things.
>...

> So I guess this is a longwinded way of saying I come to more
> or less the same conclusion but for different reasons.

Ned, I think "yes".

I think there is one small difference between EAI --perhaps not
generally, but at the IMAP/POP end of things.  I have no idea
how much of a difference it makes.  A system operator,
especially one at the "we are giving things away for free that
are worth what you pay for them and are big enough to not care"
end of the spectrum can avoid all issues with client interfaces
to the mail store by simply refusing to advertise EAI capability
at the delivery server.  Nothing requiring EAI capabilities ever
makes it into the mail store, so it makes no difference whether
POP or IMAP clients (or webmail interfaces) are upgraded or not.
The MIME design avoided that particular control point and, with
(Continue reading)

Permalink | Reply |
headers
ned+ima | 14 May 2012 18:06

Re: Status summary on SimpleDowngrade


> --On Monday, May 14, 2012 15:04 +0100 Alexey Melnikov
> <alexey.melnikov <at> isode.com> wrote:

> > A message in IMAP is immutable (i.e. it can't change its basic
> > properties, other than IMAP flags/annotations). The message is
> > uniquely identified by UIDVALIDITY (per mailbox value) + its
> > UID.
> > So if the message changes in the IMAP mailstore, it has to get
> > a new UID, or the UIDVALIDITY for the mailbox has to change.
> > The latter signals clients that all of its cached messages are
> > no longer available and have to be purged from the cache.

> Right.  I think that, among other things that means that, if I'm
> a server and I try the strategy of converting/downgrading the
> message when it enters the mail store and then keeping both
> versions and deciding which one to deliver based on what the
> client asks for, I'd better be _really_ alert and careful about
> the above.  I'm not even certain it is possible to get right, at
> least while preserving UIDVALIDITY at all.

> I started thinking about a slightly different, but related,
> problem over the weekend having to do with what happens when a
> user accesses a mail store with an EAI-compliant IMAP client, an
> EAI non-compliant IMAP client, a webmail client (probably
> compliant), and compliant and non-complaint POP clients that use
> the notorious "leave mail on server" option and that do so in
> different orders.  One can get a bad headache rather easily.  My
> use of the term "variant of message" rather than "downgraded
> message" in my "critical path issues" note earlier today was a
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 14 May 2012 18:37

Re: Status summary on SimpleDowngrade


--On Monday, May 14, 2012 09:06 -0700 Ned Freed
<ned.freed <at> mrochek.com> wrote:

>...
>> I started thinking about a slightly different, but related,
>> problem over the weekend having to do with what happens when a
>> user accesses a mail store with an EAI-compliant IMAP client,
>> an EAI non-compliant IMAP client, a webmail client (probably
>> compliant), and compliant and non-complaint POP clients that
>> use the notorious "leave mail on server" option and that do
>> so in different orders.  One can get a bad headache rather
>> easily.  My use of the term "variant of message" rather than
>> "downgraded message" in my "critical path issues" note
>> earlier today was a consequence of that because, in many
>> respects, a "downgraded message" (simple or otherwise) isn't
>> really a transformed copy of the same message -- it is a new
>> message with a familial or derivative relationship to the
>> original one that the server chooses to deliver instead.
> 
> If you want to turn that headache into a migraine, consider
> what happens when a single EAI client alternately accesses a
> mailbox on the campany LAN, which allows direct access, and
> through a capability-filtering corporate firewall that removes
> the EAI capability from the server announcement.
> 
> And yes, such firewalls do exist for POP, IMAP, and SMTP. And
> you can't assume they filter all the protocols in a consistent
> way either - does that upgrade this to a cluster headache?
(Continue reading)

Permalink | Reply |
headers
John Levine | 7 May 2012 14:35

Re: Status summary on SimpleDowngrade

>The third alternative is to keep th message in RAM and discard it at the
>end of the mailbox session. But in that case even frequent and until now
>cheap operations like UID FETCH 1:* RFC822.SIZE become expensive.

I would think that if your downgrade were something like simpledowngrade
you could downgrade on the fly, as the message passes from the message store
through the POP or IMAP server and out to the client.  As far as I can tell
it doesn't depend on any interactions between headers, so you can do it one
line or header at a time.

R's,
John
Permalink | Reply |
headers
fujiwara | 7 May 2012 07:17
Picon
Favicon

Re: Status summary on SimpleDowngrade

> From: John C Klensin <klensin <at> jck.com>
>> If people concretely expect to write MUAs that do something
>> useful with the Downgraded-foo headers, then we might as well
>> publish a document that says what those headers should
>> contain.  But it's my impression that the plan is to add them
>> just in case anyone is interested, which strikes me as mildly
>> counterproductive.
> 
> Kazunori Fujiwara and his colleagues can (and should) speak for
> themselves, but I suspect that they already have such MUAs
> implemented.  Certainly they had those MUAs when the
> experimental specs specified very similar downgrading in
> transit.  It would be quite easy to modify an MUA, and to move
> the downgrading code from an MTA to a POP/IMAP server, if one
> had that code already.  If I'm correct, there is both running
> code for the popimap-downgrade case and the Downgraded-foo
> headers and a community with a long history of routinely dealing
> with non-ASCII characters who think that approach is desirable.
> The combination is a lot more than "in case anyone is
> interested".  One can speculate on how many others are likely to
> support it, but that is more speculation.

I read the message now because of Japanesde holiday week.

In-transit-downgrading worked at the experimental spec and
implementing new MUA that understands Downgraded-* header fields may
be easy.

But, In my opinion, it is better to implement and deploy EAI capable
MUAs rather than to implement MUAs which understand popimap downgraded
(Continue reading)

Permalink | Reply |
headers
ned+ima | 6 May 2012 07:13

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)

> Let me be blunt, with the understanding that I agreed to take on
> this WG because there seemed to be general agreement that one of
> our major shared goals was to move this work forward
> efficiently, much more efficiently than we have been doing
> lately.

> Unless someone is going to argue strongly that the more complex
> popimap-downgrade spec should simply be dropped, which scenarios
> you (or others) find persuasive is simply not interesting.  You
> predict that one scenario will dominate and that certain things
> are important and therefore find some approaches unpersuasive.
> Others make different predictions and/or assessments of
> importance.  Starting from a variation on some of Ned's
> comments, others of us may have yet a third prediction.

Well, as I've stated before, I actually don't find it especially persuasive
that either of these documents will see much use in their intended roles. That
said, I've never said there is no utility here, and to be honest I'm really not
sure in the "whole mailbox permanent downgrade" which approach makes more
sense. 

> No matter how persuasive each of us may find our individual
> predictions, there are two important realities.  First, we are
> all making those predictions without specific experience or data
> about this particular type of situation.  Second, people who
> implement and deploy these things are thoroughly likely to do
> what they think is right, regardless of what the IETF predicts
> or thinks is good for them.

Sure, none of us have any actual deployment experience with EAI, which is part
(Continue reading)

Permalink | Reply |
headers
Claudio Allocchio | 6 May 2012 10:07
Picon

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)


>> Recommendation: Those of us who care about (note that I didn't
>> say "like") each of the scenarios try to make sure that the
>> protocols and actions that result are well-thought-out,
>> well-documented, and, ideally, clear about the scenarios for
>> which they are optimized.  Let's be sure that the base EAI POP
>> and IMAP documents provide the right references and linkages to
>> whatever downgrade specs are out there and that they are
>> otherwise agnostics.  And let's save arguments about
>> persuasiveness or plausibility for some time post-deployment
>> when we've actually accumulated some serious experience.
>
> Seems like a reasonable approach to me, especially since I happen to 
> think the likely deployment scenario may be rather different from what 
> we're envisioning.

with just my WG member hat on (and the ancient one of implmemeter and 
provider of gateway services - a very similar scenario to downgrading) I 
can only FULLY support this reccomendation and approach!

Very strange deployment we cannot even think of in our way to see the 
world can happen, <joke> also driven by users/groups which believes that 
the correct way to send a personal message to somebody is to post it on a 
social network messages board </joke>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio <at> garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;
(Continue reading)

Permalink | Reply |
headers
John Levine | 6 May 2012 16:42

Re: Downgrade this, was Status summary

> Second, people who implement and deploy these things are thoroughly
> likely to do what they think is right, regardless of what the IETF
> predicts or thinks is good for them.

You're doubtless correct, but now I'm totally confused.  I think I'm
seeing the suggestion that we provide a range of downgrade options,
none of which can interoperate, and implementers will implement one of
them or maybe do something totally different.  What's the benefit of
putting anything in a standard beyond the advice that a downgrade has
to get rid of non-ASCII text and not introduce addresses that could be
replied to by mistake?

As a straw man, here's another unimplemented downgrade strategy.

We all seem to agree that it would be a good thing for users to see
the addresses of their correspondents.  Let's say the message has
these headers, with the capitalized strings standing for UTF-8.

From: <ABDUL <at> AA> acomment
To: <BIBI <at> BB> bcomment
Cc: <CHEN <at> CC> ccomment

The downgraded message headers are rewritten to these:

From: <p1 <at> proxy.local> ABDUL <at> AA acomment
To: <p2 <at> proxy.local> BIBI <at> BB bcomment
Cc: <p3 <at> proxy.local> CHEN <at> CC ccomment

Since comment text can be MIME encoded, the user can now see the
original addresses.  The p1, p2, and p3 addresses are indexes into a
(Continue reading)

Permalink | Reply |
headers
ned+ima | 6 May 2012 16:50

Re: Downgrade this, was Status summary

> > Second, people who implement and deploy these things are thoroughly
> > likely to do what they think is right, regardless of what the IETF
> > predicts or thinks is good for them.

> You're doubtless correct, but now I'm totally confused.  I think I'm
> seeing the suggestion that we provide a range of downgrade options,
> none of which can interoperate, and implementers will implement one of
> them or maybe do something totally different.  What's the benefit of
> putting anything in a standard beyond the advice that a downgrade has
> to get rid of non-ASCII text and not introduce addresses that could be
> replied to by mistake?

There are some who are arguing that all of this needs to be marked as
informational, not standards-track. One of the possible, and even likely,
outcomes of that is that implementors will feel *no* need to implement things
in a consistent fashion. So not being on the standards track could reduce
the availability of validation anchors even more than it needs to be.

Regardless, I see your point that documenting multiple approaches has
its own issues, almost independnent of what those approaches are.

> As a straw man, here's another unimplemented downgrade strategy.

> We all seem to agree that it would be a good thing for users to see
> the addresses of their correspondents.  Let's say the message has
> these headers, with the capitalized strings standing for UTF-8.

> From: <ABDUL <at> AA> acomment
> To: <BIBI <at> BB> bcomment
> Cc: <CHEN <at> CC> ccomment
(Continue reading)

Permalink | Reply |
headers
John C Klensin | 6 May 2012 20:09

Re: Downgrade this, was Status summary


--On Sunday, May 06, 2012 14:42 +0000 John Levine
<johnl <at> taugh.com> wrote:

>> Second, people who implement and deploy these things are
>> thoroughly likely to do what they think is right, regardless
>> of what the IETF predicts or thinks is good for them.
> 
> You're doubtless correct, but now I'm totally confused.  I
> think I'm seeing the suggestion that we provide a range of
> downgrade options, none of which can interoperate, and
> implementers will implement one of them or maybe do something
> totally different.  What's the benefit of putting anything in
> a standard beyond the advice that a downgrade has to get rid
> of non-ASCII text and not introduce addresses that could be
> replied to by mistake?

See Ned's note.

> As a straw man, here's another unimplemented downgrade
> strategy.
> 
> We all seem to agree that it would be a good thing for users
> to see the addresses of their correspondents.  Let's say the
> message has these headers, with the capitalized strings
> standing for UTF-8.
> 
> From: <ABDUL <at> AA> acomment
> To: <BIBI <at> BB> bcomment
> Cc: <CHEN <at> CC> ccomment
(Continue reading)

Permalink | Reply |
headers
Claudio Allocchio | 6 May 2012 22:56
Picon

Re: Downgrade this, was Status summary


> There are all sorts of ways this could fail, e.g., a user
> sends mail through another MSA, but I will wave my hands and
> say that my users don't do that, or if they do, they get what
> they deserve.

There are good reasons to be very careful in promoting some field to a 
different scope in order to supply missing or useful information to act on 
inside a message header or evelope if the used filed is unstructured, and 
vaguely  specified in scope.

A true story to explain it:

in the '70s, the IBM MVS "SMTPNOTE" mail system (a quite primitive batch 
mail system) looked like

  //SENDNOTE EXEC PGM=IEBGENER
  //SYSIN DD DUMMY
  //SYSPRINT DD SYSOUT=*
  //SYSUT2 DD SYSOUT=(B,SMTP)
  //SYSUT1 DD *
  HELO MVSHOST
  MAIL FROM:<MVSUser <at> MVSHost.xyz.com>
  RCPT TO:<unixuser <at> pop3.xyz.com>
  DATA
  From: "some comment here" <MVSUser <at> MVSHost.xyz.com>
  To: "some comment here" <unixuser <at> pop3.xyz.com>
  Subject: Test message from MVS using SMTP

  This is a line in the body of the note.
(Continue reading)

Permalink | Reply |
headers
John R Levine | 6 May 2012 23:30

Re: Downgrade this, was Status summary

> There are good reasons to be very careful in promoting some field to a 
> different scope in order to supply missing or useful information to act on 
> inside a message header or evelope if the used filed is unstructured, and 
> vaguely  specified in scope.

I agree.  I did say I didn't think we should publish my hack.  But it 
seems to me that anything beyond simpledowngrade runs a similar risk.

> Now that hopefully I do not crash any more mainframes, I'm not in favour of 
> leaving open to any (even good) alternate ideas the already slippery path of 
> "downgrading". It's just MHO, of course... my cents, but let's stay with the 
> current 2 proposals, and see what will be implemented out there.

I'm not thrilled about them, but I suppose that if we publish them as 
informational they'd be mostly harmless.

R's,
John
Permalink | Reply |
headers
John C Klensin | 7 May 2012 01:22

Re: Downgrade this, was Status summary


--On Sunday, May 06, 2012 22:56 +0200 Claudio Allocchio
<Claudio.Allocchio <at> garr.it> wrote:

> 
>> There are all sorts of ways this could fail, e.g., a user
>> sends mail through another MSA, but I will wave my hands and
>> say that my users don't do that, or if they do, they get what
>> they deserve.
> 
> There are good reasons to be very careful in promoting some
> field to a different scope in order to supply missing or
> useful information to act on inside a message header or
> evelope if the used filed is unstructured, and vaguely
> specified in scope.

Yes.  And that is one of the advantages of the "separate header
fields" architecture of popimap-downgrade in comparison to trick
encoding and embedding hacks of various sorts.  Of course there
are disadvantages as well but, since we've been telling mail
implementers for many years to ignore (or purge) header fields
they don't recognize, the odds of unintended consequences are
vastly reduced.

> A true story to explain it:
> 
> in the '70s, the IBM MVS "SMTPNOTE" mail system (a quite
> primitive batch mail system) looked like
>...
(Continue reading)

Permalink | Reply |
headers
ned+ima | 6 May 2012 06:36

Re: Status summary on SimpleDowngrade (was: Re: AppsDir Review of draft-ietf-eai-simpledowngrade-03)

> > That is ultimately the argument in favor of popimap-downgrade over
> > simpledowngrade: if it is worth going to the trouble of downgrading
> > at all, one might as well exert the extra effort to do it
> > comprehensively.

> That's the argument, but it's one that I don't find at all persuasive.

I don't really find it persuasive either, but not for some the reasons you
give.

> If a user has a non-EAI MUA, the most a downgrade can realistically do
> to create something the MUA can display is what simpledowngrade
> describes.  Anything beyond that is a quality of implementation issue
> that has nothing to do with interoperability.  As soon as you rewrite
> anything, signatures break, heuristics that look for patterns in the
> header lines don't work any more, and it's just a losing battle to try
> to make it look like a real non-EAI message.

Unfortunately, one of your examples is demonstrably off target while the other
actually favors popimap-downgrade.

More specifically, as I pointed out in a previous message, AFAICT this supposed
"signature breaking" is nothing but a will o' the wisp. Yes, it will break DKIM
and DomainKeys, but those aren't intended to be end-to-end mechanisms. (And if
they used that way, they encounter a plethora of much more serious problems.)
The actual end-to-end signature mechanisms in use are things like PGP or
S/MIME. which operate either by using multipart/signed or through embeddings in
text parts. Since multipart/signed requires 7bit encoding of content, the issue
it has is with EAI proper, not with downgrading. And I fail to see an issue
specific to downgrading with text part embedddings either.
(Continue reading)

Permalink | Reply |

Gmane