Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[John C Klensin]

Dave,

I don't think much can be accomplished by an extended debate
about our respective points.   I've injected my comments into
the Last Call bin, you have injected yours.  As both of us have
pointed out on many other occasions, this is not about seeing
how many endorsers one can get.

You will probably like some of my more general comments on the
document even less.   Please at least acknowledge that I am
entitled to have those opinions.

--On Friday, February 27, 2009 18:52 -0800 Dave CROCKER
 wrote:

>...
> Personally, I suspect you'll have an easier time of it if you
> suggest specific text.  (As for making the text "consistent
> with other text in the document" I'd be glad to perform that
> task, given any rough approximation that folks like.)

That is a reasonable proposed compromise.  I am still concerned
that elements of this may be controversial enough that a WG
process is really required.   Most of those issues have been
aired before, especially vis-a-vis terminology that carries
highly loaded semantics with it, semantics are are particularly
sensitive given various efforts to establish mechanisms for
email sender authentication or authorization.  I will explain
that further in another note, but they are issues that have been
raised before.

>> An alternative, if you could get the IESG to agree to it,
>> would be to say, somehow, "the Internet's email system is
>> mostly ASCII although various changes have been made and are
>> being made to accommodate non-ASCII strings in appropriate
>> contexts; internationalization is not further discussed in
>> this document".
> 
> Well that is, indeed, specific text.
> 
> Are you suggesting it replace the existing Section 6.3 text?

What I'm suggesting is that you need to do one of two things:

(i) Get community consensus and IESG agreement to explicitly
blow off the internationalization issues.  I can personally live
with that as long as it is done explicitly, either with a "just
not discussed here" statement like the one above or with a
forward pointer to a document that may never be written.   I
note that either one would violate a BCP and some explicit
policy statements but that procedural issue is a separate
problem.

(ii) Write something real for Section 6.3 and put it there.
That might start with a trimming and reworking of the IMC
document (see Paul's "should not be referenced in a modern
architecture document" comment -- one of the few I18N-related
areas in which the two of us are in agreement).  Much of the
material there is good.  Some can just be left out.  The
references need to be updated and some of the text needs
reconsideration in the light of things that have happened in the
last decade.  I would volunteer to work with you and/or Paul on
the rewrite, but I really have to devote all of my
internationalization cycles right now to the IDNABIS WG.
However, if a revised version of that text were folded into the
architecture document and included in a Last Call, that would
obviously satisfy my concern about a normative reference to a
non-consensus document.

> Are you seeking support for that replacement from others on
> the list?

No.  I am asserting my belief that, without one of the choices
above, the document is incomplete and not ready for prime time.
I am completely agnostic about which choice is made although I
believe that the requirements for a meaningful
internationalization session are more comfortably waived for an
informational document than for a standards track one.

>> For example, [MAIL-I18N] points to RFC 2279, which has been
>> obsolete for more than five years due to a definitional
>> change,
> 
> What is the superior reference you suggest be used?

A quick glance at the rfc-index, or faking an I-D format for
[MAIL-I18N] and pushing it through the reference checker, will
quickly point you to RFC 3629, a full Internet Standard.
Depending on what else is being said, an additional reference to
RFC 5198 might also be relevant.   But note that these are
references out of [MAIL-I18N] and not the architecture document
itself.  They are irrelevant if you adopt the first option above
and would probably fall out fairly automatically in any
extraction of text from, and revision of [MAIL-I18N] for
incorporation into the architecture document as suggested in
(ii).

  john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[Dave CROCKER]

John C Klensin wrote:

 What specific changes are you proposing?


Really, John, whatever folks agree on is more than fine with me.  However, I 
also note that some other experienced IETFers have indicated that they consider 
it acceptable to leave the text as-is.


Please note that besides the terse Section 6.3, the document does duly cite RFC 
2045 and RFC 2047, for body and "header extensions", in Section 4.1.


My own sense of why the current I8N section is so sparse is because the 
additional capabilities have yet to be all that well established into the 
service, except for very narrow (albeit useful) exceptions.  Since the document 
seeks to describe what is standardized as accepted practice, that leaves a bit 
of a hole for I8N details.


The incorporation-by-reference done in the draft is an attempt to limit the 
document's being drawn into a topic that seems to be email's third rail.  Since 
you feel strongly about the document's failings in this regard and since you 
happen to be a tad more knowledgeable about the topic than I (or most others), 
what do you want included, *specifically*?




Actually, Dave, I can remember no community discussion of the
Internationalization section of this document.  


  



