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

[Sam Hartman]

> "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
>> data security layers) TLS+PLAIN (with a recommendation that
>> PLAIN not be used when TLS is not in use).

Simon> I don't think recommending the DIGEST-MD5 security layers
Simon> is a good idea.

Simon> The integrity layer is hard coded to be HMAC-MD5, with keys
Simon> derived using a home-grown key-derivation function based on
Simon> MD5.


I think the key derivation function used by digest-md5 is sound given
reasonable assumptions.  I am reasonably certain this is true under
the random oracle assumption but believe it may be true under weaker
assumptions.


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

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

[Doug Royer]

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 spams blocked by my usage of two open
relay DNS-black lists blocking them from 14,131 UNIQUE IP addresses.
6,676 of which have no reverse-DNS. They seem to be in IP blocks of 
10-12. The other 2,616 spams that were DNS-blocked were from

non-open-relay lists. I still get 20-50 spams that make it to
my inbox every day.

The SORBS pages say they have over 3 Million such open relay
or open proxy (hacked or not) sites.

Spammers seem to setup open relays and use them. And as I do not
think that there are 14 thousand spammers, my guess is that the
spammer machines change their IP nightly or find a lot of open
relays. If it were not for open-relay DNS black lists,
I could not run my company.

About 90% of the the spam that is in my logs seems to be from
open relays.

I read your paper. And FYI,  I can name ONE person that is responsible
for about 60% of the spam that makes it into my inbox. So it is possible
that a few spammers are reading the anti-spam lists.

I can not me certain that the open-relay DNS-black lists are not
blocking other traffic. I only know which lists I subscribed to
after trial and error and looking at the logs to see which stopped
more spam.



3) Assertions and assumtions in the draft are based on spamops "lore"  
rather than fact. This is bad engineering. The "issue" in the draft is

whether its assumptions and assertions about open relays and email
authentication are based on facts, versus the opinions of zealots.  
Neither open relays nor email authentication has been shown to be related

to spam: Neither promoting spam, nor preventing spam.



--

Doug Royer | http://INET-Consulting.com
---|-

  We Do Standards - You Need Standards

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;1795 W. Broadway St #266;Idaho Falls;ID;83402;U.S.A
email;internet:[EMAIL PROTECTED]
title:CEO
tel;work:208-881-0380
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [EMAIL PROTECTED]
	Yahoo: Help4Unix
x-mozilla-html:TRUE
url:http://Royer.com
version:2.1
end:vcard



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

[Dean Anderson]

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 require
careful scrutiny: Spamops needs to give consideration to lawful and
legitimate activity. People loosely associated with this group promised in
1997 to give a "technical solution" to spam. They have failed for more
than 8 years to do that, but have instead been associated with various
schemes to charge/extort fees for email services. In 1997, they rejected a
compromise with IEMCC that in retrospect was quite reasonable, and in at
least one way better than the CAN-SPAM law that was finally passed,
because IEMCC proposed to label spam with a header.  In retrospect, the
spamops community has been extremely unreasonable and irrational, and has
failed to deliver anything that was promised.

3) Assertions and assumtions in the draft are based on spamops "lore"  
rather than fact. This is bad engineering. The "issue" in the draft is
whether its assumptions and assertions about open relays and email
authentication are based on facts, versus the opinions of zealots.  
Neither open relays nor email authentication has been shown to be related
to spam: Neither promoting spam, nor preventing spam.

4) There are also numerous detailed problems with the language in the 
draft. However, in comparison with the major issues 1-3 above, these are 
minor, but also indicate that the document is not suitable for last call.


More inline.

On Tue, 21 Jun 2005, Bill Sommerfeld 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 addresses you leave them with 
> > no other option.
> 
> "if anything would give burglars a reason to break windows, it would
> have been locked doors.  i mean, when you put locks on millions of
> doors, you leave them with no other option."

Yes, there are some "burglars". But the open relay situation is much more
like gas pumps: Anyone can drive up and put gas in. That doesn't give them
the right to drive off without paying.

> people who send spam *always* have the option of changing their line of
> work. 

Nonsense.  Real spammers, advertizing real products and real services have
the legal right to do so.  Blacklists have no legal right to block them.  
Exactis V.  MAPS, CAN-SPAM.  

Real spammers have no reason to abuse open relays.  And if they did use
them without permission, they would be easily blocked, easily found, and
then billed for those services. In 9 years, we've never found real
spammers abusing our relays. But we have found anti-spammers abusing them;
We've found anti-spammers soliciting abuse for them; We've found
anti-spammers telling people that open relays are free; And we've found
anti-spammers doing other mischief.  The "open relay" problem, is purely
due to anti-spammers.  The operational response:  Prevent anti-spammers
from discovering the relays, and you prevent abuse.  Real spammers aren't
searching for open relays, either.


--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   






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

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

[Dean Anderson]

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, it is anti-spammers that usually
made this assertion.  It isn't the case because intelligent spam-blocking
requires that the headers and message content be analyzed, ala spamassasin
and other tools.  Years ago, the unreasonable spamops folks insisted on
trying to block spam without receiving it: That is, to send a "550 no spam
accepted" type message before the SMTP DATA command. This kind of blocking
is not reasonable, since use of a relay, any relay (open or closed),
defeats the blocking scheme.  The often asserted goal of "saving
resources" is not valid because it is faster to queue the message and
analyze it afterwards than it is to hold up the mail process trying to
decide whether to reject it before receipt.

By contrast, intelligent analysis of the message headers and content can
block the message from a blocked host no matter what relays they used.  
(open, closed, authenticated, or unauthenticated). And this is what one
wants.

You should probably read http://www.av8.net/FTC.pdf, which details the
many fallacies promoted by anti-spammers about open relays.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

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

[Brian E Carpenter]

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
IETF Chair
Distinguished Engineer, Internet Standards & Technology, IBM


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

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

[Bruce Lilly]

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 PowerPoint by Windows Acrobat Distiller in 1.3 (Acrobat 4.x) PDF
format.

> > It is unclear what you're referring to; specific
> > sections of RFC 1958 were referenced.
> 
> This "incompatible with the Internet architecture",
> your death sentence.  You could as well quote KISS
> (3.5), the principle of constant change (1), build
> on the work of others (3.2), running code (3.14),
> or don't wait for perfect solutions (3.7).  In some
> way or another all relevant for hutzler-spamops-04.

Perhaps. You're welcome to comment on issues that you think are
important.  I picked the end-to-end issue (as reaffirmed by RFCs
3426 and 3439), security issues, and consistency and clarity of
terminology.  There may well be other issues; due to the ambiguity
and vagueness (in part due to lack of clear and consistent
terminology) it's not currently possible to tell from the draft
as written.

> > security multiparts (not referenced by RFC number,
> > which is 1847
> 
> You never stop to amaze me with RfC numbers I have
> never before heard of...  oh, that stuff, okay, now
> where's that related to MSA and MDA considerations ?

It's related to the concept of authentication/authorization and
the end-to-end principle.  It seems rather silly for some random
MTA to decide whether or not some human sender or machine is
allowed to send a message to me claiming to be from some author.
If the existing mechanisms which are capable of providing true
end-to-end authentication are used, there is absolutely no reason
for some intermediate MTA to try to play nanny.
 
> Okay, I'd interpret it as the address identifying the
> mailbox in the forward path.
[...]
> So "RCPT-TO address" is a forward-path minus route,

The point is that if the perfectly fine terminology used in the
primary reference is used in the draft itself, there is no need
for interpretation (i.e. "guessing").

> > other mail system components cannot determine whether
> > or not delivery is "final"
> 
> Then they have to assume that it is, and if something
> beyond their control has its own ideas it's responsible
> to get it right, e.g. a mailing list.
> 
> > See above and RFC 3028 (esp. sect. 4.3).
> 
> MUA-stuff, a MUA claiming to be no MUA is still a MUA.

No, RFC 3028 is Sieve, which "is not tied to any particular
operating system or mail architecture"; it can be run in an MUA,
but can also be run elsewhere.  See the RFC 3028 Abstract and
Introduction.

> > think about the word "gateway" for a moment or two.
> 
> Yes, MUAs claiming to be a gateway are often a PITA.

No, nothing to do with MUAs.  An MTA acting as a gateway might
indeed make final *SMTP* delivery, but not final delivery; moreover
a subsequent gateway may reintroduce the message into SMTP.  In
other cases, the MTA may be unable to determine whether delivery
is to a message store or to a temporary spooling area for subsequent
gateway processing.

In particular, your interpretation about "reject instead of accept
and later bounce" is inapplicable in the case of many gateways; the
gateway has no way to determine validity of the recipient mailbox
equivalent -- if it turns out to be invalid, a "bounce" may well be
the only way to provide an indication to the originator.  [in more
general terms, that interpretation means little if multiple "hops"
of store-and-forward (SMTP) is used; if one late hop results in a
permanent error reply code (or a timeout, etc.) the intermediate
MTA that accepted and stored the message before attempting to send
to the MTA or MDA that might be able to reject the message still
needs to send a "bounce", as that is specifically required by RFC
2821 sections 2.1, 3.3, 3.7, 4.1.1.4, 4.2.5, 6.1.]

> > So is it a person, a piece of software, a host, an IP
> > address, or what?
> 
> It's something with an IP connecting to port 25 or 587
> saying HELO or EHLO.  And if that's you using telnet
> it's perfectly okay.

But it's still not clear what it is that is supposed to be
authenticated.

> >> Yes, it's simply the 2476(bis) 4.3 MUST, see above.
> > Where's the justification for an imperative?
> 
> In section 4.3 of 2476(bis), without authentication it
> would be an open relay and no MSA.

The draft still lacks a justification corresponding to BCP 14
"actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)  For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for interoperability".

> > No. No matter what
> 
> Now wait, my next statement belonged to this part:
> 
> | If it's coupled with 2476(bis) "enforced submission rights".
> 
> > there is an open window that 

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

[Frank Ellermann]

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 AcroReader 3.0 -
I'll wait until you quote it again for an I-D where I
promised that it would survive your review.

>>>o Too much text is ambiguous or vague
>> Statements like this are vague and therefore almost
>> useless.
> That's in a summary and is supported by detailed
> comments on specific draft text which is ambiguous
> and/or vague.

Maybe swap "specific examples" and "comments".  Or
replace "comments" by "summary".  Or add "specific
examples shown below" to the "serious defects".

I simply tried to read it top down (jumping from
RfC 2476bis to the I-D and back in another window).

>> please remove [R21] from your list.

> It is unclear what you're referring to; specific
> sections of RFC 1958 were referenced.

This "incompatible with the Internet architecture",
your death sentence.  You could as well quote KISS
(3.5), the principle of constant change (1), build
on the work of others (3.2), running code (3.14),
or don't wait for perfect solutions (3.7).  In some
way or another all relevant for hutzler-spamops-04.

> security multiparts (not referenced by RFC number,
> which is 1847

You never stop to amaze me with RfC numbers I have
never before heard of...  oh, that stuff, okay, now
where's that related to MSA and MDA considerations ?

All they have to decide is "is this a submission ?",
"if yes, when should I accept it ?", "is this for
a local user ?", and "if no, what should I do ?".

Not at all related to the DATA or a potential MIME
multipart/signed or multipart/encrypted body.  Dave
is listed in the RfC 1847 credits, so he would know
if there's any problem.  I certainly don't see it.

> e.g. "RCPT-TO address" vs. RCPT TO path (no hyphen
> and "path" as used in RFCs 821, 2821)

Okay, I'd interpret it as the address identifying the
mailbox in the forward path.  Or as RfC 821 put it,
"the mailbox is an absolute address", "to emphasize
the distinction between an adress and a route".

So "RCPT-TO address" is a forward-path minus route,
what else should it be.  The hyphen might be a typo.

 [skipping some text where we probably disagree]
> The underlying problem may be the lack of definition
> of an MDA.

Point, 2476(bis) offers only MUA, MSA, and MTA.  And
your concept makes sense, but not in conjunction with
some ideas in the draft.

> other mail system components cannot determine whether
> or not delivery is "final"

Then they have to assume that it is, and if something
beyond their control has its own ideas it's responsible
to get it right, e.g. a mailing list.

> See above and RFC 3028 (esp. sect. 4.3).

MUA-stuff, a MUA claiming to be no MUA is still a MUA.

> think about the word "gateway" for a moment or two.

Yes, MUAs claiming to be a gateway are often a PITA.

  [submitting entity]
>> 2476(bis) defines MSA and MUA, it must be the latter
>> in this case.

> So is it a person, a piece of software, a host, an IP
> address, or what?

It's something with an IP connecting to port 25 or 587
saying HELO or EHLO.  And if that's you using telnet
it's perfectly okay.

>> Yes, it's simply the 2476(bis) 4.3 MUST, see above.
> Where's the justification for an imperative?

In section 4.3 of 2476(bis), without authentication it
would be an open relay and no MSA.  Normally I'd hate
"green MUST be a colour" statements, maybe there's an
odd weak point in the draft and 2476(bis).

> (draft-under-discussion punctuation mode on)
> If you, think, that adding random, commas, improves
> readability, you, are mistaken.  It obfuscates, the
> meaning.
> (bizarre punctuation mode off)

Only typos, nothing bizarre about it from my POV.

  [SMTP-afer-POP]
>> Depends on how you do it, it can be perfectly sane and even
>> better than the non-standard SMTP AUTH "LOGIN" scheme, or
>> PLAIN without TLS (not allowed, but not everybody knows it).

> No. No matter what

Now wait, my next statement belonged to this part:

| If it's coupled with 2476(bis) "enforced submission rights".

> there is an open window that an attacker can exploit.

He had to get the "enabled" IP and had to know the MAIL FROM.

> Also, basic POP3 uses plaintext USER and PASS commands;

When I said _can_ be better than AUTH "LOGIN" it was of course
not about USER PASS.  But APOP can be already slightly better.

>> My copy of RfC 3700 lists STD 10 => RfC 821 + 1870.

> std-index also says RFC 974.  std-index and rfc-index both
> say 821 et al. are obsoleted by 2821, and 2821 itself says
> so.

RfC 2821 is a "proposed standard", and for some of the more
obscure RfC 821 features like SAML or SOML it says "read 821".

Besides RfC 821 had a logical concept of MAIL FROM, at least
in theory, where RfC 2821 offers only a "we broke it, sorry".

 [rfc2223bis-08.txt]
> "A

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

[Bruce Lilly]

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 program.

> > [R5.editor62] may be useful
> 
> An 1.5 MB PDF, so that is most probably irrelevant to
> create plain text 20 KB Internet Drafts with 10 pages.

Heavens to Betsy, a whole floppy disk's worth of space :-).
It gives advice on writing comprehensible text (slides 42 through 54
are pertinent to the draft under discussion) among other things.

> >o Too much text is ambiguous or vague
> 
> Statements like this are vague and therefore almost useless.

That's in a summary and is supported by detailed comments on specific
draft text which is ambiguous and/or vague.

> > [X] incompatible with the Internet Architecture (RFC 1958).
> 
> This "exponential-growth-info" is no standard of any kind,
> please remove [R21] from your list.

It is unclear what you're referring to; specific sections of RFC 1958
were referenced.
 
> > [X] incompatible with one or more approved Internet
> > specifications
> 
> Care to name one or more specifications ?

Aside from RFC 1958, the review specifically mentioned issues related
to RFCs 2821, 2476, BCP 14, and security multiparts (not referenced by
RFC number, which is 1847).
 
> > [X] uses non-standard, inconsistent, or poorly-defined
> > terminology
> 
> Which "standard terminology" are you talking about ?

Several cases were specifically mentioned (e.g. "RCPT-TO address"
vs. RCPT TO path (no hyphen and "path" as used in RFCs 821, 2821)).
 
> > [X] not backwards compatible with widely deployed,
> > standards-conforming infrastructure
> 
> If there's a problem with 2476bis I didn't see it,
> except from the obvious s/2476/gellens-submit-02/

E.g. the conflict between 2476 et seq "MAY choose to use port 25" vs.
draft under discussion "MUST support the SUBMISSION port".  There are
of course other issues as listed in the review.
 
> > o Draft section 2 states that an MSA is always used
> > for "submission", but that is not universal current
> > practice.  Many service providers support only MTAs,
> > and messages may be initially transported by an MUA
> > sending to an MTA.
> 
> As defined in 2476bis that's a special case of an MSA:
> 
> | A site MAY choose to use port 25 for message
> | submission, by designating some hosts to be MSAs and
> | others to be MTAs.

No, while 2476 permits use of port 25 for an MSA, it does not specify
that use of port 25 automatically changes an MTA into an MSA.  MTA
transfer (other than gateways) precludes message modification; an
MSA is explicitly permitted by 2476 to modify message content without
notice to or approval of the client or author, and the draft's "treat
as submission" appears to encourage such unauthorized modification *by
MTAs*.
 
> And as far as I can tell it this _is_ current practice.

Unauthorized message modification may indeed be current practice in
*some* places, but it's not *best* current practice, and in any event
although the abbreviation "BCP" stands for best current practice, the
BCP series of RFCs has specific uses as specified in BCP 9 and as
paraphrased in the review; the draft under discussion fails to meet
several of the requirements for BCP as noted in the review (and by
others in IETF discussion list comments).

> > o The same draft section refers to an "inbox", which
> > is not defined.
> 
> Actually "inbox" is defined in the next statement,

I see no *definition*.  Nothing resembling one.

> > o In some cases, an MDA may continue transport of a
> > message based on per-mailbox forwarding, aliasing, or
> > list expansion operations.
> 
> If it's no final delivery it's no MDA.

The underlying problem may be the lack of definition of an MDA.  As
far as I'm concerned, aliasing, forwarding, and list expansion take
place at an MDA, when the mailbox local-part is interpreted.  Such
interpretation is a delivery operation rather than a transport operation
as it involves changes to the SMTP envelope.  That the same message
(RFC 2822 sect. 3.6.4) is again transported as a result of delivery
to a mailbox simply means that the delivery isn't "final" (and in
practice this may happen via a distributed mechanism such as a Sieve
script, such that other mail system components cannot determine whether
or not delivery is "final").
 
> > "It is sometimes difficult for an SMTP server to
> > determine whether or not it is making final delivery".
> 
> Difficult or not, it will decide this, otherwise it's a
> Schroedinger-MTA or science fiction.

See above and RFC 3028 (esp. sect. 4.3).  Also, think about the word
"gateway" for a moment or two.
 
> > Draft section 3 refers to "sender", which is not
> > defined.
> 
> It's defined in STD 10, everybody knows what it is.
> And in the context of chapter 3 it's the submitter.

RFC 

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

[Nicholas Staff]

Carl-

In the future I'd appreciate you not cluttering my mailbox with "fluff" 
either, so please refrain from posting such non-technical and off-topic 
messages in the future.

Might I ask why you thought it OK to cause everyone else to waste bandwidth, 
time, and energy reading your off-topic post?

But thank you for reminding everyone of the scare-tactics and bullying you 
and other spamops types are so fond of.

Of course, maybe the problem is that you see these comments as fluff and 
don't understand how pertinent they are.

Best regards,

Nick Staff

- Original 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 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 option.
>>
>>
>
>"if anything would give burglars a reason to break windows, it would
>have been locked doors.  i mean, when you put locks on millions of
>doors, you leave them with no other option."
>
>people who send spam *always* have the option of changing their line of
>work.
>
>- Bill
>
>
>
>
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>
>


I appreciate all of the substantive comments on the BCP draft so far.
But I would appreciate if fluff like the above were directed to another
list/formsomething other than the IETF/IESG. It simply does not
provide any technical benefits and simply causes me and others to have
to read more email. To be honest, anyone who has been as involved with
operational spam fighting as myself and the co-authors understands these
arguements all to well. No need to replay them here.

It sorta is spam, IMO :-)

