Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: Simon> "Kurt D. Zeilenga" <[EMAIL PROTECTED]> writes: >> It is my recommendation that the mandatory-to-implement >> "strong" authentication mechanism for this protocol be either: >> DIGEST-MD5 (with a mandate that impleme

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

I have not been following this topic closely. To the point of open relays being a problem. I think that the judgment as to if open replays are a problem or not depends on which spam lists you are on. With my system and by grep-ing through my last 4 weeks of logs there were 22,870 of 26,157 spam

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

There are several issues for the IESG: In summary, people have brought up several reasons that this draft shouldn't be approved. But I think these are sufficient: 1) End run around SMTP developers, as Keith Moore pointed out. 2) "spamops" past unreasonable and irrational demands and views requ

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

On Mon, 20 Jun 2005, Nicholas Staff wrote: > Dean, > > I couldn't agree with you more - thanks for saying it. You're welcome. > whats funny to me is if anything would have given spammers a reason to > exploit open relays it would have been the blacklists. No, this isn't the case, and ironica

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

Everybody, Most of the mail under this subject field is of little help to the IESG in judging whether the draft in question is ready to become a BCP. Please ask yourself "Does my message address specific issues in the draft?" before hitting the send button. Thanks - - - - - - - - - - - - - - -

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Tue June 21 2005 17:00, Frank Ellermann wrote: > > Bruce Lilly wrote: > [1.5 MB PDF] > > Heavens to Betsy, a whole floppy disk's worth of space :-). > > Won't impress my nice USR Courier and AcroReader 3.0 - I can't help that. The document comments indicate that it was generated from MS Po

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Bruce Lilly wrote: > Credit goes to Henrik Levkowetz' idnits program. ACK. [After some debugging with his help I found a way to use the Web service, it works fine with Lynx] [1.5 MB PDF] > Heavens to Betsy, a whole floppy disk's worth of space :-). Won't impress my nice USR Courier and AcroRe

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Mon June 20 2005 21:40, Frank Ellermann wrote: > Bruce Lilly wrote: > > > Checking nits according to > > http://www.ietf.org/ID-Checklist.html: > [...] > Okay, you found nits above the typo level, draft -04 > has to be fixed before it can be "last called" again. Credit goes to Henrik Levkowet

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

Message - From: "Carl Hutzler" <[EMAIL PROTECTED]> To: ; Sent: Tuesday, June 21, 2005 5:57 AM Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification [EMAIL PROTECTED] wrote: >On Tue, 2005-06-21 at 00:28, Nicholas Staff

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

[EMAIL PROTECTED] wrote: On Tue, 2005-06-21 at 00:28, Nicholas Staff blames the victims: whats funny to me is if anything would have given spammers a reason to exploit open relays it would have been the blacklists. I mean when you arbitrarily blacklist millions of their ISP's addre

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

On Tue, 2005-06-21 at 00:28, Nicholas Staff blames the victims: > whats funny to me is if anything would have given spammers a reason to > exploit open relays it would have been the blacklists. I mean when you > arbitrarily blacklist millions of their ISP's addresses you leave them with > no oth

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

From: "Dave Crocker" <[EMAIL PROTECTED]> To: "Nicholas Staff" <[EMAIL PROTECTED]>; ; Sent: Monday, June 20, 2005 9:09 PM Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification > See what worries me is whe

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

t; <[EMAIL PROTECTED]> To: "Tony Finch" <[EMAIL PROTECTED]> Cc: ; Sent: Monday, June 20, 2005 1:20 PM Subject: Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification On Mon, 20 Jun 2005, Tony Finch wrote: > On Sun, 19 Jun 2005, Dean

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

> See what worries me is when you didn't understand the relevence of my post > you didn't ask me one question. What makes you think I didn't understand the relevance of your post? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to:

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