While this document has been kicking around the community for
quite a while and gotten comments and input from far more people
than are listed in the Acknowledgements, it is an individual


I've variously done two or three detailed audits, to find and list the name of 
every person who made posted a substantive note about any of the email-arch 
drafts.  This of course does not mean that I found everyone who should be 
listed. I know there are many others who have looked at the document, but if you 
know of any contributors who are missing from the section, please let me know.




   the question is "is
it ready" rather than "can the author insist that IETF
participants put other work aside to do a sufficiently close
review of a 49 page document to suggest alternate text that is
consistent with other text in the document".  


First, "is it ready" sounds like exactly the question that folks responding to 
the Last Call have been answering.


Second, in your own case this document is not exactly being sprung on you 
without notice.  It's been circulated in the ietf-smtp mailing list with 11 
revisions over 5 years, including 2 or 3 (or maybe even) four postings that 
characterized themselves as "pseudo Last Call".  And as cited above, there was 
an explicit request for discussion about internationalization last March on that 
list.  And many of those people cited in the Acknowledgments section performed 
detailed reviews.


Since shyness is not one of my failings, you know that anyone with an interest 
in email technology and standards has had this document intrude on their screen 
more than once over the last five years -- and I don't mean just folk within the 
IETF sphere.  So it doesn't make sense that you would suggest that there is 
somehow some sudden demand for review by folks within the email community.




I've demonstrated (and will demonstrate further below) that at
least this one section is not ready and have suggested what is


Now all you have to do is to convince those other folk who feel that the current 
text in the section is sufficient.


Personally, I suspect you'll have an easier time of it if you suggest specific 
text.  (As for making the text "consistent with other text in the document" I'd 
be glad to perform that task, given any rough approximation that folks like.)




An alternative, if you could get the IESG to agree to it, would
be to say, somehow, "the Internet's email system is mostly ASCII
although various changes have been made and are being made to
accommodate non-ASCII strings in appropriate contexts;
internationalization is not further discussed in this document".


Well that is, indeed, specific text.

Are you suggesting it replace the existing Section 6.3 text?

Are you seeking support for that replacement from others on the list?



For example, [MAIL-I18N] points to RFC 2279, which has been
obsolete for more than five years due to a definitional change,


What is the superior reference you suggest be used?


d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[Paul Hoffman]

At 8:30 PM -0500 2/27/09, John C Klensin wrote:
>Instead, it
>references (given how little text is in the Internationalization
>section, "incorporates by reference" might be more accurate) a
>somewhat-outdated private consortium document that has never had
>anything resembling formal IETF review.

+1. I am slowly going through draft-crocker-email-arch, but when I saw John 
bring this up, I thought it had to be a mistake.

I haven't touched the reference in question in over a decade. (There is no URL 
for the document in the draft, but it can be found at 
.) For those of you checking your 
chronometers, that means it predates IDNs, much less EAI.

It should not be referenced in a modern architecture document.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Comments requested on recent appeal to the IESG

[Douglas Otis]

On Feb 27, 2009, at 1:12 AM, Alessandro Vesely wrote:

Douglas Otis wrote:
There are hundreds of thousands of legitimate SMTP clients in  
comparison to hundreds of millions of domains.


My understanding is that recipients are only interested in a few  
domain names: their company, their banks, their customers, their  
providers, and the like. While they are probably interested in  
knowing about such site reputations, they don't want to know how  
often those domains' servers change their network settings. Good  
domain names last longer than their IPs.


Alessandro,

The recommended change does not eliminate the presence of the  
authorizing domain in the authentication-results header, but  
supplements it with that of the SMTP client IP address.  The SPF/ 
Sender-ID mechanism might be intended to only modify the DSN handling  
of messages not from authorized SMTP clients.  Although both RFC 4406  
and RFC 4408 make non-normative comments about what might be deduced  
from an authorizing domain's reputation in respect the validity of  
email-addresses, there is no mandate that ensures an assumption of  
validity.  Some incorrectly expect a domain that has authorized SMTP  
clients, will have only authorized SMTP clients that enforce the  
exclusive use of their domain within either the PRA or Mail From.


Assessing the reputations of SMTP clients indirectly by the  
authorizing domains significantly limits the protections that might be  
achieved whenever domain spoofing is detected.  Targeted phishing is  
already difficult to detect, where many attacks now leverage  
information from social networking sites to determine which domains  
are known by the victims.  While the SMTP client authorized by some  
domains change over time, the protection of the domain within either  
the PRA or Mail From is still a function of the SMTP client, and is  
not directly that of the many many more authorizing domains.