Also, I am working with the team of co-authors to compile the legitimate
comments and suggestions and I intend to publish them back to the team
that submitted those comments shortly. We will keep the IETF/IESG lists
apprised of our progress.


-Carl






-- 
Carl Hutzler
Director, Host Mail Development
America Online
[EMAIL PROTECTED]
703.265.5521 work
703.915.6862 cell


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


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

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

[Carl Hutzler]

[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 addresses you leave them with 
no other option.
   



"if anything would give burglars a reason to break windows, it would
have been locked doors.  i mean, when you put locks on millions of
doors, you leave them with no other option."

people who send spam *always* have the option of changing their line of
work. 


   - Bill




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




I appreciate all of the substantive comments on the BCP draft so far. 
But I would appreciate if fluff like the above were directed to another 
list/formsomething other than the IETF/IESG. It simply does not 
provide any technical benefits and simply causes me and others to have 
to read more email. To be honest, anyone who has been as involved with 
operational spam fighting as myself and the co-authors understands these 
arguements all to well. No need to replay them here.


It sorta is spam, IMO :-)

Also, I am working with the team of co-authors to compile the legitimate 
comments and suggestions and I intend to publish them back to the team 
that submitted those comments shortly. We will keep the IETF/IESG lists 
apprised of our progress.



-Carl






--
Carl Hutzler
Director, Host Mail Development
America Online
[EMAIL PROTECTED]
703.265.5521 work
703.915.6862 cell


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

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

[Bill Sommerfeld]

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 option.

"if anything would give burglars a reason to break windows, it would
have been locked doors.  i mean, when you put locks on millions of
doors, you leave them with no other option."

people who send spam *always* have the option of changing their line of
work. 

- Bill




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

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

[Nicholas Staff]

I thought you didn't understand the relevance because you started your 
response with "I am not sure how this line of discussion relates to the 
proposed BCP" and you ended your response with "So an attempt to bring this 
thread into some relevance for the Last Call:"

To be honest I didn't understand why you wouldn't think it a relevant albeit 
dissenting post.  Anyway, we obviously both see very diffeent sides - 
hopefly if either of us are right that's the school of thought that will 
prevail.

Best regards,

Nick Staff
- Original Message - 
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 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:  www.bbiw.net



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

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

[Nicholas Staff]

Dean,

I couldn't agree with you more - thanks for saying it.

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 option.  Of course that would have fed the claims that open relay 
needed to be stopped which would have brought more support to the blacklists 
thereby forcing more spammers to seek out open relays, etc, etc, forever and 
ever.


- Original Message - 
From: "Dean Anderson" <[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 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 anything. You made an assertion that doesn't
stand up: What is probably your customers' attempts to relay externally
does not represent spammers trying to abuse open relays. This is very
likely legitimate, by legitimate users.  This doesn't make your point.

The fact that you seem to get gratification at "blocking email" and
ASSUMING it is abuse, doesn't do you, us, your customers, or anyone any
good. It doesn't show that open relays are exploited by spammers. The fact
is, open relays aren't abused by spammers.  In 9 years, no genuine
commercial operation has ever abused our relay. And we look. We don't just
look at "relay denied"  log messages and impute bad motives, as you do.
Instead, we look at the queued messages. We try to find the company
selling something; And there hasn't been any.  We found instead that this
is abuse queued by self-described anti-spammers aka "spamops" people
trying to "teach us a lesson" about running open relays. And when they
gave up on abuse and shut their "blacklists", we had no further abuse,
either.

> Regarding the second, we dealt with an incident last year where a spammer
> exploited an open proxy on our network to send spam;

An open proxy on a machine run by your customer is still your customer,
and is therefore entitled to send email.

> they evaded our port 25 block by using an unauthenticated outgoing SMTP
> relay.

But they were your customer, and were therefore authorized to send email.
If you had run SMTP AUTH, they would have obtained the password, because
they can INSTALL AN OPEN PROXY ON YOUR CUSTOMERS MACHINE.  Authenticating
the relay will do nothing.  Your problem is the open proxy.  Deal with the
problem, don't invent a solution that won't fix the problem.

> This attack was easy for us to stop because they discovered the relay by
> looking up our MX record;

Funny that you should call this as an "exploit". SPF (the email
authentication du jour)  will identify your outbound relays, too.

You are arguing in circles, making my points for me.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000



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


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

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

[Dave Crocker]

>  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:  www.bbiw.net



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

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

[Nicholas Staff]

And what does accountability mean for you David?  Does it mean people being 
accountable for their own actions or does it mean people being accountable 
to you?
See what worries me is when you didn't understand the relevence of my post 
you didn't ask me one question.  You didn't give me the opportunity to be 
accountable. You decided for me and while doing that you somehow managed to 
state none of my points while at the same time stating all of yours as if 
that's what I had been trying to say.

I'm including my original post at the end of this one so people can decide 
for themselves if your confusion was in earnest or if you're just dishonest.

As for your BCP, well David, one of the innconveniences about having a place 
where everyone can say what they want is that everyone can say what they 
want.  Personally I think that's a pretty fair trade-off (though I'm sure 
the aptly named SPEW(s) would disagree).

**Original Post**

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 proportions 
are certainly nothing like spam.  Why the difference?  Well first I split 
spam into 2 categories:

1.  legitimate advertisements for legitimate products (whether solicited or 
unsolicited).
2.  Fraudulent mail, scams, cons, etc.

I think the email abusers almost entirely fall into the second category and 
that nobody would be complaining if spam primarily consisted of 
Bloomingdale's catalogues and coupon val-paks.

So I think we are attacking things the wrong way.  The methods we are 
using - whether blacklists or 'authorized email' is going to either prove 
fruitless or end up ruining the big picture, which for me is electronic 
communication for everyone, to everyone.  Using electronic means, I don't 
see how we can ever prevent spam and still have open global communication 
among disparate systems.  It would be a different story if one organization 
ran all email servers worldwide but that horrible thought aside there will 
always be holes and breaks in an authentication/authorization scheme unless 
people limit who they can communicate with, and even then there will be 
spam.

There's also the returns we see on our efforts to consider.  Think of the 
millions of man/woman hours spent trying to stop spam - so many hours it 
probably would have taken less to inspect every email by hand.  And then 
when you think (if you believe as I do) that everything can be gotten around 
and that security holes are as infinite as the imagination, well then you 
know there will always be some kid with a script (which also includes any 
real spammer) who will be able to get around your defenses within a week of 
them being implemented.

My last unconstructive comment is that simple systems scale lossless and 
complex systems grow in a complexity proportionate to their size.

Funny enough, I think the postal inspector's department came about because 
of the amount of scams being sent via mail shortly after the civil war (such 
a glut that it was bringing the postal service to their knees).  Yet the 
postal service remained open-relay - why?  Maybe because they realized that 
they didn't need to 'trace' scam-mail because scams are trace-inclusive as 
the scammer must include a point of contact.  Sure there's the occasional 
anonymous letter bomb but since their resources aren't spent blocking coupon 
mailers they are much more likely to catch the big stuff.

