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 implementations support its
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 ironically,
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
]
To: Nicholas Staff [EMAIL PROTECTED]; iesg@ietf.org;
ietf@ietf.org
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 when you didn't understand the relevence of my
post
you didn't ask me one
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 other
[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
: Carl Hutzler [EMAIL PROTECTED]
To: iesg@ietf.org; ietf@ietf.org
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 blames the victims:
whats
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 Levkowetz' idnits
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
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
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 plain
]
Best regards,
Nick Staff
- Original Message -
From: Dave Crocker [EMAIL PROTECTED]
To: Nicholas Staff [EMAIL PROTECTED]; iesg@ietf.org;
ietf@ietf.org
Sent: Sunday, June 19, 2005 11:15 AM
Subject: 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:
]
To: Tony Finch [EMAIL PROTECTED]
Cc: iesg@ietf.org; ietf@ietf.org
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 Anderson wrote:
Neither open
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
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
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
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, by the
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.
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
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
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 dismiss
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 woods
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. it was
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
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, limited
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 messages.
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
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
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
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
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
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 from
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
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
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
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
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
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
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:
Keith,
http://mipassoc.org/spamops/request%20for%20BCP%20status.txt
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 the
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 matter.
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
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
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:
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
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 also
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
Submission Between Independent Networks' to BCP
snip
(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 niche has
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
(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 because...
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 under the
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
: '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
is held) in Paris, since this impacts not just email
Crocker; ietf@ietf.org
Subject: Client and server authentication for email (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
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
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
term
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
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 that my
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, and saw that it
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 not
On Friday, June 10, 2005 04:25:58 PM -0400 Keith Moore moore@cs.utk.edu
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,
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
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 cannot
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
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
--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 ...
might
Ned Freed [EMAIL PROTECTED] wrote:
[Pekka Savola [EMAIL PROTECTED] wrote:]
On Wed, 8 Jun 2005, Ned Freed wrote:
[Pekka Savola [EMAIL PROTECTED] wrote:]
A practical issue I have with this doc is that the recommendations are
relatively few, and most of them are rather generic or vague.
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
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
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
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.
For
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+PLAIN (with a
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
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'
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
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
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
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.
On Fri, 3 Jun 2005, The IESG wrote:
The IESG has received a request from an individual submitter to consider the
following document:
- 'Email Submission Between Independent Networks '
draft-hutzler-spamops-04.txt as a BCP
This seems a good document, but could probably still use a bit of
On Fri, 3 Jun 2005, The IESG wrote:
The IESG has received a request from an individual submitter to consider the
following document:
- 'Email Submission Between Independent Networks '
draft-hutzler-spamops-04.txt as a BCP
This seems a good document, but could probably still use a bit of
Pekka is correct: a null IANA section is required for internet drafts.
It is stripped in the RFC process.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
--On Monday, 06 June, 2005 19:03 -0400 Sam Hartman
[EMAIL PROTECTED] wrote:
...
Dave 2. Taking note of the exact language used in the
sentence Dave citing MD5 -- specifically the may be
sufficient, please Dave supply alternative language.
That sentence recommends both cram-md5
Date: 2005-06-07 16:37
From: Dave Crocker [EMAIL PROTECTED]
1) What the implications of treating out-of-network mail injection as
submission are.
Unfortunately, you are asking an entirely open-ended question and I do not
know
what implications you are looking for.
One
On Wed, 8 Jun 2005, Ned Freed wrote:
A practical issue I have with this doc is that the recommendations are
relatively few, and most of them are rather generic or vague.
Haven't we learned more on email BCPs by now?
What we have learned and what we are able to reach consensus on are two very
John C Klensin [EMAIL PROTECTED] writes:
To that end, since CRAM-MD5 is very widely deployed, I'd like to
see a much stronger justification for removing it than matters
of taste.
Seconded.
In the programs I use, mostly centered around e-mail and SMTP/IMAP,
CRAM-MD5 is the normal
Hi. I'm not in a good position to write a long response now; let me
know if you do end up wanting a longer response and you'll get it in a
week or so.
I don't think cram-md5 is a reasonable best current practice. I think
it is accurate to describe it as a common practice.
It's my
On Wed, 8 Jun 2005, Ned Freed wrote:
A practical issue I have with this doc is that the recommendations are
relatively few, and most of them are rather generic or vague.
Haven't we learned more on email BCPs by now?
What we have learned and what we are able to reach consensus on are two very
Sam,
Dave 2. Taking note of the exact language used in the sentence
Dave citing MD5 -- specifically the may be sufficient, please
Dave supply alternative language.
That sentence recommends both cram-md5 and digest-md5. I think
digest-md5 is fine; I think cram-md5 is not. I'd like to
Dave == Dave Crocker [EMAIL PROTECTED] writes:
Dave Sam,
First, in section 5, please do not list cram-md5 as a secure
authentication technology. Today I think we'd require a
security layer from a SASL mechanism to consider it secure.
Also cram-md5 suffers from other
First, in section 5, please do not list cram-md5 as a secure
authentication technology. Today I think we'd require a security
layer from a SASL mechanism to consider it secure. Also cram-md5
suffers from other defects.
Also, I'm a bit concerned about the following requirement:
o Mail
Sam,
First, in section 5, please do not list cram-md5 as a secure
authentication technology. Today I think we'd require a security
layer from a SASL mechanism to consider it secure. Also cram-md5
suffers from other defects.
1. You mean that MD5 is not a common, current practise that
Dave Crocker wrote:
1. You mean that MD5 is not a common, current practise that
provides a useful degree of security?
The SASL-registry says limited for CRAM-MD5 and common for
DIGEST-MD5, whatever that means. I know an MSA offering...
AUTH PLAIN LOGIN CRAM-MD5
...s/CRAM-MD5/OTP/ or
93 matches
Mail list logo