deliberately falsifying the data requires that "trusted-isp.com"  
be removed from my set of trustees.
Customers of such providers will still desire their email to be  
annotated.


The consistency of requiring perfect reputation of happy-fraud.com  
is questionable. If that's my bank, I should probably think about  
changing.


This misinterprets the concern.  ESPs optimize profits by reducing  
their support calls.  To do this, they might reduce erroneous  
rejections by tweaking SPF to make guesses.  As such, it is not safe  
to assume that because the ESP accepted a message from an authorized  
SMTP client, that:


  A) the SMTP client was actually authorized, and

  B) that this authorization verifies an authorizing domain emitted  
the message.


The safety of an assumption about an authorizing domain originating a  
message depends upon the reputation of the SMTP client for its  
protection of the PRA and Mail From.  Unfortunately, identifiers for  
the SMTP client have been omitted.  It appears ESPs have agreed not  
hold SMTP clients accountable to reduce ESP support calls.  Having  
some of their customer's domains affected by a security breach is  
preferred over all customer's domains being affected (even when it  
would be appropriate for all domains).


A package delivered by Fred bearing Sam's return address where Sam  
references Fred as being *authorized* does not represent an  
assurance that the package is really from Sam.  Only when Fred has  
a reputation of always checking sender identities against return  
addresses can there be any assurance that the return address is  
valid.


Trusting the return address is only relevant at the transport level,  
MUAs should not provide means to issue bounces.


Having the Authentication-Results header include the IP address of the  
SMTP client provides a means to better determine what is safe to  
reveal to the recipient.


Besides, IMHO, it is Sam's reputation that the recipient should be  
interested in, not Fred's. We apparently differ slightly on this  
subject, but I'd defer it, as it is not the most relevant point.


Holding Sam accountable for an SMTP client run by Fred assumes Sam has  
established agreements with Fred stipulating PRA or MAIL FROM  
exclusivity.  Will omission of the SMTP client identifiers morally  
obligate Sam to establish exclusivity service agreements?  Such  
agreements would not be a prerequisite when Fred is held accountable,  
but might be seen as revenue stream by ESPs.  In addition, when Fred's  
security is breached, the PRA or MAIL FROM for any domain delivered by  
Fred should not be trusted until Fred's breach has been mitigated.   
Not being able to determine whether a message was delivered by Fred  
makes comprehensive annotation protections impossible.


When Fred delivers email for tens of thousands of domains, how will a  
breach be reported?  Instead of reporting the range of IP addresses  
Fred uses, adjustment to annotations will need the tens of thousands  
of domains that Fred handles.  Do

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[John C Klensin]

--On Friday, February 27, 2009 16:50 -0800 Dave CROCKER
 wrote:

> John,
> 
> With respect to character set, internationalization, and the
> like, I cannot tell what text changes you propose for the
> document.  The current text was developed through community
> discussion.

>  What specific changes are you proposing?
> 
> s/old/new/ form, or a multiline equivalent, would be most
> helpful.
> 
> I suggest that the bulk of any changes really does need to
> refer to community consensus documents, rather than trying to
> summarize the topic.

Actually, Dave, I can remember no community discussion of the
Internationalization section of this document.   And while I
tend to agree with you about reference to community consensus
documents, that section does not reference one.  Instead, it
references (given how little text is in the Internationalization
section, "incorporates by reference" might be more accurate) a
somewhat-outdated private consortium document that has never had
anything resembling formal IETF review.

While this document has been kicking around the community for
quite a while and gotten comments and input from far more people
than are listed in the Acknowledgements, it is an individual
submission for the standards track, not a WG product subsequent
to a IETF-approved charter.   If the IESG is consistent with the
criteria it has applied to a large number of other individual
submission documents in the last year or so, the question is "is
it ready" rather than "can the author insist that IETF
participants put other work aside to do a sufficiently close
review of a 49 page document to suggest alternate text that is
consistent with other text in the document".  

I've demonstrated (and will demonstrate further below) that at
least this one section is not ready and have suggested what is
needed to fix it -- describe the current internationalization
status in sufficient detail to either eliminate the need to
reference "[MAIL-I18N]" or to reduce it to a clearly
informative, "additional reading" reference.   