I know there are 8 trillion problems with this idea but I think in general, 
email fraud needs to become like mail fraud and there needs to be a team of 
inspectors who follow up on such reports and arrest violators (I know the 
Internet is bigger than the US, so of course it's up to each country how to 
handle it).  I'm sorry for the non-technical post but I think blacklists are 
disgusting (I don't care if they 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 PROTECTED]>; ; 

Sent: Sunday, June 19, 2005 11:15 AM
Subject: 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

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

[Frank Ellermann]

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 text 20 KB Internet Drafts with 10 pages.
Remove {R5] from your references please, or at the
very minimum add a warning about its size.

> the status as defined in [R6.BCP9] should be:

Let's assume that we know the list of possibilities,
and just state what you think...

> [X] Informational

...something's wrong if your review is longer than
the reviewed source.

>o Too much text is ambiguous or vague

Statements like this are vague and therefore almost useless.

> [X] incompatible with the Internet Architecture (RFC 1958).

This "exponential-growth-info" is no standard of any kind,
please remove [R21] from your list.

> [X] incompatible with one or more approved Internet
> specifications

Care to name one or more specifications ?

> [X] uses non-standard, inconsistent, or poorly-defined
> terminology

Which "standard terminology" are you talking about ?

The draft references exactly three normative texts,
you might get some more recursively, so if there's a
conflict please _show_ it.  I can't check vague claims
based on what you might consider as "standard".

> [X] not backwards compatible with widely deployed,
> standards-conforming infrastructure

If there's a problem with 2476bis I didn't see it,
except from the obvious s/2476/gellens-submit-02/

> o Draft section 2 states that an MSA is always used
> for "submission", but that is not universal current
> practice.  Many service providers support only MTAs,
> and messages may be initially transported by an MUA
> sending to an MTA.

As defined in 2476bis that's a special case of an MSA:

| A site MAY choose to use port 25 for message
| submission, by designating some hosts to be MSAs and
| others to be MTAs.

And as far as I can tell it this _is_ current practice.

> o The same draft section refers to an "inbox", which
> is not defined.

Actually "inbox" is defined in the next statement, but I
agree that this definition is somewhat beside the point
in a piece of text about MDAs.

> o In some cases, an MDA may continue transport of a
> message based on per-mailbox forwarding, aliasing, or
> list expansion operations.

If it's no final delivery it's no MDA.

> "It is sometimes difficult for an SMTP server to
> determine whether or not it is making final delivery".

Difficult or not, it will decide this, otherwise it's a
Schroedinger-MTA or science fiction.

> Draft section 3 refers to "sender", which is not
> defined.

It's defined in STD 10, everybody knows what it is.
And in the context of chapter 3 it's the submitter.

> it is unclear what is meant by "sender authentication".

The complete chapter 3 explains what it's supposed to
be for an MSA, "submitter authentication".

> Section 3 also refers to "the final MTA-to-MDA
> transmission", ignoring the caveat in [R10.RFC2821].

"551 user not local" is an old and simple concept, not
the stuff to write a new BCP about.  The idea in the
draft is to reject mails to unknown local users a.s.a,p.
instead of first accept and later bounce such crap.

And that's indeed "best current practice" everywhere.

> It also refers to "MDA-to-MUA delivery"

What term do you propose to catch all these wild and
wonderful ways to get mail from an MDA to the user ?
This "MUA" could be a Webmail interface, it could be
IMAP, POP3, some ETRN or ATRN trick, UUCP, what else.

Maybe "mailbox-by-MUA access" ?

> The same draft section refers to a "relationship
> between client and server" but does not specify
> what the nature of the supposed relationship is

This "supposed relationship" can be whatever the site
wants it to be, the text simply states "MUST perform
 authentication during mail submission, based on an
 existing relationship with the submitting entity."

This MUST directly reflects the MUST in chapter 4.3
of 2476 or 2476bis, it's nothing new.

> "the MDA can determine that it will be effecting
>  final delivery" in direct contradiction to the
> statement quoted above from the approved Internet
> specification contained in [R10.RFC2821].

Yes, something might be odd here, because if it's
not effecting final delivery it's no MDA, and that
might be a kind of circular definition.

> undefined term "submitting entity"

2476(bis) defines MSA and MUA, it must be the latter
in this case.  I'm less sure about "formail" forms,
that could be a special case of "submitting entity".

> That bullet point uses a BCP 14 imperative keyword

Yes, it's simply the 2476(bis) 4.3 MUST, see above.

 [chapter 3, 3rd bullet]
> A BCP 14 imperative keyword is used with no rationale
> for such an imperative.

That's about open relays.  Treat mails from unknown
strangers to unknown strangers as submission.  In fact
this MUST is odd.  An open relay is 

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

[Dean Anderson]

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 anything. You made an assertion that doesn't
stand up: What is probably your customers' attempts to relay externally
does not represent spammers trying to abuse open relays. This is very
likely legitimate, by legitimate users.  This doesn't make your point.

The fact that you seem to get gratification at "blocking email" and
ASSUMING it is abuse, doesn't do you, us, your customers, or anyone any
good. It doesn't show that open relays are exploited by spammers. The fact
is, open relays aren't abused by spammers.  In 9 years, no genuine
commercial operation has ever abused our relay. And we look. We don't just
look at "relay denied"  log messages and impute bad motives, as you do.  
Instead, we look at the queued messages. We try to find the company
selling something; And there hasn't been any.  We found instead that this
is abuse queued by self-described anti-spammers aka "spamops" people
trying to "teach us a lesson" about running open relays. And when they
gave up on abuse and shut their "blacklists", we had no further abuse,
either.

> Regarding the second, we dealt with an incident last year where a spammer
> exploited an open proxy on our network to send spam; 

An open proxy on a machine run by your customer is still your customer,
and is therefore entitled to send email.

> they evaded our port 25 block by using an unauthenticated outgoing SMTP
> relay.

But they were your customer, and were therefore authorized to send email.  
If you had run SMTP AUTH, they would have obtained the password, because
they can INSTALL AN OPEN PROXY ON YOUR CUSTOMERS MACHINE.  Authenticating
the relay will do nothing.  Your problem is the open proxy.  Deal with the 
problem, don't invent a solution that won't fix the problem.

> This attack was easy for us to stop because they discovered the relay by
> looking up our MX record; 

Funny that you should call this as an "exploit". SPF (the email
authentication du jour)  will identify your outbound relays, too.

You are arguing in circles, making my points for me.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

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

[Bruce Lilly]

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 comments on this action.  Please send any comments to the
> iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-01.

Comments:


Internet-Drafts and RFCs are required to meet certain criteria:
[R1.Checklist] (see also references in that document), [R2.ID],
[R3.Instruct].  These can be checked by using the "idnits" tool:
[R4.idnits].  That tool noted the following regarding the document:

  idnits 1.73 (17 Jun 2005)

  draft-hutzler-spamops-04.txt:


Checking nits according to
http://www.ietf.org/ID-Checklist.html:
* The document seems to lack an IANA Considerations section.
  Checking conformance with RFC 3978/3979 boilerplate...
* The document seems to lack an RFC 3978 Section 5.1 IPR
  Disclosure Acknowledgement.

(Expected a match on the following text:
  "By submitting this Internet-Draft, each author represents that
  any applicable patent or other IPR claims of which he or she is
  aware have been or will be disclosed, and any of which he or she
  becomes aware will be disclosed, in accordance with Section 6 of
  BCP 79.")

  (The document uses RFC 3667 boilerplate or RFC 3978-like
  boilerplate instead of verbatim RFC 3978 boilerplate.  After 6
  May 2005, submission of drafts without verbatim RFC 3978
  boilerplate is not accepted.)

Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:
  Nothing found here (but these checks do not cover all of
  1id-guidelines.txt yet).

Miscellaneous warnings:
  None.

The wording of the document is poor.  [R5.editor62] may be useful.  Many
terms (details below) are undefined, poorly defined, or inconsistently
defined.  Many "sentences" suffer from odd placement of punctuation,
particularly commas, which make parsing those "sentences" impossible.

The (intended) status of the document is:

   [ ] Not indicated

   [ ] Experimental

   [ ] Informational

   [ ] Proposed Standard

   [ ] Draft Standard

   [ ] Internet Standard

   [X] Best Current Practice

   However, the status as defined in [R6.BCP9] should be:

   [ ] Experimental (typically denotes a specification that is part of
   some research or development effort, subject only to editorial
   considerations and to verification that there has been adequate
   coordination with the standards process)

   [X] Informational (published for the general information of the
   Internet community, does not represent an Internet community
   consensus or recommendation, subject only to editorial
   considerations and to verification that there has been adequate
   coordination with the standards process)

   [ ] Proposed Standard (generally stable, has resolved known design
   choices, is believed to be well-understood, has received
   significant community review, appears to enjoy enough community
   interest to be considered valuable, has no known technical
   omissions)

   [ ] Draft Standard (at least two independent and fully interoperable
   implementations from different code bases have been developed,
   sufficient successful operational experience has been obtained,
   unused options and features have been removed, well-understood,
   known to be quite stable both in its semantics and as a basis for
   developing an implementation, must have been Proposed Standard
   for at least six months)

   [ ] Internet Standard (significant implementation and successful
   operational experience has been obtained, characterized by a high
   degree of technical maturity and by a generally held belief that
   the specified protocol or service provides significant benefit to
   the Internet community, must have been Draft Standard for at
   least four months)

   [ ] Historic (A specification that has been superseded by a more
   recent specification or is for any other reason considered to be
   obsolete, must have been Standards Track)

   [ ] Best Current Practice (a way to standardize practices and the
   results of community deliberations, subject to the same basic set
   of procedures as standards track documents, the community's best
   current thinking on a statement of principle or on what is
   believed to be the best way to perform some operations or IETF
   process function, common guidelines for policies and operations
   which are generally different in scope and style from protocol
   standards, not well suited to the phased roll-in nature of the
   three stage standards track and instead generally only make sense
   for full and immediate instantiation)

   [ ] None of the a

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

[Tony Finch]

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
exploited an open proxy on our network to send spam; they evaded our port
25 block by using an unauthenticated outgoing SMTP relay. This attack was
easy for us to stop because they discovered the relay by looking up our MX
record; our MXs now handle incoming email only, and our outgoing relays
have an obscure name which makes them difficult enough to discover that
spammers don't bother. We are also moving our users to securely
authenticated message submission so the relays can be more thoroughly
locked down.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

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

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

[Dean Anderson]

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 any "holes", nor does it improve up-stream
accountability.  Neither open relays nor lack of email authentication are
problems that are exploited by spammers.

All the BCP does is propogate myths that have never held up to analysis.
And somewhat worse, the BCP propogates these myths by assumption, without
discussion or analysis that reveals the fallacies of those myths.

So, this BCP should be rejected.

--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

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

[Dave Crocker]

>  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 legitimate
>  companies

I am not sure how this line of discussion relates to the proposed BCP, but
indeed discussions about spam need to distinguish between real companies that
are too aggressive, versus the folks that might politely be called rogue but
more usefully called criminal.  (Independent of whether they break laws, all of
their behaviors are that of a criminal, in terms of trying to bypass filters and
avoid accountability.)

Real companies need real and appropriate rules.  We might not like these
companies, but we can bring them under control.

Criminals, of course, need different methods.


So an attempt to bring this thread into some relevance for the Last Call:

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.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Dean Anderson]

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-SPAM merely requires a postal address, phone number, unsubscribe URL 
and no forged headers. Its harder to automatically identify commercial 
bulk email, and so harder to count how much of "spam" is really CBE, and 
how much is just non-commercial annoyance.  Enter SPF:

Bulk commercial emailers jumped on the SPF bandwagon on the assumption
that SPF would mean their email would be subjected to fewer tests.  
People monitoring SPF records support noticed this, and reported it.  
Temporarily, this gave a fairly good label for commercial bulk email. It
was found that about 6% of SPAM was SPF-PASS.  So, it may very well be
that as much as 94% of what we call "spam" is non-commercial annoyance
rather that genuine commercial bulk email.  I had previously thought that
frauds and junk was probably a high percentage, but not that high.

It gives further credence to the view that we have an "pretend spam"/fraud
abuse problem, not commercial bulk email problem.


But some people would complain about genuine CBE, anyway. Although you
hear less of it today, the view of many more radical antispammers is that
spam (Commercial Bulk Email, ie Bloomingdales, etc) needs to be banned
completely. One of the early "spam" complaints is about Network Solutions
sending CBE to its domain registry subscribers. Today, many wouldn't think
that abuse, because the recipients were the customers of Network
Solutions.  

--Dean


On Thu, 16 Jun 2005, Nicholas Staff wrote:

> 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 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 legitimate companies 
> so if we got rid of the frauds we would have effectively reduced spam by 99% 
> (by no means is that percentage anything more than a rough approximate 
> estimate).
> 
> Best regards,
> 
> Nick Staff
> 
> 
> Original post:
> 
> 
> 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 proportions 
> are certainly nothing like spam.  Why the difference?  Well first I split 
> spam into 2 categories:
> 
> 1.  legitimate advertisements for legitimate products (whether solicited or 
> unsolicited).
> 2.  Fraudulent mail, scams, cons, etc.
> 
> I think the email abusers almost entirely fall into the second category and 
> that nobody would be complaining if spam primarily consisted of 
> Bloomingdale's catalogues and coupon val-paks.
> 
> So I think we are attacking things the wrong way.  The methods we are 
> using - whether blacklists or 'authorized email' is going to either prove 
> fruitless or end up ruining the big picture, which for me is electronic 
> communication for everyone, to everyone.  Using electronic means, I don't 
> see how we can ever prevent spam and still have open global communication 
> among disparate systems.  It would be a different story if one organization 
> ran all email servers worldwide but that horrible thought aside there will 
> always be holes and breaks in an authentication/authorization scheme unless 
> people limit who they can communicate with, and even then there will be 
> spam.
> 
> There's also the returns we see on our efforts to consider.  Think of the 
> millions of man/woman hours spent trying to stop spam - so many hours it 
> probably would have taken less to inspect every email by hand.  And then 
> when you think (if you believe as I do) that everything can be gotten around 
> and that security holes are as infinite as the imagination, well then you 
> know there will always be some kid with a script (which also includes any 
> real spammer) who will be able to get around your defenses within a week of 
> them being implemented.
> 
> My last unconstructive comment is that simple systems scale lossless and 
> complex systems grow in a complexity proportionate to their size.
> 
> Funny enough, I think the postal inspector's department came about because 
> of the amount of scams being sent via mail shortly after the civil war (such 
> a glut that it was bringing the postal service to their knees).  Yet the 
> postal service remained open-relay - why?  Ma

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

[Dean Anderson]

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 person "posting" (anon or not) - eg the post-office gets 
> paid _before_ your letter gets delivered.  The problem with spam is that the 
> receipient is "paying" the cost (cod with no chance to refuse delivery)...

This "spammers don't pay" claim isn't true, except for viruses.  This myth
was first leveled against Cyberpromo and others in the 1990s. But
Cyberpromo (and the others)  frequently had T1 connections that they paid
for.  We occasionally hear of "pink contracts" that spammers presumably
pay more for.  Commercial bulk emailers have always paid at least as much
as everyone else. Sometimes more.

Second, junk postal mail costs the recipient much, much more in time and
trash handling, landfills, and garbage pickup than spam does.  Both sender
and receiver incur expenses with postal junk mail. An the case of postal
mail, bulk mailers pay substantially _less_ than everyone else. Regular
people pay 37 cents. I think bulk mail is still at 15 cents (it could be
higher now).  But even if the bulk mail rates are higher now, they are
less than 37 cents.  Imagine if we were to charge commercial bulk emailers
less for their internet service.

Third, for the case where viruses are used, the spam problem exists but
pales in comparison to the problems of distributed DOS attacks, extortion
of various sorts, and other criminal activity and mischief available to
the virus operator.  That they are "spamming on someone else's dime" is
the least of the worries with a virus/botnet.



-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

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

[Brian E Carpenter]

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


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

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

[Nicholas Staff]

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 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 legitimate companies 
so if we got rid of the frauds we would have effectively reduced spam by 99% 
(by no means is that percentage anything more than a rough approximate 
estimate).

Best regards,

Nick Staff


Original post:


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 proportions 
are certainly nothing like spam.  Why the difference?  Well first I split 
spam into 2 categories:

1.  legitimate advertisements for legitimate products (whether solicited or 
unsolicited).
2.  Fraudulent mail, scams, cons, etc.

I think the email abusers almost entirely fall into the second category and 
that nobody would be complaining if spam primarily consisted of 
Bloomingdale's catalogues and coupon val-paks.

So I think we are attacking things the wrong way.  The methods we are 
using - whether blacklists or 'authorized email' is going to either prove 
fruitless or end up ruining the big picture, which for me is electronic 
communication for everyone, to everyone.  Using electronic means, I don't 
see how we can ever prevent spam and still have open global communication 
among disparate systems.  It would be a different story if one organization 
ran all email servers worldwide but that horrible thought aside there will 
always be holes and breaks in an authentication/authorization scheme unless 
people limit who they can communicate with, and even then there will be 
spam.

There's also the returns we see on our efforts to consider.  Think of the 
millions of man/woman hours spent trying to stop spam - so many hours it 
probably would have taken less to inspect every email by hand.  And then 
when you think (if you believe as I do) that everything can be gotten around 
and that security holes are as infinite as the imagination, well then you 
know there will always be some kid with a script (which also includes any 
real spammer) who will be able to get around your defenses within a week of 
them being implemented.

My last unconstructive comment is that simple systems scale lossless and 
complex systems grow in a complexity proportionate to their size.

Funny enough, I think the postal inspector's department came about because 
of the amount of scams being sent via mail shortly after the civil war (such 
a glut that it was bringing the postal service to their knees).  Yet the 
postal service remained open-relay - why?  Maybe because they realized that 
they didn't need to 'trace' scam-mail because scams are trace-inclusive as 
the scammer must include a point of contact.  Sure there's the occasional 
anonymous letter bomb but since their resources aren't spent blocking coupon 
mailers they are much more likely to catch the big stuff.

I know there are 8 trillion problems with this idea but I think in general, 
email fraud needs to become like mail fraud and there needs to be a team of 
inspectors who follow up on such reports and arrest violators (I know the 
Internet is bigger than the US, so of course it's up to each country how to 
handle it).  I'm sorry for the non-technical post but I think blacklists are 
disgusting (I don't care if they help or not) and I just think so much 
brilliance could be directed elsewhere.

Thanks and best regards,

Nick Staff
[EMAIL PROTECTED]

-- Original message -- 
> >  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 working fine for its intended purpose.

> One needs to be careful not to dismiss established techniques in favor of 
> the
> latest fashionable one that is not as well fully understood.

I don't know what you mean by "relatively recent", but I was doing it at 
least
as early as April 1999 - that's the last mod date on my source files.  RFC 
2554
only dates from March 1999.

> For example, rate limiting is used to control a single source. It's quite
useful
> when used at the destination. At a sufficiently well-run source network, 
> it
also
> can be pretty useful.

It's also pretty useful for preventing a relay from being exploited by 
spammers.

> The problem is with zo

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

[nick . staff]

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 there'd be at least some spill-over (companies that once in awhile shelled out the bucks or defrauded the post office using tampered stamp machines which some snail-mail advertising companies have done to the tune of $20 million).  Since I've never been offered herbal viagra or a piece of Nigeria via the post office I have to assume there's yet another reason.  Am I right, how could I know, that's why this is just food for thought if you will.
--Best regards, 
Nick Staff
[EMAIL PROTECTED]
-- Original message -- 
> 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 > receipient is "paying" the cost (cod with no chance to refuse delivery)... > > -- > Larry Smith > SysAd ECSIS.NET > [EMAIL PROTECTED] > > > On Thursday 16 June 2005 21:50, [EMAIL PROTECTED] wrote: > > 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 > > proportions are certainly nothing like spam. Why the difference? Well > > first I split spam into 2 categories: 1. legitimate advertisements for > > legitimate products (whether solicited or unsolicited). 2. Fraudulent > > mail, scams, cons, etc. > > I think the email abusers almost entirely fall into the second category and > > that nobody would be complaining if spam primarily consisted of > > Bloomingdale's catalogues and coupon val-paks. So I think we are attacking > > things the wrong way. The methods we are using - whether blacklists or > > 'authorized email' is going to either prove fruitless or end up ruining the > > big picture, which for me is electronic communication for everyone, to > > everyone. Using electronic means, I don't see how we can ever prevent spam > > and still have open global communicat!
 ion among disparate systems. It would > > be a different sto
ry if one organization ran all email servers worldwide > > but that horrible thought aside there will always be holes and breaks in an > > authentication/authorization scheme unless people limit who they can > > communicate with, and even then there will be spam. There's also the > > returns we see on our efforts to consider. Think of the millions of > > man/woman hours spent trying to stop spam - so many hours it probably would > > have taken less to inspect every email by hand. And then when you think > > (if you believe as I do) that everything can be gotten around and that > > security holes are as infinite as the imagination, well then you know there > > will always be some kid with a script (which also includes any real > > spammer) who will be able to get around your defenses within a week of them > > being implemented. My last unconstructive comment is that s!
 imple systems > > scale lossless and complex systems grow in a complexity proportionate to > > their size. Funny enough, I think the postal inspector's department came > > about because of the amount of scams being sent via mail shortly after the > > civil war (such a glut that it was bringing the postal service to their > > knees). Yet the postal service remained open-relay - why? Maybe because > > they realized that they didn't need to 'trace' scam-mail because scams are > > trace-inclusive as the scammer must include a point of contact. Sure > > there's the occasional anonymous letter bomb but since their resources > > aren't spent blocking coupon mailers they are much more likely to catch the > > big stuff. I know there are 8 trillion problems with this idea but I think > > in general, email fraud needs to become like mail fraud and there needs to > > !
 be a team of inspectors who follow up on such reports and arrest viola
tors > > (I know the Internet is bigger than the US, so of course it's up to each > > country how to handle it). I'm sorry for the non-technical post but I > > think blacklists are disgusting (I don't care if they help or not) and I > > just think so much brilliance could be directed elsewhere. Thanks and best > > regards, > > Nick Staff > > [EMAIL PROTECTED] > > -- Original message -- > > > > > > 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. Thou

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

[Larry Smith]

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 
receipient is "paying" the cost (cod with no chance to refuse delivery)...

-- 
Larry Smith
SysAd ECSIS.NET
[EMAIL PROTECTED]


On Thursday 16 June 2005 21:50, [EMAIL PROTECTED] wrote:
> 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
> proportions are certainly nothing like spam.  Why the difference?  Well
> first I split spam into 2 categories: 1.  legitimate advertisements for
> legitimate products (whether solicited or unsolicited). 2.  Fraudulent
> mail, scams, cons, etc.
> I think the email abusers almost entirely fall into the second category and
> that nobody would be complaining if spam primarily consisted of
> Bloomingdale's catalogues and coupon val-paks. So I think we are attacking
> things the wrong way.  The methods we are using - whether blacklists or
> 'authorized email' is going to either prove fruitless or end up ruining the
> big picture, which for me is electronic communication for everyone, to
> everyone.  Using electronic means, I don't see how we can ever prevent spam
> and still have open global communication among disparate systems.  It would
> be a different story if one organization ran all email servers worldwide
> but that horrible thought aside there will always be holes and breaks in an
> authentication/authorization scheme unless people limit who they can
> communicate with, and even then there will be spam. There's also the
> returns we see on our efforts to consider.  Think of the millions of
> man/woman hours spent trying to stop spam - so many hours it probably would
> have taken less to inspect every email by hand.  And then when you think
> (if you believe as I do) that everything can be gotten around and that
> security holes are as infinite as the imagination, well then you know there
> will always be some kid with a script (which also includes any real
> spammer) who will be able to get around your defenses within a week of them
> being implemented. My last unconstructive comment is that simple systems
> scale lossless and complex systems grow in a complexity proportionate to
> their size. Funny enough, I think the postal inspector's department came
> about because of the amount of scams being sent via mail shortly after the
> civil war (such a glut that it was bringing the postal service to their
> knees).  Yet the postal service remained open-relay - why?  Maybe because
> they realized that they didn't need to 'trace' scam-mail because scams are
> trace-inclusive as the scammer must include a point of contact.  Sure
> there's the occasional anonymous letter bomb but since their resources
> aren't spent blocking coupon mailers they are much more likely to catch the
> big stuff. I know there are 8 trillion problems with this idea but I think
> in general, email fraud needs to become like mail fraud and there needs to
> be a team of inspectors who follow up on such reports and arrest violators
> (I know the Internet is bigger than the US, so of course it's up to each
> country how to handle it).  I'm sorry for the non-technical post but I
> think blacklists are disgusting (I don't care if they help or not) and I
> just think so much brilliance could be directed elsewhere. Thanks and best
> regards,
> Nick Staff
> [EMAIL PROTECTED]
> -- Original message --
>
> > >  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 working fine for its intended
> purpose.
>
> > One needs to be careful not to dismiss established techniques in favor of
> > the latest fashionable one that is not as well fully understood.
>
> I don't know what you mean by "relatively recent", but I was doing it at
> least as early as April 1999 - that's the last mod date on my source files.
>  RFC 2554 only dates from March 1999.
>
> > For example, rate limiting is used to control a single source. It's quite
>
> useful
>
> > when used at the destination. At a sufficiently well-run source network,
> > it
>
> also
>
> > can be pretty useful.
>
> It's also pretty useful for preventing a relay from being exploited by
> spammers.
>
> > The problem is with zombies.  They make mush of old-time models of spam,
> > since they demonstrate that a very small data stream from a single source
> > can be leve

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

[nick . staff]

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 proportions are certainly nothing like spam.  Why the difference?  Well first I split spam into 2 categories:
1.  legitimate advertisements for legitimate products (whether solicited or unsolicited).2.  Fraudulent mail, scams, cons, etc.
I think the email abusers almost entirely fall into the second category and that nobody would be complaining if spam primarily consisted of Bloomingdale's catalogues and coupon val-paks.
So I think we are attacking things the wrong way.  The methods we are using - whether blacklists or 'authorized email' is going to either prove fruitless or end up ruining the big picture, which for me is electronic communication for everyone, to everyone.  Using electronic means, I don't see how we can ever prevent spam and still have open global communication among disparate systems.  It would be a different story if one organization ran all email servers worldwide but that horrible thought aside there will always be holes and breaks in an authentication/authorization scheme unless people limit who they can communicate with, and even then there will be spam.
There's also the returns we see on our efforts to consider.  Think of the millions of man/woman hours spent trying to stop spam - so many hours it probably would have taken less to inspect every email by hand.  And then when you think (if you believe as I do) that everything can be gotten around and that security holes are as infinite as the imagination, well then you know there will always be some kid with a script (which also includes any real spammer) who will be able to get around your defenses within a week of them being implemented.
My last unconstructive comment is that simple systems scale lossless and complex systems grow in a complexity proportionate to their size.
Funny enough, I think the postal inspector's department came about because of the amount of scams being sent via mail shortly after the civil war (such a glut that it was bringing the postal service to their knees).  Yet the postal service remained open-relay - why?  Maybe because they realized that they didn't need to 'trace' scam-mail because scams are trace-inclusive as the scammer must include a point of contact.  Sure there's the occasional anonymous letter bomb but since their resources aren't spent blocking coupon mailers they are much more likely to catch the big stuff.
I know there are 8 trillion problems with this idea but I think in general, email fraud needs to become like mail fraud and there needs to be a team of inspectors who follow up on such reports and arrest violators (I know the Internet is bigger than the US, so of course it's up to each country how to handle it).  I'm sorry for the non-technical post but I think blacklists are disgusting (I don't care if they help or not) and I just think so much brilliance could be directed elsewhere.
Thanks and best regards,
Nick Staff
[EMAIL PROTECTED]-- Original message -- > >  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 working fine for its intended purpose.

> One needs to be careful not to dismiss established techniques in favor of the 
> latest fashionable one that is not as well fully understood.

I don't know what you mean by "relatively recent", but I was doing it at least
as early as April 1999 - that's the last mod date on my source files.  RFC 2554
only dates from March 1999.

> For example, rate limiting is used to control a single source. It's quite 
useful 
> when used at the destination. At a sufficiently well-run source network, it 
also 
> can be pretty useful.

It's also pretty useful for preventing a relay from being exploited by spammers.
 
> The problem is with zombies.  They make mush of old-time models of spam, since 
> they demonstrate that a very small data stream from a single source can be 
> leveraged into a very, very large data stream, given enough sources. 

Rate limiting of this type (based on source IP address), if done properly, 
doesn't 
help or hurt zombies.  The rates need to be set such that zombies can send 
directly
to the recipients' MXes as easily, and more reliably, as they can send the same 
mail via the rate limiting SMTP servers.

> One can start imagining more complex rate-limiting models, but then we would 
be 
> talking about research efforts.  A BCP is not supposed to rely on research, 
> especially when it hasn't been done.  

Maybe you should stick to talking about things that you know som

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

[Dean Anderson]

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.
> Yes, it isn't a very large proportion of our total volume, but I would
> expect that to change rapidly if the probes were successful.

Yes, indeed. It will change if the probes are successful. But it is easy
figure out who is doing the probes. Open relay probing requires an valid
emailbox. So just queue up the probes, identify the blacklist (its usually
something like relaytest@). In the rare case it is not plainly
a blacklist, send in an abuse report on the destination emailbox.

Another technique is to run non-production open relays, let them be
scannned, and see what blacklists the relays turn up on, and then start
blocking (and reporting) any IPs that try to connect to the non-production
relays.  

Anti-spammers also scan the /24 around any known open relay before abuse.
This behavior started shortly after I reported that I could identify abuse
with the specific blacklist that was promoting the abuse. I did this by
adding different non-production relays to different blacklists, and then
tracking the IPs and spams that came through.  After that, they started to
scan the /24 immediately before abuse to obscure which blacklist was doing
the abuse.  If you have enough address space, you can still conduct the
tests with each relay on a different /24. After that, they started
claiming that 130.105/16 was stolen.

> > You said it is more prevalent on hosts named mail or smtp---one would at
> > minumum need a list of domains to search. Where do you suppose they
> > obtained this list?
> 
> Where do you suppose they get lists of email addresses to send spam to?

That's not the same thing. Most of those lists have AOL and MSN and the
top 50 or 100 or so domains. I have the spam email lists, too. The email
addresses show up in my logs and the block email messages' envelope
recipient lines [RP.*FD in sendmail]. That doesn't give them enough to
find very many open relays by simply adding mail or smtp to the domain
names from a list of email addresses.

Open relay abuse just doesn't scale. Too much searching, too few relays.

> > Who is doing this searching?  Internal viruses?
> 
> The probes are external, and appear to be mostly from compromised home
> computers. Our network is reasonably well managed and infections are
> quashed promptly.
> 
> > What sort of commercial companies are abusing your open relays?
> 
> You misunderstand: We don't operate open relays, but despite your claims
> about the rareness of open relay abuse, our email servers are frequently
> probed with open relay attacks. I believe you are depending on security
> through obscurity to avoid attack. One of our main outgoing relay services
> has an obscure name (ppsw.cam.ac.uk) and is probed 100 times less
> frequently than our MXs or our MSA service named smtp.hermes.cam.ac.uk.

Well, script kiddies may do many odd things. Further, if you aren't
running open relays, how do you know for certain that it's not just
misconfigured clients?  "Relaying denied" is a frequent problem
experienced by real customers who aren't spammers.

Adding mail or smtp to a domain is probably something your legitimate
users are doing, trying to figure out how to relay remotely. Very likely,
this represents the number of legitimate mails your users would like to
'open relay.'

> > You also haven't shown that the abusers would be prevented from emailing
> > if open relays were closed.
> 
> That's irrelevant: it's still my responsibility not to abet them.

I'm not "abetting" them.  They send email no matter what. They didn't get
anything they don't already have.  And in practice, its the anti-spammers
who are abusing open relays (to teach us a lesson), not real bulk
commercial emailers.


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

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

[Dean Anderson]

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 applicability.

I tried a "rate limiting" freeware a couple years ago. It didnt' work,
largely due to very poor programming. It had no locking. The programmers
didn't seem to understand that the program could be invoked
simultaneously. It worked only so long as there was only one message at a
time, a rate so slow as to not require rate limiting.

But abusers do look and behave differently from regular users.  This can
be exploited to some extent.  Slow queues that wait for an abuse pattern,
and so forth.  But the best thing is to just block the blacklists from 
scanning. And the techniques I just described to Tony Finch.

> The problem is with zombies.  They make mush of old-time models of spam, since
> they demonstrate that a very small data stream from a single source can be
> leveraged into a very, very large data stream, given enough sources.

It is interesting that the most recent "email authentication" scheme (SPF)
asists the zombies by identifying the ISP's (possibly closed) outgoing
relays. If the ISP happens to block port 25, which may be attractive to
residential ISPs which also happen to have the most zombies, then the
zombie needs to use the ISPs relays.  Finding that relay for a thousand
different mail clients is a chore, and would have to be performed by a
severely limited virus payload. But along comes SPF, and identifies those
relays for the zombie.  Foot, gun, trigger. Or perhaps SPF was more
intentional, and also happened to be a great source of money.

> I don't know how much experience you have trying to do such tracing, but the
> spamops folks have made quite clear that it is both vastly more effort and
> considerably less productive, than one might expect.  Again, there is no way
> that relying on that is a reasonable best practise on the current Internet.  
> As
> a small example, not that spammers now are stealing IP Address blocks.  That
> pretty much kills backtrace accountability.

The spamops folks are frequently unreasonable in this respect. They have
asserted, for example, that one cannot trust _any_ mail headers.  They
expect _immediate_ results. Those are just unreasonable demands.  No ISP
is going to cancel a users account on the say-so of some unreasonable
anti-spammer, who (as a group) are already well-known for outright lying,
revenge, and defamation.

Tracking a spam zombie requires a bit of patience and persistence. There
is nothing that will make that easier, except perhaps a standard abuse
submission protocol (which I proposed back in 1999).

> >  unfortunately, the vigilante character of various open-relay blacklists
> 
> blacklists are not the subject of this BCP.

Its couched in terms to avoid that, and just assumes the blacklists claims
about open relays are right.

> >  killed any attempt at this kind of innovation.  just as we're now in
> >  danger of various kinds of brain-dead "authentication" methods and
> >  meaningless requirements killing useful email functionality.
> 
> new authentication methods are not the subject of this BCP.

It doesn't specify a specific method. It just says that email
authetication should be used.

--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   




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

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

[Dave Crocker]

>  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



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

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

[Keith Moore]

> >  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 working fine for its intended purpose.

> One needs to be careful not to dismiss established techniques in favor of the 
> latest fashionable one that is not as well fully understood.

I don't know what you mean by "relatively recent", but I was doing it at least
as early as April 1999 - that's the last mod date on my source files.  RFC 2554
only dates from March 1999.

> For example, rate limiting is used to control a single source. It's quite 
> useful 
> when used at the destination. At a sufficiently well-run source network, it 
> also 
> can be pretty useful.

It's also pretty useful for preventing a relay from being exploited by spammers.
 
> The problem is with zombies.  They make mush of old-time models of spam, 
> since 
> they demonstrate that a very small data stream from a single source can be 
> leveraged into a very, very large data stream, given enough sources. 

Rate limiting of this type (based on source IP address), if done properly, 
doesn't 
help or hurt zombies.  The rates need to be set such that zombies can send 
directly
to the recipients' MXes as easily, and more reliably, as they can send the same 
mail via the rate limiting SMTP servers.

> One can start imagining more complex rate-limiting models, but then we would 
> be 
> talking about research efforts.  A BCP is not supposed to rely on research, 
> especially when it hasn't been done.  

Maybe you should stick to talking about things that you know something about.

> >  block spam.  the goal of such relays is to make it at least as easy for
> >  the spammer to simply contact the appropriate MXes for the destination
> >  addresses as to use the relays.  of course it is necessary for such
> >  relays to record source IP addresses, etc., so that they are as
> >  traceable to their origin as messages sent directly to MXes.
> 
> I don't know how much experience you have trying to do such tracing, but the 
> spamops folks have made quite clear that it is both vastly more effort and 
> considerably less productive, than one might expect. 

That's a problem with mail relaying in general, not just with open relays.
Now if you want to discourage multi-hop mail relaying, that might actually be
useful for lots of reasons besides just traceability.

> >  unfortunately, the vigilante character of various open-relay blacklists
> 
> blacklists are not the subject of this BCP.

This thread has pretty much diverged from the subject of your draft
document anyway.

> >  killed any attempt at this kind of innovation.  just as we're now in
> >  danger of various kinds of brain-dead "authentication" methods and
> >  meaningless requirements killing useful email functionality.
> 
> new authentication methods are not the subject of this BCP.

You mean "your draft document".  It's certainly not a BCP as it's 
currently written.

Keith

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

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

[Ned Freed]

> 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 at least rate limiting has been a popular
technique to use for at least five years, and has been in use at some sites for
a lot longer. However, I see it used mostly in two ways:

(1) To limit the amount of damage a local zombie can do.
(2) To limit incoming spam.

I've been tempted to try and write a document about rate limiting, but the
problem is most of the information I have about its effectiveness (or lack
thereof) is anecdotal in nature. Such a document really needs to be developed
by folks with substantial experience using the technique on a large site over a
number of years, and even then I don't think you're going to get an analysis of
its relevance to operating open relays.

> One needs to be careful not to dismiss established techniques in favor of the
> latest fashionable one that is not as well fully understood.

The problem with rate limiting isn't that it isn't well understood, for some
class of attacks at least. Rather, the problem is, as you indicate below, the
nature of the threat continues to evolve, and the way it has evolved has made
rate limiting less useful, for sure when it comes to blocking incoming spam. It
remains useful in limiting damage from local zombies, mostly because these
still tend to send lots of messages very quickly.

> For example, rate limiting is used to control a single source. It's quite 
> useful
> when used at the destination. At a sufficiently well-run source network, it 
> also
> can be pretty useful.

Exactly.

> The problem is with zombies.  They make mush of old-time models of spam, since
> they demonstrate that a very small data stream from a single source can be
> leveraged into a very, very large data stream, given enough sources.

Zombies are indeed the problem, but it breaks down into two cases, one where
the zombies you're trying to deal with are your own systems (or your customer's
systems), and another where the zombies are elsewhere and are targetting you.
Rate control, especially rare control with notification, is still pretty
effective at dealing with local zombies.

However, I fear that use of rate limiting to allow open relaying is more
cloesely aligned with the second case.

> One can start imagining more complex rate-limiting models, but then we would 
> be
> talking about research efforts.  A BCP is not supposed to rely on research,
> especially when it hasn't been done.

The rate limit stuff I see in use is an odd mixture of sophistication and
simplicity. For example, it is common to see limits applied at multiple levels,
that is, there may be a limit on recipients per transaction, a limit on
transaction per session, and finally a rate limit on incoming sessions.

However, it is often the case that rate limit information isn't shared all that
well between mutlple systems. I also don't see careful analysis of the effect
of rate limits being done, although that may be more due  to folks keeping
their results to themselves than anything else.

> Besides that, note my comment above about "sufficiently well-run source 
> network"
> is clearly not possible when the network accepts mail without accountability 
> of
> the submitter.  In other words, an open relay.

Agreed.

> >  block spam.  the goal of such relays is to make it at least as easy for
> >  the spammer to simply contact the appropriate MXes for the destination
> >  addresses as to use the relays.  of course it is necessary for such
> >  relays to record source IP addresses, etc., so that they are as
> >  traceable to their origin as messages sent directly to MXes.

> I don't know how much experience you have trying to do such tracing, but the
> spamops folks have made quite clear that it is both vastly more effort and
> considerably less productive, than one might expect.  Again, there is no way
> that relying on that is a reasonable best practise on the current Internet.  
> As
> a small example, not that spammers now are stealing IP Address blocks.  That
> pretty much kills backtrace accountability.

This is another case where I have only anecdotal information - I may write the
software but I don't run a large site that uses it - but the information I have
agrees with your assessment.

Ned

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

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

[Dave Crocker]

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 established techniques in favor of the
latest fashionable one that is not as well fully understood.

For example, rate limiting is used to control a single source. It's quite useful
when used at the destination. At a sufficiently well-run source network, it also
can be pretty useful.

The problem is with zombies.  They make mush of old-time models of spam, since
they demonstrate that a very small data stream from a single source can be
leveraged into a very, very large data stream, given enough sources.

One can start imagining more complex rate-limiting models, but then we would be
talking about research efforts.  A BCP is not supposed to rely on research,
especially when it hasn't been done.

Besides that, note my comment above about "sufficiently well-run source network"
is clearly not possible when the network accepts mail without accountability of
the submitter.  In other words, an open relay.


>  block spam.  the goal of such relays is to make it at least as easy for
>  the spammer to simply contact the appropriate MXes for the destination
>  addresses as to use the relays.  of course it is necessary for such
>  relays to record source IP addresses, etc., so that they are as
>  traceable to their origin as messages sent directly to MXes.

I don't know how much experience you have trying to do such tracing, but the
spamops folks have made quite clear that it is both vastly more effort and
considerably less productive, than one might expect.  Again, there is no way
that relying on that is a reasonable best practise on the current Internet.  As
a small example, not that spammers now are stealing IP Address blocks.  That
pretty much kills backtrace accountability.


>  unfortunately, the vigilante character of various open-relay blacklists

blacklists are not the subject of this BCP.


>  killed any attempt at this kind of innovation.  just as we're now in
>  danger of various kinds of brain-dead "authentication" methods and
>  meaningless requirements killing useful email functionality.

new authentication methods are not the subject of this BCP.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Tony Finch]

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 total volume, but I would
expect that to change rapidly if the probes were successful.

> You said it is more prevalent on hosts named mail or smtp---one would at
> minumum need a list of domains to search. Where do you suppose they
> obtained this list?

Where do you suppose they get lists of email addresses to send spam to?

> Who is doing this searching?  Internal viruses?

The probes are external, and appear to be mostly from compromised home
computers. Our network is reasonably well managed and infections are
quashed promptly.

> What sort of commercial companies are abusing your open relays?

You misunderstand: We don't operate open relays, but despite your claims
about the rareness of open relay abuse, our email servers are frequently
probed with open relay attacks. I believe you are depending on security
through obscurity to avoid attack. One of our main outgoing relay services
has an obscure name (ppsw.cam.ac.uk) and is probed 100 times less
frequently than our MXs or our MSA service named smtp.hermes.cam.ac.uk.

> You also haven't shown that the abusers would be prevented from emailing
> if open relays were closed.

That's irrelevant: it's still my responsibility not to abet them.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

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

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

[Keith Moore]

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 consensus has been in place for quite a few years.


sometimes rough consensus is wrong, particularly when it hasn't resulted 
from informed, intelligent dialogue.  another way to put it is that 
sometimes rough consensus is indistinguishable from blind prejudice.


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 
block spam.  the goal of such relays is to make it at least as easy for 
the spammer to simply contact the appropriate MXes for the destination 
addresses as to use the relays.  of course it is necessary for such 
relays to record source IP addresses, etc., so that they are as 
traceable to their origin as messages sent directly to MXes.


unfortunately, the vigilante character of various open-relay blacklists 
killed any attempt at this kind of innovation.  just as we're now in 
danger of various kinds of brain-dead "authentication" methods and 
meaningless requirements killing useful email functionality.


The fact that attackers are not trying to exploit a particular weakness right 
now, although they used it heavily in the past, does not justify leaving the 
weakness in place.


this much is certainly true.

Keith

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

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

[Ned Freed]

> 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 place that may stop relay attempts before they
get to the "don't allow relaying" rule.

A cursory examination of the logs shows that most of the destination addresses
are ones I've never heard of. But there are also a fair number of addresses I
recognize as IETF people. Sure looks like somebody is tracking sender-recipient
pairs off of mailing list mail.

Mrochek.com probably qualifies as an obscure domain.

> 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.

Overall traffic is about 500 legit messages a day and a highly variable amount
of spam, but rarely less than a thousand spams and viruses a day.

I don't think I'll be making my home system an open relay any time soon...

Ned

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

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

[Dean Anderson]

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 smtp---one would at
minumum need a list of domains to search. Where do you suppose they
obtained this list?  Do you have a particularly well-known domain?

Who is doing this searching?  Internal viruses?  Perhaps your should
report it to the organizations doing the probing.

What sort of commercial companies are abusing your open relays?  We
haven't found any commercial advertising in open relay abuse in the 9
years that we've run open relays.

People should and do use open relay when it is necessary: When you have to
provide email services to persons and organizations outside your address
space.

You also haven't shown that the abusers would be prevented from emailing
if open relays were closed.  There are number of myths about open relays
that are debunked in http://www.av8.net/FTC.pdf which was submitted to the
FTC spamforum in 2003, after the FTC issued a press release against open
relays. The FTC didn't permit participation by open relay operators, and
an FTC lawyer supervising the forum even ridiculed John Gilmore.  
However, the FTC did allow known spammer Scott Richter to attend. It was
later learned that MAPS employees were working for Richter.  And the FTC
did use a blacklist called Osirusoft run by Joe Jared. Among other revenge
activity, Jared blacklisted his ex-girlfriend out of spite after the
relationship failed.  In spite of this incident, the FTC continued to use
the blacklist until it shutdown later in 2003, blacklisting the entire
world, and disrupting the email of all the blacklist subscribers,
including the FTC.

Part of the fallacy embodied in the open relay myth and also in the email
authentication jihad is that:

Every user has relay services until they are no longer a user. 

That includes viruses and spammers.  So why should it be anti-spam "best
practice" not to use open relays?  Open relays have nothing to do with
spam. They never have.

--Dean


On Thu, 16 Jun 2005, Tony Finch wrote:

> 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 similar volume of relay attempts occurs for machines
> named 'mail' or 'smtp'. More obscure mail hosts might see a more
> manageable number of attacks, but I still think it is valid for this draft
> to state that it is best practice that MTAs must not be configured for
> open relaying.
> 
> Tony.
> 

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000   



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

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

[Dave Crocker]

>  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 IS.


>  And lastly, it seems inappropriate that such a draft would be proposed
>  with language about open relays without seeking the input of open relay
>  operators such as Av8 Internet. Av8 Internet is one of the very few open
>  relay operators that is willing to publicly discuss these operations.

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 consensus has been in place for quite a few years.


>  Had anyone bothered to ask, I would have reported that open relay abuse

The fact that attackers are not trying to exploit a particular weakness right
now, although they used it heavily in the past, does not justify leaving the
weakness in place.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Tony Finch]

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 similar volume of relay attempts occurs for machines
named 'mail' or 'smtp'. More obscure mail hosts might see a more
manageable number of attacks, but I still think it is valid for this draft
to state that it is best practice that MTAs must not be configured for
open relaying.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR
GOOD.

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

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

[Dean Anderson]

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 possible by some other method, doesn't solve the
problem, since it is the equivalent of dialup problem:

Every user is authorized to send email until they aren't. 

Only their service provider can remove that authorization

And of course, it isn't just users who send email. Devices send email, 
too.

Service providers aren't complaining that they can't identify they users.  
Rather, the people frustrated by email authentication are the end user
recipients of spam. Email authentication isn't going to lessen that. Even
if it were do-able (and done), end-users and other carriers wouldn't have
access to the subscriber identity information.  And if they are your
subscriber, you usually don't have any lack of identity information given
a spam and its headers.

Service providers implementing protocols like SMTP-AUTH have not reported
that SMTP-AUTH results in less spam.  Just the opposite is usually the
case: No change.  

Email authentication isn't a weakness that is exploited by spammers.  
commercial bulk emailers are by and large compliant with the CAN-SPAM act.  
The CAN-SPAM Act has demonstrated a distinction between commercial bulk
emailers and abusers with no direct commercial purpose. (see
http://www.av8.net/SpamTypes.txt).  Abusers have been using viruses and
rooted computers to send abuse email. It is not the economics of
commercial bulk email, nor the lack of email authentication that is the
problem. It is the economics of anti-spam blacklists that shows that
"economic value" of virus/abuse "spam".  Blacklists such as SORBS are now
charging (extorting) money from both users and victims.

And lastly, it seems inappropriate that such a draft would be proposed
with language about open relays without seeking the input of open relay
operators such as Av8 Internet. Av8 Internet is one of the very few open
relay operators that is willing to publicly discuss these operations.  
Av8 has operated open relays since 1996 and has considerable experience
with abusers and the methods of protecting open relays from abuse. While
groups like Nanog have worked to suppress certain viewpoints
(http://www.iadl.org/nanog/nanog-story.html -- this page is not yet
finished, but I've made an early version available) it is still well-known
that I am willing to discuss the issues and have a lot of research to
support my views.

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. Previous testing of open relay blacklists had revealed that they
were involved in directly or indirectly supporting abuse, promoting abuse,
and even soliciting the abuse of open relays. Logs revealed that these
blacklists were the only groups systematically searching for open relays
to abuse, and that open relays were only abused after discovery by the 
open relay blacklists. 

I do note that open relay abuse has resumed slightly since SORBS.NET
started scanning for open relays in March 2005, but there are presently
only about 5 IP addressses abusing our relays, despite the well-known fact
that we operate open relays. In the past, we would sometimes see as many
as 2400 IP addresses trying to abuse our relays.  Nearly all of this abuse
is fairly trivially detected and blocked. Open relays do not present any
"problem" to be addressed.

I think the IETF should make more efforts to make sure that its
recommended best common practices are based on facts rather than myths.

Dean Anderson
Av8 Internet, Inc

=

   Best practices are:

   o  Operators of MSAs MUST perform authentication during mail
  submission, based on an existing relationship with the submitting
  entity.  This requirement applies to all mail submission
  mechanisms.

   o  For email being received from outside their local operational
  environment, email service operators MUST distinguish between mail
  that will be delivered inside that environment, from mail that is
  to be relayed back out to the Internet.  This allows the MTA to
  restrict this operation, preventing the problem embodied by "open"
  relays.

   o  Mail coming from outside an email operator's local environment,
  and having a RCPT-TO address that resolves to a destination that
  is also outside the local environment, MUST be treated as mail
  submission, rather than mail relaying.  Hence it must be subjected
  to mail submission authorization and validation checks.

   o  MDAs SHALL NOT accept mail to recipients for which that MDA has no
  arrangement to perform delivery.




-- 
Av8 Internet   

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

[Dave Crocker]

> > >  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.


indeed.  so it's probably a good thing that i said nothing to indicate that.

oh...

> The document is being offered to the IETF in the usual
> manner of an independent submission, for the usual manner
> of review and, if necessary, modification.

How about that.  I seem to have said exactly the opposite of what you
attribute to me.

but hey, thanks for continuing down such a constructive path.  we
wouldn't want to get bogged down in nit-picking attacks.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Dave Crocker]

>  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 others for one's views.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Dave Crocker]

>  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 slanderous claims about end-runs, and offering hypotheticals for
which there is no basis.

The document had quite a few, independent people contribute to it.  It has gone
through considerable evolution.  These are facts.  The form cites these facts.
Whether you think there needs to be more discussion and modification is fine,
but don't start looking for silly conspiracies.

The document is being offered to the IETF in the usual manner of an independent
submission, for the usual manner of review and, if necessary, modification.

Rather than nit-pick the form that was submitted or cast aspersions on our
motives, why not focus your considerable talents on constructive dialogue?


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[April Marine]

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 bogged down in nit-picking attacks.



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



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

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

[Keith Moore]

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.


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

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

[Dave Crocker]

> > >  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.


indeed.  so it's probably a good thing that i said nothing to indicate that.

oh...

> The document is being offered to the IETF in the usual
> manner of an independent submission, for the usual manner
> of review and, if necessary, modification.

How about that.  I seem to have said exactly the opposite of what you
attribute to me.

but hey, thanks for continuing down such a constructive path.  we
wouldn't want to get bogged down in nit-picking attacks.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Keith Moore]

> >  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.


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

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

[Keith Moore]

> 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 have a leg to stand on here.

If you want to fix your document, I'm all for it, and I believe that is the 
quickest
path to getting a useful document out the door.  But I will insist that it be 
fixed
and that the fixes get adequate review.  

Keith


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

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

[Dave Crocker]

>  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 others for one's views.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net





  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Dave Crocker]

>  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 slanderous claims about end-runs, and offering hypotheticals for
which there is no basis.

The document had quite a few, independent people contribute to it.  It has gone
through considerable evolution.  These are facts.  The form cites these facts.
Whether you think there needs to be more discussion and modification is fine,
but don't start looking for silly conspiracies.

The document is being offered to the IETF in the usual manner of an independent
submission, for the usual manner of review and, if necessary, modification.

Rather than nit-pick the form that was submitted or cast aspersions on our
motives, why not focus your considerable talents on constructive dialogue?


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Keith Moore]

> >  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 because it was not invited to do so, or perhaps because (to
those who were aware of the document) it seemed premature to do so.
It's not as if every I-D is worth reviewing, particularly in the early
stages.  A lot of I-Ds are abandoned by their authors without any 
attempt to publish them as RFCs.

> Your criteria for "end run" appear to be rather liberal, if not silly.
> 
> You wouldn't be trying to delay things, so as to somehow force 
> discussion of your now-competing document, would you?

I certainly want to encourage adequate review of whatever gets published
as an RFC.  As for "competing document", well at this stage it's not even an
I-D.  I consider it a contribution to the discussion.

Keith


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

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

[Dave Crocker]

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 the
>  ietf-smtp mailing list, and found exactly four mentions of that
>  document title or ID.

Multiple:  "Having, relating to, or consisting of more than one individual,
element, part, or other component; manifold."

Also, the statement carefully said "references" rather than discussion.  So the
statement makes no more than a minimal, and correct, claim.


>  While the claim in the status file is true on its face (there really
>  were multiple "references" to the document) one should not infer that
>  the document has actually been discussed on the ietf-smtp list, because

indeed.  one usually should not infer more than is said, particularly in a
formal document.


>  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.  That community chooses not to pursue the
matter.

Your criteria for "end run" appear to be rather liberal, if not silly.

You wouldn't be trying to delay things, so as to somehow force
discussion of your now-competing document, would you?

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Keith Moore]

> 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:
> 
>    
> 

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
ietf-smtp mailing list, and found exactly four mentions of that
document title or ID.

The first two mentions were a question about one particular aspect of
version -00 of that document, and one reply to that specific question.
These were one year ago.

The second two mentions of the spampos document were in a discussion 
of the SPF draft, and didn't actually discuss the spamops document.

While the claim in the status file is true on its face (there really
were multiple "references" to the document) one should not infer that
the document has actually been discussed on the ietf-smtp list, because
no significant discussion or review has taken place there.  In
particular, the ietf-smtp list does not seem to have been explicitly
asked to review the document, even though that is the de facto place to
discuss uses of and extensions to SMTP.

Frankly, it's hard to see this as other than an attempt at an "end run"
around the SMTP developer community.

Keith


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

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

[wayne]

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 had
the chance to re-read the draft and follow the ongoing discussions
here.

I completely agree with Daniel's comments and suggestions.  This is
fundementally a very good document and should be published as soon as
possible.


-wayne


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

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

[Daniel Senie]

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 is recommended". Let's face it, 
the SMTP AUTH options are driven from the referenced protocol documents 
(RFC2554).


Can we move on and get this document completed? Can we get the security 
folks to help work on the next generation of RFC2554? It's time to decouple 
that from a document that says "Use the Submission protocol so we can 
support customers who're roaming, and ensure we aren't also permitting spam 
relay."


What those of us operating networks would really like is a document like 
the one under consideration to point software vendors at and say "We as 
ISPs need you to support this so we can support your customers."



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

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

[Dave Crocker]

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:

  


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Dave Crocker]

> > >  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 said "local environment" and nothing about
> >  "network",  and it suddenly didn't seem so broken any more.
> >
>  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 substantiate the point.

What you are so winningly touting was not, as you indicate, a problem with the
text, but a problem with my use of a different term in this thread.




  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[David Hopwood]

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 niche has
outlived its usefulness, but if "The RECOMMENDED
alternatives..." include only things that are significantly more
complex or require significantly more infrastructure, there is
some reason to believe that they will go nowhere fast,
independent of any pronouncements the IETF chooses to make.


I am reminded of the following from secsh-architecture, in the context of how to
check the ssh host public key, and so authenticate the ssh host.

" The members of this Working Group believe that 'ease of use' is
   critical to end-user acceptance of security solutions, and no
   improvement in security is gained if the new solutions are not used.
   Thus, providing the option not to check the server host key is
   believed to improve the overall security of the Internet, even though
   it reduces the security of the protocol in configurations where it is
   allowed."

For me, this is sound engineering, imperfect but recognising the frailties of
the world, producing something that will be deployed. 


I am all in favour of usable security. All too often, however, "ease-of-use"
is used to justify security compromises, without even thinking about how a
higher level of security and a better user interface could be achieved
simultaneously. That is *not* sound engineering.


I apply the same logic  to MD5.


We know how to design password-based protocols that prevent session hijacking
and dictionary attacks, provide mutual authentication, and do not require
storing password-equivalent authenticators. It is not rocket science,
and it does not require any additional effort from the user. That's not
the problem; the problem is a lack of *concrete* deployable security
protocols that implement the known state of the art.

(TLS prevents session hijacking, but does not implement strong password
authentication. AFAIK, the nearest thing available is
.)

--
David Hopwood <[EMAIL PROTECTED]>


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

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

[Tom Petch]

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: Last Call: 'Email Submission Between Independent Networks' to BCP

>


> (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
> outlived its usefulness, but if "The RECOMMENDED
> alternatives..." include only things that are significantly more
> complex or require significantly more infrastructure, there is
> some reason to believe that they will go nowhere fast,
> independent of any pronouncements the IETF chooses to make.
>
>  john
>

I am reminded of the following from secsh-architecture, in the context of how to
check the ssh host public key, and so authenticate the ssh host.

" The members of this Working Group believe that 'ease of use' is
   critical to end-user acceptance of security solutions, and no
   improvement in security is gained if the new solutions are not used.
   Thus, providing the option not to check the server host key is
   believed to improve the overall security of the Internet, even though
   it reduces the security of the protocol in configurations where it is
   allowed."

For me, this is sound engineering, imperfect but recognising the frailties of
the world,
producing something that will be deployed.  I apply the same logic to MD5.



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

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

[JFC (Jefsey) Morfin]

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 accomplished by client possession and verification of
a server key or by an extra secret and handshake. That
would presumably be "good enough" unless we also have a
significant concern about sessions being hijacked once
they have been properly initiated. I don't know the
degree to which that is a practical concern (remember
that SMTP sessions, especially pipelined ones, are
typically pretty short and that, e.g., IMAP has
provisions for in-session reverification although I
believe they are still not intensively used).
Conversely, if the server identity is not verified, or
is verified only by the luser's receiving an
incomprehensible warning message and clicking "accept"
every time, then even encryption wouldn't seem to help
much.


Yes. This is why I rise the multimodal general issue (can be check-back 
procedure, parallel exchanges, multichannels, multitechnology, etc.). This 
also goes with a generalised usage of IPv6 (identification of a permanent 
address - I do not think the IPSEC is of interest here as one never knows 
about the real end to end path?).

jfc



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

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

[JFC (Jefsey) Morfin]

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
https://www1.ietf.org/mailman/listinfo/ietf

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

[Dave Crocker]

>  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 of the community attempt to get its work done, including
specifing security mechanisms as needed, and then have the security community
come in and take shots at it, is not the way to run a productive process.

In other words, the issue is not with the truth of your assertions but with the
timing and place of them.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[John C Klensin]

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 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 readily vunerable
>>  to dictionary attacks, there are other problems and the
>>  presence of encryption would pose an inconvenience, not
>>  an obstacle, for the attacker.
> 
> The strength of the encryption mechanism does not matter: if
> the algorithm has been crypto-analyzed, then the attacker can
> just proceed with a reverse computation. We don't know when a
> given algorithm will be broken, but we can suspect that any
> algorithm will be broken eventually. The reasonable design
> rule is thus to never hardcode a specific encryption or
> hashing algorithm in a protocol.
> 
> Even with a strong algorithm, the only effective protection
> against dictionary attacks is "key entropy", which determines
> the number of trials needed before finding a match. This
> number follows Moore's law: attackers with 2005 computers can
> attempt 100 times more trials than attackers of 1995. We have
> reached a point where "if an average user can remember the
> password, there is probably not enough entropy in it". 
> 
> If you use simple hash functions like MD5 or SHA, challenge
> response mechanisms are only OK if the shared secret contains
> at least as much entropy as a good symmetric key. Most experts
> will assume that if you can, you should use a randomly
> generated 128 bit key. In practice, provisioning such keys is
> hard.
> 
> If you must use a low entropy key, you may have a solution by
> picking a very slow encryption algorithm. Essentially, you
> would counter Moore's law by requiring more CPU for a single
> trial. For example, instead of using the simple SHA, you may
> want to iterate the algorithm 10,000 times. Any verification
> takes 10,000 times more than a simple trial, and the
> dictionary attack becomes impractical. On the other hand, you
> have increased the cost for the client and the server. You
> also rely on the assumption that nobody can compute the result
> of 10,000 iterations without iterating the algorithm 10,000
> times, which may or may not be a safe assumption.
> 
> CRAM-MD5 has another weakness that increases its vulnerability
> to dictionary attack. In CRAM-MD5, the challenge is chosen by
> the server, and the result computed by the client. An
> ill-intentioned server can thus choose a challenge, and
> pre-compute a database of expected results. A better algorithm
> should allow the client to inject some salt in the process.
> 
> -- Christian Huitema
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf





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

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

[Christian Huitema]

>   (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 readily vunerable
>   to dictionary attacks, there are other problems and the
>   presence of encryption would pose an inconvenience, not
>   an obstacle, for the attacker.

The strength of the encryption mechanism does not matter: if the
algorithm has been crypto-analyzed, then the attacker can just proceed
with a reverse computation. We don't know when a given algorithm will be
broken, but we can suspect that any algorithm will be broken eventually.
The reasonable design rule is thus to never hardcode a specific
encryption or hashing algorithm in a protocol.

Even with a strong algorithm, the only effective protection against
dictionary attacks is "key entropy", which determines the number of
trials needed before finding a match. This number follows Moore's law:
attackers with 2005 computers can attempt 100 times more trials than
attackers of 1995. We have reached a point where "if an average user can
remember the password, there is probably not enough entropy in it". 

If you use simple hash functions like MD5 or SHA, challenge response
mechanisms are only OK if the shared secret contains at least as much
entropy as a good symmetric key. Most experts will assume that if you
can, you should use a randomly generated 128 bit key. In practice,
provisioning such keys is hard.

If you must use a low entropy key, you may have a solution by picking a
very slow encryption algorithm. Essentially, you would counter Moore's
law by requiring more CPU for a single trial. For example, instead of
using the simple SHA, you may want to iterate the algorithm 10,000
times. Any verification takes 10,000 times more than a simple trial, and
the dictionary attack becomes impractical. On the other hand, you have
increased the cost for the client and the server. You also rely on the
assumption that nobody can compute the result of 10,000 iterations
without iterating the algorithm 10,000 times, which may or may not be a
safe assumption.

CRAM-MD5 has another weakness that increases its vulnerability to
dictionary attack. In CRAM-MD5, the challenge is chosen by the server,
and the result computed by the client. An ill-intentioned server can
thus choose a challenge, and pre-compute a database of expected results.
A better algorithm should allow the client to inject some salt in the
process.

-- Christian Huitema

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

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

[John C Klensin]

Scott,

I'll leave it to you, Ted, and your IESG colleagues to figure
out what priority this has, but it seems to me that this topic
is, at some point, worth some serious discussion.  If the
security community has really concluded that authentication
without encryption is no longer acceptable --and it certainly
sounds that way from the discussions of the last week, put into
context by Christian's explanation-- then we have a task in
front of us to start upgrading or deprecating almost every
application protocol we have, back to and including Telnet.  

Conversely, it seems to me that an alternate recommendation
would be "don't even bother thinking about running applications
on the public Internet except over encrypted tunnels that
provide both privacy and server authentication".  If we are
headed that way, and believe that advice will be followed, then
perhaps the issues and requirements for individual applications
actually get less stringent than what we've been trying to
insist on for the last several years.

My only strong opinions about this are that some serious,
carefully-explained and consensus-based guidance is in order
here and that it should apply, to the extent possible, across
the applications space rather than being developed by picking at
particular sentences in particular proposed-for-standards-track
documents.

And, coming back to my initial note to Sam on the original
thread, I think that, if we propose to impose much stronger
requirements, we need to be careful about explanations and
education, lest the marketplace respond by saying "too hard",
"can't be deployed at plausible cost", "the users will just
click 'yes' when the warnings come up and get irritated in the
process",  or "lousy user experience" and then ignore whatever
recommendations we have made.

best,
 john


--On Saturday, 11 June, 2005 11:32 -0400 Scott Hollenbeck
<[EMAIL PROTECTED]> wrote:

>> -Original Message-
>> From: John C Klensin [mailto:[EMAIL PROTECTED] 
>> 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 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 but just 
>> about every application we have:
> 
> [snip]
> 
> An apparea meeting is planned, but due to the change in
> meeting structure we've asked to have it scheduled for a
> one-hour slot on Monday.  Ted and I are open to having a
> discussion topic if someone is willing to lead the discussion.
> 
> -Scott-
> 





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

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

[Scott Hollenbeck]

> -Original Message-
> From: John C Klensin [mailto:[EMAIL PROTECTED] 
> 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 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 but just 
> about every application we have:

[snip]

An apparea meeting is planned, but due to the change in meeting structure
we've asked to have it scheduled for a one-hour slot on Monday.  Ted and I
are open to having a discussion topic if someone is willing to lead the
discussion.

-Scott-


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

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

[John C Klensin]

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 quite clear, and it
is hugely more helpful than what end up sounding like personal
authority statements of the "I don't like it so you shouldn't
use it" variety.

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 but just about every
application we have:

(1) Given the problem you describe, then the key feature
of digest-MD5 is not the difference in algorithm, but
the fact that it uses a privacy layer.  That should
probably be much more clear than it has been in most of
the "digest-MD5 is better" discussions.

(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 accomplished by client possession and verification of
a server key or by an extra secret and handshake. That
would presumably be "good enough" unless we also have a
significant concern about sessions being hijacked once
they have been properly initiated. I don't know the
degree to which that is a practical concern (remember
that SMTP sessions, especially pipelined ones, are
typically pretty short and that, e.g., IMAP has
provisions for in-session reverification although I
believe they are still not intensively used).
Conversely, if the server identity is not verified, or
is verified only by the luser's receiving an
incomprehensible warning message and clicking "accept"
every time, then even encryption wouldn't seem to help
much.   

(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 readily vunerable
to dictionary attacks, there are other problems and the
presence of encryption would pose an inconvenience, not
an obstacle, for the attacker.  

Is that correct?

john


--On Saturday, 11 June, 2005 00:04 -0700 Christian Huitema
<[EMAIL PROTECTED]> wrote:

>> (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...
> 
> Times change. Today, using challenge response mechanisms such
> as CRAM-MD5 over un-encrypted channels is not much more secure
> than sending password in clear text. If a third party can
> listen to the challenge and response, and then mount a
> dictionary attack.
> 
> 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 attacker control. Very often, laptops are programmed to
> fetch pending e-mail as soon as they connect to a network. The
> laptop will try resolve "mail.example.com", and start a POP3
> or IMAP exchange. The attacker controls the DNS service on the
> wireless network, and will easily spoof the server. It will
> then respond to the connection with a CRAM-MD5 challenge, and
> harvest the e-mail address of the victim as well as the answer
> to the challenge. The attacker is now in a position to obtain
> the e-mail and password pair for the victim. The attack lasts
> a few seconds, and may not require any particular action by
> the victim. 
> 
> IETF protocols should not endorse the use of unprotected
> challenge-response mechanism. They certainly should not lure
> clients to accept challenges from unauthenticated servers.
> 
> -- Christian Huitema
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf





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

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

[Bruce Lilly]

>  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 attacker control.
> Very often, laptops are programmed to fetch pending e-mail as soon as
> they connect to a network. The laptop will try resolve
> "mail.example.com", and start a POP3 or IMAP exchange. The attacker
> controls the DNS service on the wireless network, and will easily spoof
> the server. It will then respond to the connection with a CRAM-MD5
> challenge, and harvest the e-mail address of the victim as well as the
> answer to the challenge. The attacker is now in a position to obtain the
> e-mail and password pair for the victim. The attack lasts a few seconds,
> and may not require any particular action by the victim. 

Thank you, Christian; we now have a concrete description of a specific
problem.

There is however, a subtle difference between POP3/IMAP and SMTP as
used by the draft under discussion.  POP3/IMAP authenticate a user as
authorized to access the contents of one or more mailboxes, whereas
SMTP involves a client host and a server. [while SMTP provides for
specification of a mailbox (for delivery notifications), during multi-
hop transfers that mailbox remains unchanged as the message is
transferred from client to server/client to server, so is not usable
for authentication of a client host]

For the "evil twin" problem, the following seem to apply to SMTP:
o the client cannot be certain of the server's identity.  This seems
  to be characteristic of the SMTP protocol; the client identifies
  itself, but the server does not (at least not other than in optional
  text which is (a) easily forged and (b) specifically required to be
  disregarded by the client)
o the "evil twin" could harvest client (host) identity and credentials,
  that would allow the "evil twin" to spew spam and malware as if it
  were the client
o the "evil twin" could harvest mailbox information (but not access
  credentials) from SMTP MAIL FROM and RCPT TO commands, and could
  collect or modify any unencrypted message (header and body)
  content
o TLS doesn't seem to help, as the "evil twin" can certainly use TLS,
  either on port 465 or via STARTTLS on either port 25 or 587 to lure
  the client into revealing host credentials; worse, it may give
  message senders a false sense of privacy if message content is not
  encrypted by a separate mechanism such as S/MIME or PGP/MIME.
o As I understand it, control of DNS does not appear to be necessary.
  The "evil twin" is in effect a man-in-the-middle, which can "proxy"
  the application protocol between the traveler's host and the
  legitimate remote server, both for collection of information and
  for modification of application-layer content.  That could, for
  example, be implemented as port-based TCP filtering without the
  need to affect DNS transactions. Specifically, even if the
  traveler uses a hard-coded IP address of the SMTP server, the
  "evil twin" can intercept the session data.

[the assumption in the above analysis is that the attacker can use an
access point implemented as or connected to a router, rather than as
a pure bridge, and that the network configuration behind the AP is
not easily determined by the victim]

o Again, as I understand it, the mode of access need not be wireless;
  the same sort of "proxying" could take place via any sort of
  network connection (e.g. wired Ethernet connections as provided
  by some hotels)
o On a wired network implemented via hubs (as opposed to switches),
  eavesdropping is of course possible by third parties. TLS may be
  effective against that case and the one immediately below. 
o unprotected wireless access opens the communications to attacks
  other than man-in-the-middle by eavesdroppers.
o even protected wireless access (for some unspecified meaning of
  "protected") is susceptible to attacks by an unscrupulous provider
o Even "protected" wireless access is susceptible to man-in-the-
  middle attacks; there exist wireless APs implemented as routers
  which are capable of operating in multiple modes, including
  as a type of range extender.  Firmware modification could
  provide for eavesdropping or content replacement or session
  redirection, and a no-firmware-modification implementation
  could tie two units (one acting as an access point, the other
  operating as an AP client to the genuine access point), providing
  the man-in-the-middle attacker with access to data via the wired
  connections between the two APs.

> IETF protocols should not endorse the use of unprotected
> challenge-response mechanism. They certainly should not lure clients to
> accept challenges from unauthenticated servers.

Has either been codified in an approved RFC (BCP or otherwise)?

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

[Christian Huitema]

> (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...

Times change. Today, using challenge response mechanisms such as
CRAM-MD5 over un-encrypted channels is not much more secure than sending
password in clear text. If a third party can listen to the challenge and
response, and then mount a dictionary attack.

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 attacker control.
Very often, laptops are programmed to fetch pending e-mail as soon as
they connect to a network. The laptop will try resolve
"mail.example.com", and start a POP3 or IMAP exchange. The attacker
controls the DNS service on the wireless network, and will easily spoof
the server. It will then respond to the connection with a CRAM-MD5
challenge, and harvest the e-mail address of the victim as well as the
answer to the challenge. The attacker is now in a position to obtain the
e-mail and password pair for the victim. The attack lasts a few seconds,
and may not require any particular action by the victim. 

IETF protocols should not endorse the use of unprotected
challenge-response mechanism. They certainly should not lure clients to
accept challenges from unauthenticated servers.

-- Christian Huitema

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

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

[John C Klensin]

--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 have a reasonable chance of gaining consensus.
>...

And that is exactly the document that I, and others in the email
community, have been requesting for a few years now.  However,
to be completely precise:

(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...

(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
outlived its usefulness, but if "The RECOMMENDED
alternatives..." include only things that are significantly more
complex or require significantly more infrastructure, there is
some reason to believe that they will go nowhere fast,
independent of any pronouncements the IETF chooses to make.

 john


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

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

[Keith Moore]

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 considerably delay publication of  
spamops.  Nor does it really seem to be necessary, as the concepts  
and terms used  by spamops are few enough to define in that document,  
even if they're redefined later in an arch document.


Keith


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

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

[Frank Ellermann]

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



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

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

[Frank Ellermann]

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 socket interface, and in that
case cram-md5 / digest-md5 / otp is the best I have.  And the
server in question offers login / plain / cram-md5 for AUTH.

> I think the best option for this protocol, given issues
> raised by Simon regarding DIGEST-MD5, is TLS+PLAIN.

Where that's possible it's fine.  I'm more interested in the
case where it's impossible.  My understading of the draft is:

"Whatever you do stay away from PLAIN (or the obsolete LOGIN)
 without TLS, use at least CRAM-MD5".

Maybe Brian's proposed compromise covers this concept somehow.
And he wanted "known weaknesses [citations]".  That's about
today, not about some results of the not yet existing HASH WG
in 2006 or later.
  Bye, Frank



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

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

[Keith Moore]

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 determine it from the text that is written).


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

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

[Keith Moore]

> 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 determine it from the text that is written).

I can certainly propose text that (I believe) says what _I_ think it should say.

Keith

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

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

[Jeffrey Hutzelman]

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
reading things carefully, is that the material often does not
substantiate the point.

What you are so winningly touting was not, as you indicate, a problem
with the text, but a problem with my use of a different term in this
thread.


Dave,

I disagree.  I think this illustrates that you don't have a clear handle
on what you are talking about.

rather than try so hard to deny that the text is ambiguous, why not just
fix the text?



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?


-- Jeff

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

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

[Keith Moore]

> >  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 substantiate the point.
> 
> What you are so winningly touting was not, as you indicate, a problem with the
> text, but a problem with my use of a different term in this thread.

Dave,

I disagree.  I think this illustrates that you don't have a clear handle on 
what you
are talking about.

rather than try so hard to deny that the text is ambiguous, why not just fix 
the text?

Keith

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

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

[Dave Crocker]

> > >  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 said "local environment" and nothing about
> >  "network",  and it suddenly didn't seem so broken any more.
> >
>  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 substantiate the point.

What you are so winningly touting was not, as you indicate, a problem with the
text, but a problem with my use of a different term in this thread.




  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net




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

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

[Keith Moore]

> > 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.
> 
> 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 said "local environment" and nothing about "network", 
> and it suddenly didn't seem so broken any more.

at the very least it illustrates that using vague terms in a technical 
specification
without defining those terms can lead to misunderstanding.  fortunately the
misunderstanding was discovered before the document was published, so that
it can be clarified before it does harm.

Keith

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

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

[Dave Crocker]

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 challenging
function to place into an architecture.


>  didn't understand before reading your architecture document.  Having done
>  so, I can withdraw my comment on the "resolves to" phrasing, and replace it
>  with a different one:
>
>  Maybe the spamops document needs a reference to the email-arch document?

I'm going to suggest that to the other authors.  In fact, the architecture
discussion in the spamops document was the motivation (actually the basis text)
for the email-arch document.  After we did the spamops early drafts, I decided
that the community needed something specifically about email architecture.  I
thought it would be straightforward to write.  That was roughly a year and 3
major iterations ago...


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Jeffrey Hutzelman]

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
use of the word were  the cause of the problem on this thread.


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 said "local environment" and nothing about "network", 
and it suddenly didn't seem so broken any more.




If you or anyone else has specific changes they are suggesting, I'm at a
loss to  guess what.


I'm not suggesting any change.  I initially had the same concern as Sam, 
that there was a requirement to treat things as submission that really 
weren't.  But given a reasonable interpretation of "local environment" 
(i.e. one that does not assume it always means "local IP network"), I've 
managed to convince myself that there aren't any cases left where it 
matters.  So if the experts don't think this is a problem, then neither do 
I.





the trick is to be careful in deciding when the evaluation is being
done: it is evaluated at delivery time, not at the time of acceptance
into the cmu.edu mail service.

And by the way, if folks want to get into this sort of detail about the
variations in email handling, I ask that they first make sure they are
familiar with:

 .

It has gone through extensive development, specifically because these
kinds of variations turned out to take quite a bit more thought and
explanation that had originally been obvious.  The community does not
have consistent, common language and definitions.  Until we do, debates
about particular variations are sure to continue to get caught in
unstated assumptions.


Indeed.  The answer to my concern appears to lie in the subtle but 
significant semantic distinction between Relaying and Aliasing, which I 
didn't understand before reading your architecture document.  Having done 
so, I can withdraw my comment on the "resolves to" phrasing, and replace it 
with a different one:


Maybe the spamops document needs a reference to the email-arch document?


-- Jeff

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

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

[Kurt D. Zeilenga]

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.  I think most
users and administrators will enable that TLS support if a
plain text password mechanism is chosen.  And, if that's
the RECOMMENDED default, I doubt many users and administrators
will disable TLS without some considerations of th
security implications of their choice.

I think the best option for this protocol, given issues
raised by Simon regarding DIGEST-MD5, is TLS+PLAIN.

Kurt 


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

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

[Brian E Carpenter]

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 two things - technical quality and community  
consensus.
both are necessary conditions for approving the document.  but they  are 
not the same thing.


or to put it another way -
a) it should be clear to you that CRAM-MD5 has known weaknesses that  
would make it

unlikely to be suitable for BCP
b) it should also be clear to you that a BCP candidate that  recommends 
CRAM-MD5 is

unlikely to gain consensus

Keith


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 have a reasonable chance of gaining consensus.

Brian


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

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

[Dave Crocker]

>  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 pretty generically.  As you note, the document text uses different words.
In fact that language was carefully chosen.  Unfortunately, this thread has
tended toward generalities and imprecise language and I succumbed.

(By the way, thanks for returning to the source material and considering it
specifically.)


> >  o  Mail coming from outside an email operator's local environment,

>  Now, connections that come from clients not on my IP network may be from
>  authorized submission clients which are outside my "local environment".
>  But, they may also come from clients which are part of my local
>  environment, but do not happen to be on my local network.  I might decide
>  that a particular client fits that category because of its authenticated
>  identity, either to SMTP or at some lower layer.

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.


>  So maybe whether to treat such messages as "submission" or not is not all
>  that important, especially if it is reasonable under some circumstances to
>  consider a host not on the local IP network to still be part of the "local
>  environment"??

Here is the entire text of the recommendations in section 3 of the draft:

Best practices are:

* Operators of MSAs MUST perform authentication during mail submission,
based on an existing relationship with the submitting entity. This requirement
applies to all mail submission mechanisms.
* For email being received from outside their local operational environment,
email service operators MUST distinguish between mail that will be delivered
inside that environment, from mail that is to be relayed back out to the
Internet. This allows the MTA to restrict this operation, preventing the problem
embodied by "open" relays.
* Mail coming from outside an email operator's local environment, and having
a RCPT-TO address that resolves to a destination that is also outside the local
environment, MUST be treated as mail submission, rather than mail relaying.
Hence it must be subjected to mail submission authorization and validation
checks.
* MDAs SHALL NOT accept mail to recipients for which that MDA has no
arrangement to perform delivery.


If you or anyone else has specific changes they are suggesting, I'm at a loss to
guess what.


>  However, I do have another concern with this requirement, and frankly I
>  can't remember whether it's been brought up or not.  My concern is with the
>  phrase "resolves to a destination that is also outside the local
>  environment", and how it interacts with things like forwarding.  If the
>  CMU.EDU mail exchangers receive a message whose RCPT-TO is [EMAIL PROTECTED],
>  and LDAP says that mail for that address should be delivered to gmail, does
>  that make it an address that resolves to a destination outside the local
>  environment?  The document is not clear on this, and I'm very concerned
>  that a wrong answer would result in a lot of incorrectly bounced mail...

unless gmail is part of the local environment for the cmu.edu mail
service, then how could it be interpreted as anything other than
"outside"?

the trick is to be careful in deciding when the evaluation is being
done: it is evaluated at delivery time, not at the time of acceptance
into the cmu.edu mail service.

And by the way, if folks want to get into this sort of detail about the
variations in email handling, I ask that they first make sure they are
familiar with:

 .

It has gone through extensive development, specifically because these
kinds of variations turned out to take quite a bit more thought and
explanation that had originally been obvious.  The community does not
have consistent, common language and definitions.  Until we do, debates
about particular variations are sure to continue to get caught in
unstated assumptions.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Frank Ellermann]

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 whether you are authorized to use that MTA to
> submit messages to recipients not in the domain(s) for which
> that MTA is authorized to accept incoming mail.

I read "inside" as "something avoiding SMTP AUTH like RADIUS",
"outside" as "roaming user, SMTP AUTH or SMTP-after-POP", and
the third case is an unknown stranger saying "HELO".

Simply 2476 or 2476bis vs. 2821.  And what you later said,
tricks based on the MAIL FROM, is "enforced submission rights",
that's 6.1 in 2476 or 2476bis.

> I'm sending comments to IESG separately.

They know 2476bis, it was approved some weeks ago.  And the
relevant parts are the same as in RfC 2476 published 1998.

And if they don't like CRAM-MD5 what they'll get is LOGIN or
PLAIN _without_ TLS, sigh.
Bye, Frank




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

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

[Jeffrey Hutzelman]

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.



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.



Fortunately, that is not what the text Sam originally objected to actually 
says.  The actual text uses the term "local environment":




o  Mail coming from outside an email operator's local environment,
   and having a RCPT-TO address that resolves to a destination that
   is also outside the local environment, MUST be treated as mail
   submission, rather than mail relaying.  Hence it must be subjected
   to mail submission authorization and validation checks.



Now, connections that come from clients not on my IP network may be from 
authorized submission clients which are outside my "local environment". 
But, they may also come from clients which are part of my local 
environment, but do not happen to be on my local network.  I might decide 
that a particular client fits that category because of its authenticated 
identity, either to SMTP or at some lower layer.


I've tried for the better part of an hour to come up with a scenario in 
which this matters.  In particular, _any_ scenario in which a message 
addressed to a non-local recipient is not either submission or an attack -- 
whether or not the client is part of the "local environment".  I may not 
have as fertile an imagination or as much operational experience as some 
people in this thread, but I've tried really, really hard.  And I've been 
completely unable to do so.


So maybe whether to treat such messages as "submission" or not is not all 
that important, especially if it is reasonable under some circumstances to 
consider a host not on the local IP network to still be part of the "local 
environment"??




However, I do have another concern with this requirement, and frankly I 
can't remember whether it's been brought up or not.  My concern is with the 
phrase "resolves to a destination that is also outside the local 
environment", and how it interacts with things like forwarding.  If the 
CMU.EDU mail exchangers receive a message whose RCPT-TO is [EMAIL PROTECTED], 
and LDAP says that mail for that address should be delivered to gmail, does 
that make it an address that resolves to a destination outside the local 
environment?  The document is not clear on this, and I'm very concerned 
that a wrong answer would result in a lot of incorrectly bounced mail...



-- Jeff

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

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

[Keith Moore]

 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 take
 that for what you think it's worth.


Ok.  Please explain precisely what text in the draft is "incorrect"  
and what is

"incorrect" about it.


You have been sent a copy of my last call comments that I sent to  
IESG.  If you need clarification, please let me know.


I gave a case analysis for 3 conditions.  I believe none of them  
was wrong and that there is not a fourth case.  If you feel  
otherwise, please provide detail.



 I didn't see a clear breakdown of those cases.


A Friday, 5:27pm posting from me:

"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."


okay, fine.  first, it's less than general to assume that there is a  
network that is "the network" associated with the MSA.  second,  
depending on source IP address for authentication or an indication of  
trustworthiness is of limited applicability - though there may be  
cases where it's reasonable to do, it's not reasonable to do in  
general, and it's not reasonable to expect these cases to apply to  
all MTAs.  and in particular I don't think it's reasonable to treat a  
source IP address as an indication of trustworthiness unless you  
reliably know _who_ is associated with that source IP address, and  
that imposes several constraints on how you operate your network that  
are not generally met by IP networks.   (if memory serves, we don't  
usually consider authentication by source address to be "BCP"  
material, though I believe that it may be reasonable to do so in this  
case as long as appropriate constraints are identified)


finally, I believe it is simpler and clearer to treat the case where  
the client authenticates to the MSA/MTA via SMTP AUTH and the case  
where the client authenticates to the MSA/MTA via source IP address  
as the same case.  In effect, either (a) you're both authenticated  
(by any of a variety of means) and authorized to relay mail to  
domains (not networks) other than those for which the MTA is  
authorized to accept mail for, or (b) you're not able to relay mail  
to domains other than those for which the MTA is authorized to accept  
mail.


if there's a reason for having the MTA treat clients that are  
authenticated via source IP address differently from clients that are  
authenticated by other means, I haven't seen it.


 Again, I believe you are confusing what your own views and  
preferences

 are, with some sort of independent, objective reality.



 I could make the same claim about what you seem to be doing.


Yes, you could.  But that would be incorrect.


You are entitled to your opinion :)

 "Outside the network" is exactly what we felt was relevant.  It  
might be
 dandy to phrase this as some more generic issue, but since this  
is an
 operations document, for consumption by operations people, it is  
phrased

 in a way that is useful to THEIR perspective.

 This perspective is specific to MSAs that are operated by IP  
networks

 for the customers of those IP networks.


Actually it is not.  It specifies a topological distinction that is  
quite
straightforward and has nothing to do with any business  
relationship, per se.


I could try to nail down the details, but I suspect it's a rathole.   
I think the burden is on you to explain why "the network" (which I  
take to be the IP source address) is _in general_ relevant to whether  
an MTA/MSA should accept mail for relaying to domains other than  
those it is authorized to accept incoming mail for.


If all of an MSA's users access the MSA from networks other than  
the one that

the MSA is on, then all the users are "outside the network".


or maybe there is no "the network".

 The document uses the term 'submission' to refer to the hand-off  
step.  It quite  carefully distinguishes between the two ports  
through which  submission is currently done.



 I don't see any effort to distinguish the two, say in section 2.


Section 2, Terminology.

Definition of the word submission:

"At the origination end, an MUA works on behalf of end users to  
create a message

and perform initial "submission" into the transmission infrastructure,


that's not a definition, that's a use of the word.

here's my concern about treating this concept in a fuzzy fashion -  
while it's all well and good to say MTAs should not accept nonlocal  
mail from unauthenticated users (i.e. no third party relaying), we  
really don't want to encourage MTAs to perform the kinds of munging  
that MSAs are allowed to perform.  so it's far better to say "MTAs  
should not accept mail to nonlocal users from una

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

[Keith Moore]

 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 quality and community  
consensus.
both are necessary conditions for approving the document.  but they  
are not the same thing.


or to put it another way -
a) it should be clear to you that CRAM-MD5 has known weaknesses that  
would make it

unlikely to be suitable for BCP
b) it should also be clear to you that a BCP candidate that  
recommends CRAM-MD5 is

unlikely to gain consensus

Keith


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

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

[Dave Crocker]

>  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 the obvious reasons, but a
reasonable substitute would likely suffice.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Dave Crocker]

> > >  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 take
>  that for what you think it's worth.

Ok.  Please explain precisely what text in the draft is "incorrect" and what is
"incorrect" about it.

What you wrote means that you are asserting that we did not mean treat as
submission.  And I'll just bet that's not what you actually meant.


> >  I gave a case analysis for 3 conditions.  I believe none of them
> >  was wrong and
> >  that there is not a fourth case.  If you feel otherwise, please
> >  provide detail.
> >
>  I didn't see a clear breakdown of those cases.

A Friday, 5:27pm posting from me:

"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."


> >  Again, I believe you are confusing what your own views and preferences
> >  are, with some sort of independent, objective reality.
> >
>  I could make the same claim about what you seem to be doing.

Yes, you could.  But that would be incorrect.


> >  "Outside the network" is exactly what we felt was relevant.  It might be
> >  dandy to phrase this as some more generic issue, but since this is an
> >  operations document, for consumption by operations people, it is phrased
> >  in a way that is useful to THEIR perspective.
> >
>  This perspective is specific to MSAs that are operated by IP networks
>  for the customers of those IP networks.

Actually it is not.  It specifies a topological distinction that is quite
straightforward and has nothing to do with any business relationship, per se.

If all of an MSA's users access the MSA from networks other than the one that
the MSA is on, then all the users are "outside the network".


> >  The document uses the term 'submission' to refer to the hand-off
> >  step.  It quite
> >  carefully distinguishes between the two ports through which
> >  submission is
> >  currently done.
> >
>  I don't see any effort to distinguish the two, say in section 2.

Section 2, Terminology.

Definition of the word submission:

"At the origination end, an MUA works on behalf of end users to create a message
and perform initial "submission" into the transmission infrastructure,"

Whereas references to the services on different ports is... gosh.  By port
number.

If you want text changed, then please suggest specific changes.



>  Indeed, it appears that the document uses several vague terms without
>  bothering to define them.

Speaking of vagueness, please review your sentence, directly above, and explain
to me what specific references it makes and what specific changes it calls for.


>  no, that's not what I meant.  I meant "treating a message received by
>  an MTA as a submission has never been well defined".


Given that section 3 discussion the construct extensively, then I cannot
guess what more you are looking for.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Keith Moore]

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 to run a standards effort.


The current document purports to be a candidate for BCP and yet it  
recommends a practice which is clearly no longer appropriate.In  
light of the information provided it should be obvious that it's not  
acceptable in its current form.  The fix should also be obvious, and  
the resulting document (with other edits as needed for clarity) seems  
quite useful, timely, and appropriate.


This discussion isn' t holding back the document, it's helping  
provide feedback on what kinds of edits are needed to get the  
document approved.  If anything, one of the authors is holding back  
the document.



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

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

[Keith Moore]

 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' intent.  That is quite  
different

from the document being "incorrect".


I meant what I said.  You may infer that it is my opinion, and take  
that for what you think it's worth.


 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.

 This is wrong.  "outside the network" is irrelevant.  What  
matters is

 whether you are authorized to use that MTA to submit messages to
 recipients not in the domain(s) for which that MTA is authorized  
to accept

 incoming mail.


I gave a case analysis for 3 conditions.  I believe none of them  
was wrong and
that there is not a fourth case.  If you feel otherwise, please  
provide detail.


I didn't see a clear breakdown of those cases.

Again, I believe you are confusing what your own views and  
preferences are, with

some sort of independent, objective reality.


I could make the same claim about what you seem to be doing.

"Outside the network" is exactly what we felt was relevant.  It  
might be dandy
to phrase this as some more generic issue, but since this is an  
operations
document, for consumption by operations people, it is phrased in a  
way that is

useful to THEIR perspective.


This perspective is specific to MSAs that are operated by IP networks  
for the customers of those IP networks.  This is a less-than-general  
perspective, as there are MSAs that are independent of IP networks,  
and IP networks may wish to outsource mail service.  Since the email  
architecture delegates MTA authority on a per-domain basis (via DNS  
and MX records),  rather than by IP address blocks, the document  
would be more broadly applicable if it were rewritten to separate the  
concept of "operating environment" from the concept of domain.


If you're going to make a document that is narrowly scoped than that,  
you should at least state the scope.


Of course, if a user's identity is reliably known from his source IP  
address, combined with the knowledge an operator has that its network  
is adequately protected against source IP spoofing, this might  
reasonably be considered sufficient authentication for that user.   
But this should probably be stated explicitly and precisely rather  
than buried in the undefined concept of operating environment.  And  
the question of whether a user should be able to use a particular  
server for message submission, or whether a message is treated as a  
submission, probably shouldn't depend on _how_ a user has  
authenticated - whether by passwords over TLS or TLS client certs or  
by PPPoE to the provider's network (as indicated by source IP  
address)  - so long as the user's identity is reliably known.



 There seems to be some ambiguity between treating an incoming
 message as a submission and using the SUBMISSION protocol.