help or not) and I just think so much brilliance could be directed elsewhere. Thanks and best regards, Nick Staff [EMAIL PROTECTED] Best regards, Nick Staff - Original Message - From: "Dave Crocker" <[EMAIL PROTECTED]> To: "Nicholas Staff" <[EMAIL PRO

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Bruce Lilly wrote: > Checking nits according to > http://www.ietf.org/ID-Checklist.html: [...] Okay, you found nits above the typo level, draft -04 has to be fixed before it can be "last called" again. > [R5.editor62] may be useful An 1.5 MB PDF, so that is most probably irrelevant to create pla

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

On Mon, 20 Jun 2005, Tony Finch wrote: > On Sun, 19 Jun 2005, Dean Anderson wrote: > > > > Neither open relays nor lack of email authentication are > > problems that are exploited by spammers. > > Neither of those statements are true. I've already addressed the first. No, you haven't addressed a

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Fri June 3 2005 09:47, The IESG wrote: > The IESG has received a request from an individual submitter to consider the > following document: > > - 'Email Submission Between Independent Networks ' > as a BCP > > The IESG plans to make a decision in the next few weeks, and solicits > final c

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

On Sun, 19 Jun 2005, Dean Anderson wrote: > > Neither open relays nor lack of email authentication are > problems that are exploited by spammers. Neither of those statements are true. I've already addressed the first. Regarding the second, we dealt with an incident last year where a spammer exploi

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

On Sun, 19 Jun 2005, Dave Crocker wrote: > The methods in the draft BCP are intended to close some holes and improve > up-stream (source) accountability. It's a small but necessary step towards > finding ways to develop trust, since trust begins with accountability. Except that, it doesn't close

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

> When I wrote that "nobody would be complaining if spam primarily consisted > > of Bloomingdale's catalogues and coupon val-paks" I didn't mean we wouldn't > complain if we recieved the same amount of spam but it was from legitimate > companies. I meant that maybe 1% of my spam comes from leg

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

This is an interesting observation, and the SPF group shed some light on this quite by accident last year. One of the differences between CAN-SPAM and the IEMCC proposal that was rejected by anti-spammers in 1997, is that IEMCC proposed to label commercial bulk email with a special header. CAN-

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

I have no religion about top or bottom posting. Bottom posting is a variation of posting inline. On Thu, 16 Jun 2005, Larry Smith wrote: > Since you top posted, I will, against nature, respond in kind. > > The one "item" you missed from your analogy is that postal mail is "paid" for > up front,

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Maybe you should stick to talking about things that you know something about. I thought that ad hominem attacks were considered unacceptable on this list? On any IETF list, actually. It's best all round if people remain professional and polite, however strong the disagreement. Brian ___

Re: Last Call: 'Email Submission Between Independent Networks' to BCP - Clarification

Because I have already recieved several comments relating to one aspect of my original post I thought a clarification was in order as I didn't explain myself properly and there is some misunderstanding. When I wrote that "nobody would be complaining if spam primarily consisted of Bloomingdale's

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

No need to go against your nature just to make me feel comfortable Larry, post any which way you like as I'm capable of following the thread whichever way you do it. I understand your point about the prepaying but the reason I don't think that's the answer is that if money were the cause then ther

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Since you top posted, I will, against nature, respond in kind. The one "item" you missed from your analogy is that postal mail is "paid" for up front, by the person "posting" (anon or not) - eg the post-office gets paid _before_ your letter gets delivered. The problem with spam is that the rec

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

I'm sure many will think this a stupid comment, but in the hopes that some don't I'll point out that the largest and arguably most efficient messaging system in the world is built upon open relay.  Anyone can anonymously drop a letter in any mailbox in the US and while there's junk mail it's prop

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Thu, 16 Jun 2005, Tony Finch wrote: > On Wed, 15 Jun 2005, Dean Anderson wrote: > > > > What sort of mail volume to you handle? 2000-4000 attempts isn't a lot > > for large volume domain handling millions of messages per day. > > About 250K legit messages each day, and about a million junk me

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Thu, 16 Jun 2005, Dave Crocker wrote: > Keith, > > > it's possible to have open relays that don't contribute to spam. but > > those relays need to employ some other means, e.g. rate limiting, to > > Rate limiting is a relatively recent technique. Though very useful it has... > ummm, limit

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Maybe you should stick to talking about things that you know something > about. I thought that ad hominem attacks were considered unacceptable on this list? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net __

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > it's possible to have open relays that don't contribute to spam. but > > those relays need to employ some other means, e.g. rate limiting, to > > Rate limiting is a relatively recent technique. Though very useful it has... > ummm, limited applicability. mostly because of blacklists. i

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Keith, > > it's possible to have open relays that don't contribute to spam. but > > those relays need to employ some other means, e.g. rate limiting, to > Rate limiting is a relatively recent technique. Though very useful it has... > ummm, limited applicability. Actually, in my neck of the

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Keith, > it's possible to have open relays that don't contribute to spam. but > those relays need to employ some other means, e.g. rate limiting, to Rate limiting is a relatively recent technique. Though very useful it has... ummm, limited applicability. One needs to be careful not to dismis

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Wed, 15 Jun 2005, Dean Anderson wrote: > > What sort of mail volume to you handle? 2000-4000 attempts isn't a lot > for large volume domain handling millions of messages per day. About 250K legit messages each day, and about a million junk messages. Yes, it isn't a very large proportion of our

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

There is a strong rough consensus in the email operations community that open relays -- MTAs that accept mail from any source on the open Internet, when it is directly destined to go back out to the Internet -- prevents providing reasonable levels of message sender accountability. That rough

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> I don't see that sort of probing on our MXs, except on rare occasions, and > we haven't seen it recently. FWIW, my logs on mrochek.com (my home domain) show around 35,000 relay attempts during the past 6 months. This number is almost certainly much too low, in that I have various other blocks in

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

I don't see that sort of probing on our MXs, except on rare occasions, and we haven't seen it recently. What sort of mail volume to you handle? 2000-4000 attempts isn't a lot for large volume domain handling millions of messages per day. You said it is more prevalent on hosts named mail or smt

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> The notion that email authentication has helped reduce spam is completely > unsubstantiated by actual practice. Which bit of text in the document are your referring to? > Email authentication isn't a weakness that is exploited by spammers. But the lack of accountability for message senders

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Wed, 15 Jun 2005, Dean Anderson wrote: > > Had anyone bothered to ask, I would have reported that open relay abuse > has dropped off to nearly nothing since the open relay blacklists shutdown > in 2003. MXs are routinely probed by relay attempts: we see about 2000-4000 such attacks each day. A

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

There is a tremendous amount of myth propogated in this document. The notion that email authentication has helped reduce spam is completely unsubstantiated by actual practice. We have just recently observed the failure of SPF, largely due to the fact it didn't work. Email authentication, even if

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > > But I will insist that it be fixed and that the fixes get adequate > > > review. > > i apologize. i did not realize that you had a personal veto. > > > and I didn't realize that you had personal authority to expect that your > documents be published as IETF consensus documents without a

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Dave, you don't have a leg to stand on here. boy, it's a good think i'm sitting. > But I will insist that it be fixed and that the fixes get adequate review. > i apologize. i did not realize that you had a personal veto. i always thought that the ietf requirement was to obtain support fr

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Perhaps ... or perhaps ... or perhaps, or perhaps , or perhaps... > I consider it a contribution to the discussion. Keith, if you want your postings to have a constructive effect, it would help if they took a constructive tone and had constructive content, rather than making essentially slan

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

guys? do ya mind? take a breath On Tue, 14 Jun 2005, Keith Moore wrote: Dave, If I'm not mistaken, the ball is in IESG's court now. As far as I can tell, they have enough input to know what to do. Keith but hey, thanks for continuing down such a constructive path. we wouldn't want to get

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Dave, If I'm not mistaken, the ball is in IESG's court now. As far as I can tell, they have enough input to know what to do. Keith > but hey, thanks for continuing down such a constructive path. we > wouldn't want to get bogged down in nit-picking attacks. __

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > > But I will insist that it be fixed and that the fixes get adequate > > > review. > > i apologize. i did not realize that you had a personal veto. > > > and I didn't realize that you had personal authority to expect that your > documents be published as IETF consensus documents without

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > But I will insist that it be fixed and that the fixes get adequate review. > > i apologize. i did not realize that you had a personal veto. and I didn't realize that you had personal authority to expect that your documents be published as IETF consensus documents without adequate review.

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Keith, if you want your postings to have a constructive effect, it would help > if > they took a constructive tone and had constructive content, rather than > making > essentially slanderous claims about end-runs, and offering hypotheticals for > which there is no basis. Dave, you don't ha

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Dave, you don't have a leg to stand on here. boy, it's a good think i'm sitting. > But I will insist that it be fixed and that the fixes get adequate review. > i apologize. i did not realize that you had a personal veto. i always thought that the ietf requirement was to obtain support f

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Perhaps ... or perhaps ... or perhaps, or perhaps , or perhaps... > I consider it a contribution to the discussion. Keith, if you want your postings to have a constructive effect, it would help if they took a constructive tone and had constructive content, rather than making essentially sla

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > Frankly, it's hard to see this as other than an attempt at an "end run" > > around the SMTP developer community. > > Let's see: it gets announced multiple times on an smtp developer > community mailing list. "announced" is quite a stretch. > That community chooses not to pursue the ma

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Keith, > > > > > > This status file claims that the document in question has had "Multiple > references to the document in the IRTF's ASRG and the retained ietf- > smtp mailing list." I took the trouble to search my archives of th

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Folks, > > We were asked to fill out a draft form as part of the IETF submission > process, > to provide background about the spamops effort. > > The form seems useful as input to the public discussion, as well as the iesg > discussions. > > A copy is located at: > >

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

In <[EMAIL PROTECTED]> Daniel Senie <[EMAIL PROTECTED]> writes: > I've just reviewed the ongoing arguments about the draft in question > and re-read the draft itself. I realize that I am only adding a voice of approval for this document during the last call, but over the last several days, I have

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

I've just reviewed the ongoing arguments about the draft in question and re-read the draft itself. What strikes me is the level of argument over one section that could easily be adjusted. I would recommend adjusting section 5 to say: "The strongest available secure authentication mechanism i

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Folks, We were asked to fill out a draft form as part of the IETF submission process, to provide background about the spamops effort. The form seems useful as input to the public discussion, as well as the iesg discussions. A copy is located at:

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > > If my use of "network" on this thread were meant as something > > > different from "local environment" in the draft, ... > > > > > It was for me. Reading the earlier messages, it seemed to me that the > > specified behavior was broken. Then I went back and read the original > > text,

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Tom Petch wrote: From "John C Klensin" <[EMAIL PROTECTED]>: (2) CRAM-MD5 was designed around a particular market niche and, based on the number of implementations and how quickly they appeared, seems to have responded correctly to it. It may be appropriate at this point to conclude that market

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Tom Petch - Original Message - From: "John C Klensin" <[EMAIL PROTECTED]> To: "Brian E Carpenter" <[EMAIL PROTECTED]>; "Keith Moore" Cc: ; ; "Dave Crocker" <[EMAIL PROTECTED]> Sent: Saturday, June 11, 2005 6:07 AM Subject: Re: Las

Re: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

At 16:56 11/06/2005, John C Klensin wrote: (2) If the key issue is "be sure you are talking to the right server", then one could still use a challenge-response mechanism as long as the server were properly verified to the client. Presumably that could be a

RE: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

Have some security oriented multimodal work being carried in the IETF? jfc At 18:26 11/06/2005, John C Klensin wrote: Christian, Many thanks. This is _hugely_ helpful to me and, I assume, to others. john ___ Ietf mailing list Ietf@ietf.org

RE: Last Call: 'Email Submission Between Independent Networks' to BCP

> Times change. Today, using challenge response mechanisms such as Indeed, times do change. That's why is would be quite nice for the security community to take affirmative action and formulate consensus statements about mechanisms that are appropriate for particular scenarios. Having the rest

RE: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

Christian, Many thanks. This is _hugely_ helpful to me and, I assume, to others. john --On Saturday, 11 June, 2005 09:13 -0700 Christian Huitema <[EMAIL PROTECTED]> wrote: >> (3) I may no longer fully understand the implications of >> "dictionary attack" and suspect that at leas

RE: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

> (3) I may no longer fully understand the implications of > "dictionary attack" and suspect that at least some > application writers understand it even less well that I > do. But, if my understanding is correct, it seems to me > that, if passwords or passphrases are

RE: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

gt;> Sent: Saturday, June 11, 2005 10:57 AM >> To: Christian Huitema; Brian E Carpenter; Keith Moore >> Cc: iesg@ietf.org; Dave Crocker; ietf@ietf.org >> Subject: Client and server authentication for email (was: RE: >> Last Call: 'Email Submission Between Independent

RE: Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

(was: RE: > Last Call: 'Email Submission Between Independent Networks' to BCP) [snip] > It may be just my ignorance, but this does raise, for me, > some additional issues. Perhaps they should be put on the > agenda for discussion in the Apps Area meeting (assuming on >

Client and server authentication for email (was: RE: Last Call: 'Email Submission Between Independent Networks' to BCP)

Christian, Thanks. This is, IMO, _exactly_ the sort of explanation and recommendation that needs to be turned into an I-D titled something like "Challenge-response over unprotected channels no longer adequate" and published as a BCP.It didn't require very many paragraphs of explanation, it is

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> Date: 2005-06-11 03:04 > From: "Christian Huitema" <[EMAIL PROTECTED]> > Steve Bellovin was alluding to the "evil twin" attack on wireless > network. Allow me to elaborate. > > The technique allows an attacker to lure unsuspecting travelers to > connect to an un-protected wireless network und

RE: Last Call: 'Email Submission Between Independent Networks' to BCP

> (1) "known weaknesses [citations]" is significantly different > from "we don't like it" or "we assert it is bad" or even "we > don't like things unless they contain several additional > layers". The third of these might be a reasonable statement, > but would require even more justification bec

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

--On Friday, 10 June, 2005 11:18 +0200 Brian E Carpenter <[EMAIL PROTECTED]> wrote: >... > However, a BCP that states something like > >CRAM-MD5 is widely deployed for this purpose but due to > known weaknesses >[citations] is NOT RECOMMENDED. The RECOMMENDED > alternatives are ... >

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Maybe the spamops document needs a reference to the email-arch document? No, this is still highly controversial. To put it mildly. The spamops-document OTOH is fine for practical purposes. I agree that putting the arch document in the critical path for spamops would be likely to considerab

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Jeffrey Hutzelman wrote: > Maybe the spamops document needs a reference to the > email-arch document? No, this is still highly controversial. To put it mildly. The spamops-document OTOH is fine for practical purposes. Bye, Frank ___

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Kurt D. Zeilenga wrote: >> And if they don't like CRAM-MD5 what they'll get is LOGIN or >> PLAIN _without_ TLS, sigh. > I disagree with this statement. Today, many email client > and server supports TLS Not my favourite old MUA, unfortunately. When I implement a simple script I'm limited to a

correction Re: Last Call: 'Email Submission Between Independent Networks' to BCP

just a minute ago, I wrote: > It's hard to propose text that says what you mean when I don't know what you > mean (and cannot determine it from the text that is written). when I should have written: > It's hard to propose text that says what they mean when I don't know what they > mean (and cann

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> FWIW, I found the actual text perfectly clear; it was indeed the discussion > that was confusing. I wouldn't object to further clarification, but I > don't have text to propose, either. Do you? It's hard to propose text that says what you mean when I don't know what you mean (and cannot dete

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Friday, June 10, 2005 04:25:58 PM -0400 Keith Moore wrote: > at the very least it illustrates that using vague terms in a technical > specification without defining those terms can lead to > misunderstanding. Keith, the problem with pushing so hard to win a point, without actually re

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > at the very least it illustrates that using vague terms in a technical > > specification without defining those terms can lead to misunderstanding. > > Keith, the problem with pushing so hard to win a point, without actually > reading > things carefully, is that the material often does no

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > > If my use of "network" on this thread were meant as something > > > different from "local environment" in the draft, ... > > > > > It was for me. Reading the earlier messages, it seemed to me that the > > specified behavior was broken. Then I went back and read the original > > text,

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > If my use of "network" on this thread were meant as something different > > from "local environment" in the draft, then combinatorial concern you > > are raising would indeed need attention. And I wish I believed that my > > use of the word were the cause of the problem on this thread. > >

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Jeff, > Indeed. The answer to my concern appears to lie in the subtle but > significant semantic distinction between Relaying and Aliasing, which I I went through quite a number of iterations about aliasing in the email-arch document, based on lots of feedback. It does, indeed, seem to be a c

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Friday, June 10, 2005 12:55:27 AM -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: If my use of "network" on this thread were meant as something different from "local environment" in the draft, then combinatorial concern you are raising would indeed need attention. And I wish I believed tha

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

At 10:43 PM 6/9/2005, Frank Ellermann wrote: >And if they don't like CRAM-MD5 what they'll get is LOGIN or >PLAIN _without_ TLS, sigh. I disagree with this statement. Today, many email client and server supports TLS, and does so independently of what SASL mechanisms they may or may not support.

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Keith Moore wrote: The current document purports to be a candidate for BCP and yet it recommends a practice which is clearly no longer appropriate. clearly? please provide a citation to any sort of official consensus statement that establishes this clarity. you seem to be confusing tw

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> This, I think is the crux of the problem. The statement above appears to > conflate an IP network with an administrative domain, and assumes that > something belongs to one if and only if it belongs to the other. If I had said "IP" network you'd have a pretty good case. However I meant the

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Keith Moore wrote: >> if you are coming from outside the network, you do not get >> to "relay" through the network. You can post/submit from >> within, you can deliver into the net or you can post/submit >> from outside. > This is wrong. "outside the network" is irrelevant. What > matters is w

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

On Friday, June 03, 2005 05:27:55 PM -0700 Dave Crocker <[EMAIL PROTECTED]> wrote: In other words, if you are coming from outside the network, you do not get to "relay" through the network. You can post/submit from within, you can deliver into the net or you can post/submit from outside.

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Sam is correct here - the text as written is incorrect, even if it accurately reflects the authors' intent. You mean that you disagree with the authors' intent. That is quite different from the document being "incorrect". I meant what I said. You may infer that it is my opinion, and tak

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

The current document purports to be a candidate for BCP and yet it recommends a practice which is clearly no longer appropriate. clearly? please provide a citation to any sort of official consensus statement that establishes this clarity. you seem to be confusing two things - technical q

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> The current document purports to be a candidate for BCP and yet it > recommends a practice which is clearly no longer appropriate. clearly? please provide a citation to any sort of official consensus statement that establishes this clarity. an ietf formal publication would be preferred for t

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > > Sam is correct here - the text as written is incorrect, even if it > > > accurately reflects the authors' intent. > > > > > You mean that you disagree with the authors' intent. That is quite > > different from the document being "incorrect". > > > I meant what I said. You may infer tha

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

The line of discussion about a particular algorithm reflects the rather unfortunately tendency to have every system-level effort involving security get dragged into low-level debates about basic algorithms and about the current views of various experts in the security community. That's no way t

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

The implications you are drawing are exactly what is intended. When the document said "treat as a submission" it meant exactly that. Sam is correct here - the text as written is incorrect, even if it accurately reflects the authors' intent. You mean that you disagree with the authors'

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> The environment has changed a great deal. I don't know why people > thought MITM attacks weren't feasible in 1996 -- Joncheray published a > paper on how to carry them out in 1995 -- but they're now trivial. There are some meta-problems with this thread. (Aside: John K has raised his own

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

"Kurt D. Zeilenga" <[EMAIL PROTECTED]> writes: > It is my recommendation that the mandatory-to-implement > "strong" authentication mechanism for this protocol be either: > DIGEST-MD5 (with a mandate that implementations > support its data security layers) > TLS+PLAI

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Keith, > > The implications you are drawing are exactly what is intended. When the > > document said "treat as a submission" it meant exactly that. > > > Sam is correct here - the text as written is incorrect, even if it > accurately reflects the authors' intent. You mean that you disagree

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

> > The good part of this requirement seems to be to subject such mail to > > authorization (and in many cases authentication). However I think > > that saying mail must be treated as submission rather than relaying > > may have effects significantly beyond authorization/authentication. > > F

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

In message <[EMAIL PROTECTED]>, John C Klensin writes: >The claims about man-in-the-middle attacks are another matter. >When the analysis was done in 1996, the conclusion was that such >attacks were not possible unless either the secrets were already >known to the attacker or there was a plausible

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

Kurt and Sam, I hope someone else will pick up this discussion, as I'm not the right person to lead it. I would encourage you to read and react to Simon's comments as a start. However, let me make a couple of additional observations: * CRAM-MD5 was caused because folks in the security area said

Re: Last Call: 'Email Submission Between Independent Networks' to BCP

My personal view (e.g., SASL chair hat off) is that CRAM-MD5 use on the Internet should be limited. It fails to provide any form of data security itself. The lack of integrity protection means sessions are subject to hijacking. While this inadequacy can be addressed by protecting the session wit

  1   2   >