An alternative, if you could get the IESG to agree to it, would
be to say, somehow, "the Internet's email system is mostly ASCII
although various changes have been made and are being made to
accommodate non-ASCII strings in appropriate contexts;
internationalization is not further discussed in this document".
Personally, I would object less to your saying nothing (or to
saying the above, which is equivalent) than to your hand waving
and then pointing off to a decade old non-consensus document
that is outdated in several areas.   But, while it is a pity to
hold the architecture document up because of [MAIL-I18N], if
that document represents what you have to say architecturally
about i18n issues, then it is normative and your document isn't
ready to go until it is... or until the reference to it can be
eliminated.  

For example, [MAIL-I18N] points to RFC 2279, which has been
obsolete for more than five years due to a definitional change,
for an authoritative definition of UTF-8.  It also points to and
recommends Unicode TR 7 for inline language tagging.  That
document was withdrawn years ago, the link given in [MAIL-I18N]
no longer works, and the material that supercedes it (Section
16.9 of TUS 5.0 for an accessible reference) has, as its second
sentence, "The use of these characters is strongly discouraged".
That rather clear statement is followed by a discussion of
alternatives (e.g., XML or HTML) and conditions under which the
tags might be appropriate, none of which obviously apply to
Internet mail.

Several of its other references, to both IETF and non-IETF
documents, are obsolete as well.

john



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[Dave CROCKER]

John,

With respect to character set, internationalization, and the like, I cannot tell 
what text changes you propose for the document.  The current text was developed 
through community discussion.  What specific changes are you proposing?


s/old/new/ form, or a multiline equivalent, would be most helpful.

I suggest that the bulk of any changes really does need to refer to community 
consensus documents, rather than trying to summarize the topic.


d/

John C Klensin wrote:

A few observations:

...

(3) There are some useful things that can be said that are, at
this point, settled parts of the architecture or at of least the
relevant protocols.  As suggested above, one is that the content
matter is settled and that UTF-8 is the winner in the character
set wars (although other things are certainly around).  Another
is that work on i18n of email headers and addresses is
progressing, but that, until that work completes, IDNs can be
expressed in ACE form (with appropriate references).  I would
personally avoid making anything resembling a normative
reference to the experimental documents, largely because they
introduce more new syntax and terminology that would then need
to be discussed.

(4) It is a nit, but "Because its origins date back to the use
of ASCII" leaves an impression that is not strictly correct.  It
would be accurate to say that its origins date back to the time
when even the use of ASCII was controversial.  However, the
origins have nothing to do with anything: the email architecture
of today is defined in ASCII terms.  RFCs 5321, 5322, and 2045ff
are written in ASCII terms and require ASCII (except in
body-part content) as are most of the other protocols
referenced.  It would be far more accurate to simply say that we
have an ASCII-based protocol suite that is gradually being
adapted to accommodate non-ASCII elements where those are
appropriate, with the current thread and model starting with the
introduction of text/ content-types in MIME.
 
(5) The document needs to be updated to reflect current

references.  In particular, RFCs 5321 and 5322 were published
almost six months ago.  They also contain some slight
adjustments to terminology and this document should be carefully
checked to be sure its terminology is still consistent with them.

regards,
 john



--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[John C Klensin]

Since this is a substantive comment on a document that is in
Last Call for Standards Track, I'm posting the note to the IETF
list.  Since I use different addresses for the SMTP list and the
IETF one, I don't know when or if this will appear on the latter.

With the exception of the last point, this note addresses
Section 6.3 of this document (on Internationalization)
exclusively.  I will post another note before the cutoff to
address other issues.

--On Friday, February 27, 2009 15:49 -0700 "J.D. Falk"
 wrote:

> Dave CROCKER wrote:
> 
>> Just to make this explicit, SM's note is to the rest of you,
>> not to me. I asked him to solicit comments from the group,
>> since I have only tried to make the document parrot what I8N
>> folk say. My own comprehension of the topic remains muddled.
> 
> Mine is similarly muddled, but I wonder...is it appropriate to
> reference a recent (and presumably temporary) experiment
> alongside documenting the current state of the art?
> Particularly when email-arch is unlikely to be updated for
> another five years?

Well, while my comprehension may be equally muddled, it isn't
for lack of trying and involvement.

A few observations:

(1) The use of international (non-ASCII) characters in message
bodies and content has been a done deal since MIME came in.
That should probably be said explicitly.  If we were redoing
that work today, we would probably strongly recommend the use of
UTF-8, rather than alternate encodings, and might require a
charset parameter on all instances of text/plain.   But no WG
has ever been willing to move on either of those two points.