Well, I don't see the ambiguity, but I do see the confusion.

Submission is a hand-off from the From/Sender user realm to the  
mail handling
service.  SUBMISSION is a particular port and service for doing  
submissions.


The document uses the term 'submission' to refer to the hand-off  
step.  It quite
carefully distinguishes between the two ports through which  
submission is

currently done.


I don't see any effort to distinguish the two, say in section 2.   
Indeed, it appears that the document uses several vague terms without  
bothering to define them.



 It seems prudent to clearly distinguish the two.  And since treating
 an incoming message as a submission has never been well-defined,


the term "incoming" is what causes the problem here.  For every  
server, every
message that it receives is "incoming".  that is true for msa's as  
well as mtas.


agreed.

however i suspect what you mean, here, is 'coming from outside the  
network'.
since you earlier said that it is irrelevant, i'm not sure what  
your point is,

here.


no, that's not what I meant.  I meant "treating a message received by  
an MTA as a submission has never been well defined".


Keith


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

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

[Dave Crocker]

>  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 perspective on some of them and I'd
like to try to raise mine.  I don't see them as conflicting with John's,
but rather I'd like to treat them as separate just to avoid having to
worry about synchronization.  If they overlap with his, fine.  If not,
well, that's fine too.)


This draft BCP touts some basic practices to improve the accountability
of mail systems that are injecting messages into the global Internet.
It cites a range of specifics, for performing those practises, notably
with respect to some security functions.  Mostly, it cites those
specifics in order to make give body to the higher-level recommendations
it is making. It does not particularly recommend one over the other, nor
do I believe it should.

Notably it does not invent any technologies or practices.  Rather it
tries to document and recommend some broad operations practices that are
established and that result in some general improvements in the email
service.

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 to run a standards effort.

First, if the algorithm in question is so terrible, surely the large
number of folks using it would be experiencing some problems by now.  It
is not as if we are lacking in attackers exploiting easy holes in
Internet services.  And surely there would have been global alarums
raised about this algorithm, given its widespread use and it
weakenesses.

The current reality is that the ops and apps areas get to play a
guessing game, in the sure and certain knowledge that they will guess
wrong.  The security community will always find fault with our choices.

Unless and until the security community can provide the applications and
operations community some common "packages" to use, just as transport,
network management and routing do, then we are never, ever going to make
serious progress using meaningful security.

Yes, I know the arguments for why this is difficult.  And yes, I know
that security folk claim it is impossible because every service is
unique.

That's not good enough.

If the security is going to press for use of good security, then it
needs to provide far more turn-key solutions to those developing
services.  Simply requiring that every service be developed with
security expertise and solutions that are unique to the service is a
model that clearly does not... scale.

Having debates about what is currently in vogue among various experts is
a fine thing to do... among the experts.  But it is entirely
inappropriate to have these spontaneous debates in the middle of
pursuing a document specifying current practises.

If there is consensus among the security community that particular,
established practises are no longer viable, then please go through the
usual IETF processes for documenting community consensus about it.