(2) Given the requirement for an Internationalization
Considerations section, which this document honors with Section
6.3, handing the substance of that section off to an
non-consensus document (IMC's Mail-I18N) in what is clearly a
normative reference despite being listed as an informative one
(the previous sentence has essentially no content other than to
indicate that i18n is an "ongoing challenge") seems dubious and
probably inappropriate.

(3) There are some useful things that can be said that are, at
this point, settled parts of the architecture or at of least the
relevant protocols.  As suggested above, one is that the content
matter is settled and that UTF-8 is the winner in the character
set wars (although other things are certainly around).  Another
is that work on i18n of email headers and addresses is
progressing, but that, until that work completes, IDNs can be
expressed in ACE form (with appropriate references).  I would
personally avoid making anything resembling a normative
reference to the experimental documents, largely because they
introduce more new syntax and terminology that would then need
to be discussed.

(4) It is a nit, but "Because its origins date back to the use
of ASCII" leaves an impression that is not strictly correct.  It
would be accurate to say that its origins date back to the time
when even the use of ASCII was controversial.  However, the
origins have nothing to do with anything: the email architecture
of today is defined in ASCII terms.  RFCs 5321, 5322, and 2045ff
are written in ASCII terms and require ASCII (except in
body-part content) as are most of the other protocols
referenced.  It would be far more accurate to simply say that we
have an ASCII-based protocol suite that is gradually being
adapted to accommodate non-ASCII elements where those are
appropriate, with the current thread and model starting with the
introduction of text/ content-types in MIME.
 
(5) The document needs to be updated to reflect current
references.  In particular, RFCs 5321 and 5322 were published
almost six months ago.  They also contain some slight
adjustments to terminology and this document should be carefully
checked to be sure its terminology is still consistent with them.

regards,
 john

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Current mailbombing is instigated by FSF

[TSG]

Carsten Bormann wrote:

http://www.fsf.org/news/reoppose-tls-authz-standard

While I have a lot of sympathy for the cause, I have very little 
sympathy for the methods.

I have NO sympathy for the cause.
Rendering a mailing list that might be useful for actually resolving 
the issue inoperative by a "campaign" is idiotic.
Somebody from I* (the IETF chair may not be the right person this 
time) should call them and explain that this is not the way to win 
friends and impress people.


Gruesse, Carsten

PS: kill-filing messages CCed to campai...@ietf.org might help a bit.  
I don't know if the procedures allow to do this at the mailing list 
level.
Boy do I agree with you - The creation of a standard *** should *** have 
nothing to do with IP rights or licensing. The creation of any standard 
should JUST be based on whether proper vetting happened and whether the 
minimum number of ports was created and formally tested for 
interoperability. Anyone - and I mean ANYONE should be able to get a 
Standard by making the steps happen.


Todd Glassey


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Fwd: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard]

[Hector Santos]

Shouldn't the document reference RFC5321 and RFC5322 instead of the 
older ones?


--
Sincerely

Hector Santos
http://www.santronics.com

Dave CROCKER wrote:


Folks,

After 5 years and 11 public versions, the email-arch document has 
finally made its way into the formal IETF standardization process, 
starting with a Last Call for comments from the community.


The document is available in several formats from:

   

The HTML and PDF versions include figures that are markedly easier to 
view than the ASCII art in the (official) txt version...



The document is an individual submission.  Although many people have 
contributed to it, it was not the product of a working group.  So the 
IESG cannot presume it has support.  Hence, the Last Call of an 
individual submission carries an extra burden, to assess the amount of 
support that the document has from the community.  This requires 
affirmative postings from the community.


However verbose or terse, positive or negative, it will aid the IESG's 
assessment to see postings from you about whether to make "Internet Mail 
Architecture" an IETF standard.  In particular, note the enclosed 
announcement's:


 "Please send substantive comments to the ietf@ietf.org mailing 
lists by 2009-03-26."



Thanks.

d/

 Original Message 
Subject: Last Call: draft-crocker-email-arch (Internet Mail 
Architecture) to Proposed Standard

Date: Thu, 26 Feb 2009 10:10:17 -0800 (PST)
From: The IESG 
Reply-To: ietf@ietf.org
To: IETF-Announce 

The IESG has received a request from an individual submitter to consider
the following document:

- 'Internet Mail Architecture '
as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2009-03-26. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11811&rfc_flag=0 



The following IPR Declarations may be related to this I-D:



___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

[Eric Burger]

More than a +1: it is about time we got this out. For example, we  
would like to reference a document like this in the LEMONADE series of  
documents.