At that point, it will make sense for the operations and development
community to adjust what it specifies.

Until then we are stuck with the vagaries of individual opinions and as
I recall, that's not what the IETF is supposed to be driven by.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Simon Josefsson]

"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 recommendation that PLAIN not
> be used when TLS is not in use).

I don't think recommending the DIGEST-MD5 security layers is a good
idea.

The integrity layer is hard coded to be HMAC-MD5, with keys derived
using a home-grown key-derivation function based on MD5.

Of the privacy layers, only des and 3des were mandatory to implement
in RFC 2831, and both ciphers were dropped in RFC 2831bis, presumable
because they were never implemented correctly nor successfully
deployed.

Either situation alone should be enough to avoid recommending its use
for IETF protocols, in my opinion.

I believe the code complexity cost of DIGEST-MD5 generally outweigh
the small advantages that DIGEST-MD5 may have, for the majority of
users.  This is why, in my perception, DIGEST-MD5 hasn't "taken off".
The lack of cryptographic analysis and cryptographic flexibility
doesn't improve the situation.

TLS+PLAIN seem like a fine recommendation, though.

Cheers,
Simon

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

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

[Dave Crocker]

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 with the authors' intent.  That is quite different
from the document being "incorrect".

The document says what we meant, including the implications.  If there is a
factual error -- and that is what "incorrect" means -- then please state it.


> >  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.
> >
>  This is wrong.  "outside the network" is irrelevant.  What matters is
>  whether you are authorized to use that MTA to submit messages to
>  recipients not in the domain(s) for which that MTA is authorized to accept
>  incoming mail.

I gave a case analysis for 3 conditions.  I believe none of them was wrong and
that there is not a fourth case.  If you feel otherwise, please provide detail.

Again, I believe you are confusing what your own views and preferences are, with
some sort of independent, objective reality.

"Outside the network" is exactly what we felt was relevant.  It might be dandy
to phrase this as some more generic issue, but since this is an operations
document, for consumption by operations people, it is phrased in a way that is
useful to THEIR perspective.


> >  SUBMISSION is relatively recent and it's use is still only for a portion
> >  of the posting traffic on the Internet.  From a practical standpoint,
> >  port 25 is still heavily used; so that the two types of traffic are
> >  still frequently multiplexed over 25.  Hence any BCP concerning initial
> >  posting needs to cover both ports.
> >
>  There seems to be some ambiguity between treating an incoming
>  message as a submission and using the SUBMISSION protocol.

Well, I don't see the ambiguity, but I do see the confusion.

Submission is a hand-off from the From/Sender user realm to the mail handling
service.  SUBMISSION is a particular port and service for doing submissions.

The document uses the term 'submission' to refer to the hand-off step.  It quite
carefully distinguishes between the two ports through which submission is
currently done.

If you see any ambiguity, please explain where and what.


>  It seems prudent to clearly distinguish the two.  And since treating
>  an incoming message as a submission has never been well-defined,

the term "incoming" is what causes the problem here.  For every server, every
message that it receives is "incoming".  that is true for msa's as well as mtas.

however i suspect what you mean, here, is 'coming from outside the network'.
since you earlier said that it is irrelevant, i'm not sure what your point is,
here.


  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net



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

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

[Keith Moore]

> >  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 example MSAs are given significant freedom to modify submitted
> 
> That's right.
> 
> 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.  

> 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.

This is wrong.  "outside the network" is irrelevant.  What matters is whether
you are authorized to use that MTA to submit messages to recipients not in
the domain(s) for which that MTA is authorized to accept incoming mail.

> >Also, mail relaying
> >  and submission have different protocols defined by different
> >  specifications.  For the most part these protocols are interoperable
> >  but the requirement seems overly strict given this situation.
> 
> SUBMISSION is relatively recent and it's use is still only for a portion 
> of the posting traffic on the Internet.  From a practical standpoint, port 
> 25 is still heavily used; so that the two types of traffic are still 
> frequently multiplexed over 25.  Hence any BCP concerning initial posting 
> needs to cover both ports.

There seems to be some ambiguity between treating an incoming 
message as a submission and using the SUBMISSION protocol.
It seems prudent to clearly distinguish the two.  And since treating
an incoming message as a submission has never been well-defined,
perhaps a different way of describing what an MTA should do when
an unauthenticted sender tries to send to a recipient not in a domain
for which the MTA is authorized to accept incoming mail, would be
appropriate.

bottom line: the spec as written is poorly worded and needs 
significant revision.  I'm sending comments to IESG separately.
(and yes, I found the same problem that Sam did, before I read
his message)

Keith

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

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

[Steven M. Bellovin]

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 attack on
>HMAC-MD5 itself.  If such attacks are now seen to be plausible,
>or if post-authentication session hijacking has become a
>dominant concern in practice, it is, as I indicated in my
>earlier note, time to document that and to use the documentation
>as the basis for explicitly deprecating CRAM-MD5 (or HMAC-MD5
>itself if necessary).

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 off-the-shelf tools -- see, for example, Dug Song's dsniff 
package, and read the man pages for arpspoof, sshmitm, webmitm -- and 
the advent of wireless has created a fertile ground for such things.  
(Think about the "evil twin" wireless attacks.)  Factor in routing 
attacks -- they're happening, too -- and you'll see why I'm concerned.

For the record, I've seen active attacks on ssh and web in the wild, at 
the Usenix Security conference and at the IETF itself.  And those were 
without even looking for them.

--Steven M. Bellovin, http://www.cs.columbia.edu/~smb



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

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

[John C Klensin]

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
"no more clear text passwords" to applications folks, then more
or less stepped away.   Whatever the strengths or weaknesses of
either clear text passwords or CRAM-MD5, it was considered an
advantage at the time that they provided authentication, and
authentication only.  In particular, an authentication-only
model, with no attempt or pretense at privacy or integrity
protection for message content, avoids entanglements with any
national or trans-border restrictions that might exist (or be
imagined) on encryption, law enforcement access to keys, etc.  

Now sometimes that is ok, and sometimes it isn't.  I am often
reminded of a conversation with an MIT senior faculty member
some years ago about exposure of information in a
generally-accessible shared-printer environment.  Her response
to my concern was that, if someone decided to pull her material
off the printer and read it, maybe they would learn something
and that was what she and the Institute were all about.  It all
depends on the circumstances.

* There is a huge difference between telling a user or
implementer, in a Security Considerations section or otherwise,
"hey, CRAM-MD5 just provides authentication and no privacy or
integrity protection, if you need either of those, you need to
use it with something else or use something else entirely" and
saying "we have decided, in our wisdom, that authentication-only
solutions are inadequate for you and should be discouraged".

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 attack on
HMAC-MD5 itself.  If such attacks are now seen to be plausible,
or if post-authentication session hijacking has become a
dominant concern in practice, it is, as I indicated in my
earlier note, time to document that and to use the documentation
as the basis for explicitly deprecating CRAM-MD5 (or HMAC-MD5
itself if necessary).  Similarly, if there is really consensus
in the IETF community that authentication without message
integrity protection, etc., are useless or worse, then it is
time to document that opinion and the associated consensus and
see if we can start persuading implementers and the marketplace
to move on.  

But, in the presence of a fairly broad installed base and
interoperable implementations, I suggest that far more is needed
that the personal preferences of the two of you, or even the
personal preferences of the entire security community, before it
is reasonable to start recommending against the continued use of
a widely-deployed practice.   IMO, such a recommendation has to
be considered a very serious step, especially when the practice
was started as the consequence of some rather specific IETF
recommendations.   We should consider  "never mind what we said
a decade ago about clear text passwords, protected or not; we
now prefer such passwords when sent through encrypted tunnels to
be preferable to challenge-response models" to be a fairly
serious step in terms of IETF credibility if nothing else and
should not take it unless we have clear documentation and clear
consensus, not just changes in taste.

 john


--On Thursday, 09 June, 2005 06:36 -0700 "Kurt D. Zeilenga"
<[EMAIL PROTECTED]> wrote:

> 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
> with TLS, if TLS is used then it becomes a real toss-up
> between CRAM-MD5 and PLAIN.  While CRAM-MD5 might be viewed
> by some as better, I note that PLAIN provides for better
> interoperability in systems involving external password
> stores (especially in face of string preparation requirements
> to be added in revisions of PLAIN and CRAM-MD5 specifications),
> and provides support for proxy authorization (identity
> assumption).
> 
> 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 recommendation that PLAIN not
> be used when TLS is not in use).
> 
> I have slight preference for the latter.
> 
> Kurt
> 
> At 03:52 PM 6/8/2005, Sam Hartman wrote:
>> 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.

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

[Kurt D. Zeilenga]

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
with TLS, if TLS is used then it becomes a real toss-up
between CRAM-MD5 and PLAIN.  While CRAM-MD5 might be viewed
by some as better, I note that PLAIN provides for better
interoperability in systems involving external password
stores (especially in face of string preparation requirements
to be added in revisions of PLAIN and CRAM-MD5 specifications),
and provides support for proxy authorization (identity
assumption).

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 recommendation that PLAIN not
be used when TLS is not in use).

I have slight preference for the latter.

Kurt

At 03:52 PM 6/8/2005, Sam Hartman wrote:
>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 recollection that cram-md5 is vulnerable to man-in-the-middle
>attacks but digest-md5 is not.  It's also my recollection that
>digest-md5 will do a much better job of supporting servers that do not
>want to store plaintext equivalents than cram-md5.  The server will
>store a secret that is sufficient to log into that server but may not
>be sufficient to log into other servers.
>
>
>Digest-md5 also supports an integrity and confidentiality layer.
>
>I think all of the above are significant advantages over cram-md5.
>
>If you are concerned that digest-md5 is not sufficiently widely
>implemented then let's recommend plain+tls and digest-md5.  I think
>those are two low-infrastructure protocols in wide use.
>
>___
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


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