That said, this particular document is well written, gets the point  
across, and does the job nicely.


Of course, we could hold up publication for another three months, just  
so it can be an even five years since Dave submitted -00 :-(


On Feb 26, 2009, at 4:06 PM, Eliot Lear wrote:


Lisa,

I think this document is fairly well written, and I would support  
its publication.


Eliot

On 2/26/09 9:59 PM, Lisa Dusseault wrote:

FYI

-- Forwarded message --
From: The IESG
Date: Thu, Feb 26, 2009 at 10:10 AM
Subject: Last Call: draft-crocker-email-arch (Internet Mail
Architecture)  to Proposed Standard
To: IETF-Announce


The IESG has received a request from an individual submitter to  
consider

the following document:

- 'Internet Mail Architecture '
as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to  
the

ietf@ietf.org mailing lists by 2009-03-26. Exceptionally,
comments may be sent to i...@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-crocker-email-arch-11.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11811&rfc_flag=0

The following IPR Declarations may be related to this I-D:



___
IETF-Announce mailing list
ietf-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce
___
Apps-Discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss




___
Apps-Discuss mailing list
apps-disc...@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss




smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Comments requested on recent appeal to the IESG

[Alessandro Vesely]

Hi,

Douglas Otis wrote:
There are hundreds of thousands of legitimate SMTP clients in comparison 
to hundreds of millions of domains.


My understanding is that recipients are only interested in a few 
domain names: their company, their banks, their customers, their 
providers, and the like. While they are probably interested in knowing 
about such site reputations, they don't want to know how often those 
domains' servers change their network settings. Good domain names last 
longer than their IPs.


deliberately falsifying the data requires that 
"trusted-isp.com" be removed from my set of trustees.


Customers of such providers will still desire their email to be 
annotated.


The consistency of requiring perfect reputation of happy-fraud.com is 
questionable. If that's my bank, I should probably think about changing.


A package delivered by Fred bearing Sam's return address where Sam 
references Fred as being *authorized* does not represent an assurance 
that the package is really from Sam.  Only when Fred has a reputation of 
always checking sender identities against return addresses can there be 
any assurance that the return address is valid.


Trusting the return address is only relevant at the transport level, 
MUAs should not provide means to issue bounces. Besides, IMHO, it is 
Sam's reputation that the recipient should be interested in, not 
Fred's. We apparently differ slightly on this subject, but I'd defer 
it, as it is not the most relevant point.


[...]

As for tracing spoofing attacks, a MUA sees too little traffic to be 
able to do such activity.


It is reasonable to expect the MUA will check the reputation of a few 
hundred thousand IP addresses prior to applying annotations.


Here is where I don't follow you. I, for one, don't have a few hundred 
thousand messages in my mailbox. In addition most of the messages I 
have come from a minority of IP addresses.


 There are 
techniques that dramatically reduce the size of this list.  The 
alternative requires much less effective and indirect checks of many 
million authorizing domain names.


I must understand you're not talking about a process running on the 
MUA, correct?


[...]

The limit on the number of lookups should be low enough to dim DoS 
attacks.


The limit of even 10 DNS transactions (without going into how this might 
be extended) still represents an attack that does not consume _any_ 
additional resources of the attacker.


Consuming the attacker's resources is not relevant since they can 
outsource them for free.


True. I interpret it as leaving it up to the site admins to decide 
their policy. The net result should be that any local part from an 
authorized sender is reliable as much as the authorizing domain is 
trustworthy.


Agreed.  Why bother to check a local-part, especially when these checks 
might prove painful to innocent third-parties?


(I tend to appreciate the concealment of local parts as a means to 
save horizontal space on the MUA's window...)


Results obtained after inputing the *authenticated IP address* (by way 
of TCP interaction) of the SMTP client into mechanisms, such as SPF or 
Sender-ID, will be whether or not the SMTP client has been 
*authorized*.  Only when this SMTP client has a reputation of ensuring 
the Mail From or PRA originates from the user of that domain (perhaps 
with click-through validation associated with the access account), would 
it be safe to annotate a message as originating from the *authorizing* 
domain.  Attempting to indirectly assess SMTP clients based upon the 
authorizing domain makes the assessment orders of magnitude less 
effective and more expensive.


I may agree on that even if you didn't specify what techniques would 
be used. However, it seems that, even using those optimizations, the 
implied volume of data is not what a typical MUA has in its mailboxes. 
Thus, it has to rely on an external service. I ask again the same 
question: what is the result that such external service delivers?


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf