Subject: Re: [Asrg] 6. Proposals - AMTP (rev 01) - MPC

From: Bill Weinman <[email-masked]>
Date: Wed, 01 Oct 2003 21:16:39 -0500

At 10:35 AM 9/29/2003, Markus Stumpf wrote:
>We have mailservers that host some 1000 domains each with 5-500 users.
>Same problems apply to big ESPs that might implement MPC based on users.
>As one message can have multiple RCPTs the server would always have to
>send  250-MPC-ALLOW */*, because it cannot signal an MPC unless it knows
>about the recipients email address.

I added this language to the next draft version:

    If there is no MPC declaration in the EHLO reply, "ALLOW */*" is
    implied and the client may proceed.

> >From your examples:
>    S: 250-MPC DENY com/* ALLOW com/individual ALLOW com/confirmed
>The Client knows about MPC classification of the message it is trying to
>send. Maybe you should add a short paragraph about what the Client is
>considered to do, if it knows the messages doesn't meet the server
>criteria. I assume you want the client to quit the connection
>immediately and treat it like a "all recipients permanent failure".

I also added this language:

    If the MPC value of message to be delivered matches any DENY
    declaration in the EHLO reply, the client MUST issue a QUIT command
    and refrain from retrying the message, and the client SHOULD deliver
    a corresponding bounce message to the sender.

Thanks for noticing those.

>Roaming users + MPC
>As a roaming user I might want to relay a email with a MPC that
>violates the general server classification (which is IMHO pretty valid,
>even more if the remote server/recipient will accept it). I am missing a
>specification on how to handle this.

I don't really understand the question. Why would a user relay a message?

>Backup Servers
>How should MPC work with backup servers implementing stronger MPC than
>the destination host does.

MPC is policy-neutral, and doesn't have a concept of "stronger" or 
"weaker", perhaps you mean "more restrictive"?

Why would backup servers have different MPC than the servers they back up?

>IMHO the biggest problem with your MPC idea is that you reduce the
>specification to end-to-end connections, but these are relevant only to
>a very small fraction of every days Internet email connections. Most
>connections are  client <> server <> server ... server <> client
>and this makes server MPC unusable at all.

In AMTP, a message cannot be relayed from one "public" MTA to another 
"public" MTA. In your example, all but one transaction would be 
accomplished with private network connections (i.e., using privately-signed 
certificates).

>------------------------------------------------------------------------
>TLS/X.509
>Just for clarification ...
>Do you want to enforce both encryption (TLS) and authentification (X.509)?
>Authentification via X.509 doesn't necessarily need encryption. Thus you
>could "gain trust" without TLS just by exchanging/validating X.509 certs.

As I understand it, the TLS handshake includes logic to verify that the 
presenter of the certificate has the corresponding private key for the 
certificate. I don't see an easy way to do that without TLS.

>Why don't you also define authentification/trust policies for the receiving
>host? This would add additional security and address the problem of
>rogue receiving MTAs intercepting emails.

I had that in the first draft, but I became convinced that it was unnecessary.

Part of the goal of AMTP is to produce the least-restrictive specification 
that still provides the required benefits. Unless I'm missing something, 
there is not a significant problem with rogue receiving MTAs hijacking 
email. If I'm wrong about that, please let me know.

>------------------------------------------------------------------------
>SRV records
>Why do you want to make MX records obsolete?

It wasn't a goal to obsolete MX records, and the SRV records weren't in the 
original draft. But it solves a significant problem: How to transition from 
SMTP to AMTP without the overhead of attempting both protocols for a lot of 
deliveries.

If both protocols were to use MX records, the only way to know if a server 
MTA speaks AMTP would be to try the AMTP port #. That would fail often, 
especially at the beginning of the transition period. With SRV records, you 
will know which protocol to use before you connect.

The side benefit is that the MX RR was a kludge and AMTP will allow it to 
eventually die of natural causes.

>------------------------------------------------------------------------
>AMTP + SMTP
>For (at least) a grace period AMTP and SMTP have to life together.
>How should a AMTP capable sending MTA behave? What if the destination
>signals AMTP capability via SRV records but the connection cannot be
>established. Should it fallback to SMTP?

That's an implementation detail, and I think that what you described is a 
smart behavior and will likely prevail during the transition period. On the 
other hand I can see where some servers may not want to do that, so I think 
it's best to leave it out of the specification.

Thanks for the thoughtful comments. I've added your name to the 
acknowledgements section in the next draft.

--Bill

---
Never send a monster to do the work of an evil scientist.
~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~
  - Home <http://bw.org/> | Whois <http://whois.bw.org/>
  - Music <http://music.bw.org/> | Blog <http://blog.bw.org/>
  - Gimme back my email! <http://amtp.bw.org/>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Bill Weinman <[email-masked]>
Date: Wed, 01 Oct 2003 22:00:07 -0500

At 11:13 PM 9/28/2003, Yakov Shafranovich wrote:
>It would be great if you can run your proposal past those two checklists, 
>and include the results inside the main draft instead of the separate FAQ.

I read the documents you referred to and applied what I thought was 
relevant when I did my research before writing the current draft.

I did not write a point-by-point interlinear analysis of AMTP with respect 
to the documents you cited, and regrettably I don't see how I can get that 
done any time soon. I am preparing another draft and I'm busy writing the 
proof-of-concept code. AMTP is on track, in spite of a heavy day-job work 
load, and I am pleased with the momentum I have going.

OTOH, comments from this group and the other groups I've been working with 
have been very helpful. I appreciate that and thank you for it. Adjustments 
are being made to the draft, and specific acknowledgements are included there.

>This way we can evaluate the impact of the proposal easier and can have 
>the information in the document itself, instead of a separate FAQ.

Yours is a research group, and as such its mission is naturally academic. 
The AMTP draft is a protocol specification. Its mission is practical: to 
present a clear and succinct description of the AMTP protocol so that 
people can build compliant and compatible implementations. I don't see that 
an analysis such as that you suggested would support the practical goal of 
a protocol specification.

Your group is evaluating AMTP against the goals set out in your charter 
documents. That's what the ASRG is here for, and I appreciate it.

>Second, I would like to ask if you can clarify for us whether your 
>proposal seeks to replace SMTP completely. Section 3 of your draft says:

Yes, AMTP is intended as a replacement of SMTP. It is also substantially 
derivative of SMTP, a design decision intended to ease transition.

>"    The idea of replacing SMTP is appealing because it
>      permits thinking in terms of creating an infrastructure
>      that has accountability and restrictions built in.
>      Unfortunately an installed base the size of the
>      Internet is not likely to make such a change anytime
>      soon.  It seems far more likely that successful spam
>      control mechanisms will be introduced as increments to
>      the existing Internet mail service."

I am acutely aware of this issue and AMTP addresses it by maintaining the 
overall design and command set of SMTP. AMTP is substantially derivative of 
SMTP and as such the transition should be, not entirely trivial, but as 
close as possible without sacrificing its operational advantages.

>In particular we would like to consider whether it would be more viable to 
>reformulate your protocol as an ESMTP extension rather than a replacement 
>for SMTP.

I considered that approach carefully. Ultimately I realized that the SMTP 
protocol REQUIRES (in the sense of RFC2119) a level of promiscuity that 
would prevent AMTP from accomplishing its goals.

I spent many hours on transitional planning before I wrote the first draft, 
and I am working on documents to describe the transition process. In short, 
once I have working code I will provide tools to make the adoption of AMTP 
sufficiently painless that I expect it to be adopted, gradually, by a 
sufficient number of hosts to constitute a critical mass. Time will tell of 
course, but I have yet to see any argument that convinces me otherwise.

--Bill

---

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 1 Oct 2003 23:23:10 -0400

>Why would backup servers have different MPC than the servers they back up?

Because they aren't always provided by the same company.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 01 Oct 2003 23:39:51 -0400

Bill Weinman wrote:
>> proposal seeks to replace SMTP completely. 
> 

First of all Bill, please keep in mind that we are not out to get you 
here, rather we have seen the idea of replacing SMTP being discussed 
many times before (check the archives) and there are many reasons 
against it. We would consider this step, IF determined to be necessary, 
as a long term solution skin to deployment of DNS-SEC or IPv6.

Second, are you aware of other efforts underway to provide a protocol to 
replace SMTP. Especially the following:

AMDP - http://www.ietf.org/internet-drafts/draft-fakih-amdp-00.txt
AMTP - http://www.danisch.de/tmp/draft_mtp.txt
AMTP - http://www.ietf.org/internet-drafts/draft-crouzet-amtp-00.txt
Pull proposals such as IM2000, etc.

There are also many additional proposals mentioned in the list archive 
(use gmane.org to search).

> I am acutely aware of this issue and AMTP addresses it by maintaining 
> the overall design and command set of SMTP. AMTP is substantially 
> derivative of SMTP and as such the transition should be, not entirely 
> trivial, but as close as possible without sacrificing its operational 
> advantages.
> 

I want you to reconsider this issue again. Keep in mind who wrote the 
technical considerations document where this has been taken from - Dave 
Crocker. He is the same person who wrote RFC 822 and has a tremendous 
experience with email. He had also written additional comments 
(http://news.com.com/2009-1081_3-5060650.html) on the idea, specifically:

"
o E-mail authentication mechanisms already exist. They are not used very 
much. Why would a new mechanism fare better?
o When there is real consensus about the functional changes that are 
needed for e-mail, we can start deciding what technical changes will 
achieve them. Only when we find that we cannot modify SMTP to provide 
them will it make sense to consider replacing SMTP.
o Authenticating an e-mail sender will not prevent spam. It might reduce 
some kinds of it, but a great deal of spam is from people who are 
perfectly happy to be correctly identified.
"

He has stated also that:

"In general, solving spam will be easy--as long as we ignore the 
installed base of users; the human side of living with the changes; the 
need to scale use by everyone, everywhere; and the possibility that 
spammers can easily work around any particular prevention mechanism."

It would be very useful to the group in general if we had an analysis of 
whether SMTP needs to be replaced in line with Dave's suggestion above. 
Replacing SMTP is an architechtural issue for the entire Internet. The 
Internet Architechture Board (IAB) which is above both the IRTF and the 
IETF is aware of the issue and will be evaluating it, so this evaluation 
will have input from them.

>> In particular we would like to consider whether it would be more 
>> viable to reformulate your protocol as an ESMTP extension rather than 
>> a replacement for SMTP.
> 
> 
> I considered that approach carefully. Ultimately I realized that the 
> SMTP protocol REQUIRES (in the sense of RFC2119) a level of promiscuity 
> that would prevent AMTP from accomplishing its goals.
> 
> I spent many hours on transitional planning before I wrote the first 
> draft, and I am working on documents to describe the transition process. 
> In short, once I have working code I will provide tools to make the 
> adoption of AMTP sufficiently painless that I expect it to be adopted, 
> gradually, by a sufficient number of hosts to constitute a critical 
> mass. Time will tell of course, but I have yet to see any argument that 
> convinces me otherwise.
> 

I am assuming that you are planning on submitting this protocol as a 
standard to the IETF or as an RFC. In that case, I would suggest that 
you address the deployment and adoption issues in great detail. 
Additionally, the IAB will be considering the issue at some point and it 
is important to watch what they will come up with.

> Never send a monster to do the work of an evil scientist.

BTW, I love the quote :)

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 01 Oct 2003 23:40:43 -0400

as a long term solution akin to deployment of DNS-SEC or IPv6.

"

He has stated also that:

It would be very useful to the group in general if we had an analysis of 
whether SMTP needs to be replaced in line with Dave's suggestion above. 
Replacing SMTP is an architectural issue for the entire Internet. The 
Internet Architecture Board (IAB) which is above both the IRTF and the 
IETF is aware of the issue and will be evaluating it, so this evaluation 
will have input from them.

BTW, I love the quote :)

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 02:48:09 -0500

>First of all Bill, please keep in mind that we are not out to get you here,

    <heh> <heh> <heh> Honestly, if I thought you were hostile, I would not 
have replied.

>replace SMTP. Especially the following:

    Yes, I have seen all of those and more. I have been subscribed to the 
I-D announcement list for a long time.

    Just because others have proposed replacements for SMTP that did not, 
will not, may not, or can not work, does not mean that the concept of 
replacing SMTP is itself fundamentally flawed.

    Any solution that will ultimately work must go through a refinement 
process. Most proposals (including my AMTP) start out with many flaws. Then 
they either get refined or they die on the vine. Most die early. Many of my 
ideas before this one have died. I'm still refining AMTP and I'm pleased 
with the progress so far.

>>overall design and command set of SMTP. AMTP is substantially derivative 
>>of SMTP and as such the transition should be, not entirely trivial, but 
>>as close as possible without sacrificing its operational advantages.
>I want you to reconsider this issue again.

    I re-consider it every day. I have been considering and re-considering 
it for years. I have discussed it with Dave Crocker (just last month). He 
happens to disagree with me and I respect that.

>whether SMTP needs to be replaced in line with Dave's suggestion above.

    With all due respect, I have my hands full already. I am not here to be 
"useful to the group". Please don't take it personally, but if I were to 
set that as a goal I would never get my work done.

    I brought the AMTP draft to ASRG to get feedback, and I am getting that 
and I appreciate it. Several changes are going into the next draft based on 
feedback from this group. I think that's an excellent outcome.

    I am aware that the IAB and IETF have a predisposition opposed 
replacing SMTP, and frankly I think that's a smart position for them. On 
the other hand, I also think it's valuable for people like me should reach 
out and try something bold, as I am doing. The IETF cannot do that -- they 
have a large and diverse constituency. I don't have that constraint.

    The bold steps must, by necessity, be taken by individual mavericks. 
Perhaps this one will work. Perhaps it won't. We will only find out if I 
pursue it.

>is important to watch what they will come up with.

    I will be watching then, as I am now. In the mean time I will continue 
my work.

--Bill

>>Never send a monster to do the work of an evil scientist.

... cool ... so I guess I need a new one now ...

---
God is love; Love is blind; Ray Charles is blind; ...

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 02:57:06 -0500

>Because they aren't always provided by the same company.

That doesn't mean they must have different preemptive MPC values. There are 
a number of ways to deal with this: use a least-restrictive common setting 
for the EHLO reply MPC value; bind to a particular IP addresses for your 
back up server. That's off the top of my head.

The EHLO reply preemptive MPC feature is not for everyone. I'm assuming 
most large ISPs will not use it. But it's an excellent solution for 
corporate mail servers where the corporation wants to control costs and set 
company-wide policies. But I expect many ISPs to have various settings 
available for their users to set on a recipient-specific basis. Like they 
do now with spam filters.

--Bill

---

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 10:52:16 +0200

>  Because they aren't always provided by the same company.

	This is exactly the same problem we have today with backup MXes 
and their anti-spam or anti-virus implementations.  This is also why 
many spammers choose to always route their spam through the backup 
MXes, under the assumption that they will be less well protected than 
the primaries.

	There's nothing new here.  However, this is an issue that we need 
to keep in mind.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 11:09:53 +0200

At 2:48 AM -0500 2003/10/02, Bill Weinman wrote:

>  replacing SMTP, and frankly I think that's a smart position for them.

	On the whole, I agree with them.

>  On the other hand, I also think it's valuable for people like me
>  should reach out and try something bold, as I am doing. The IETF
>  cannot do that -- they have a large and diverse constituency. I
>  don't have that constraint.

	I also agree that alternative proposals should continue to be 
worked on.  If it turns out that we do need to replace SMTP in order 
to make things work, we had better be prepared with multiple 
proposals.

>     The bold steps must, by necessity, be taken by individual mavericks.

	If you're going to be that far out, be prepared for a lot of 
arrows coming your way.  And shotgun blasts.  And bullets from 
buffalo rifles from over a mile away.

	Don't be surprised if you find me as one of the people aiming 
your direction.  I can assure you that I'm going to be damn hard to 
convince.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 11:15:05 +0200

At 2:57 AM -0500 2003/10/02, Bill Weinman wrote:

>  That doesn't mean they must have different preemptive MPC values. There
>  are a number of ways to deal with this: use a least-restrictive common
>  setting for the EHLO reply MPC value; bind to a particular IP addresses
>  for your back up server. That's off the top of my head.

	If you don't control the other machine, how are you going to 
control what they use for MPC?  If you don't control the anti-spam 
settings for the other machine, how are you going to control what 
spam gets into your system?

>  corporate mail servers where the corporation wants to control costs and
>  set company-wide policies.

	Homogenous network environments where the same policy is applied 
to everyone is not going to be a particularly large subset of users.

>                              But I expect many ISPs to have various
>  settings available for their users to set on a recipient-specific
>  basis. Like they do now with spam filters.

	Which implies that we need some sort of mechanism to be able to 
communicate this information later in the SMTP dialog.

	Moreover, if we had that, and could advertise that information 
via EHLO, everyone would be better off -- homogenous network 
environments applying the same policy to everyone would be able to 
continue to do so, while heterogeneous network environments with 
per-user control over these features would also be able to make use 
of this functionality.

	Of course, this doesn't solve the problem with backup MXes.  Or 
senders that ignore this feature because it is inconvenient.

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 10:08:37 -0500

At 04:09 AM 10/2/2003, Brad Knowles wrote:
> arrows coming your way.  And shotgun blasts.  And bullets from buffalo 
> rifles from over a mile away.

    Yeah, I understand that and I expect it. And most have been civil about 
it, which is more than I expected.

> your direction.  I can assure you that I'm going to be damn hard to convince.

    Adversarial argument can be valuable outside of the legal system too!

    So far arguments have been intense and well-reasoned. I couldn't ask 
for anything more helpful than that. I think the differences between the 
second draft and the first speak highly of the process.

--Bill

---
"He who lives by fighting with an enemy has an interest in the preservation 
of the enemy's life." --Nietzsche
~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~ ~~~
  Bill Weinman <http://bw.org/>
  Gimme back my email! - <http://amtp.bw.org/>

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 2 Oct 2003 18:44:43 +0200

>    implied and the client may proceed.

Ok. So it is also "legal" for a Server to send a
   ALLOW */*	(which means no restrictions)
and later on do
   C: RCPT TO:<[email-masked]>
   S: 550 MPC policy violation
i.e. oviously "lie" about the initial MPC policy declaration :-)))

> I don't really understand the question. Why would a user relay a message?

Example: you have a large company with field workers. You have contracts
  with various service providers. The notebooks autoconfigure. If you
  are a field worker, you dialin, send your email and disconnect. You
  don't want to stay online minutes or hours for a end-to-end connection
  to the mailserver of your employer.
  So you relay the message through the mailserver of your dialin provider
  in any case, to get it off fast, disconnect and the MTA of the dialin
  provider delivers the message.
  Authorization for relay is accomplished with SMTP AUTH.
  Now the field worker wants to tell his boss a funny story about a
  customer. He selects MPC per/individual and clicks send.
  However the MTA at the ISP only accepts com/* wheras the MTA at the
  company would accept */* for the CEO.
As the MTA sends MPC declaration com/* and the clients knows it is
per/individual it will not send the message and QUIT immediately.
Tou cannot outrules this say with a correct SMTP AUTH because they do
not reach that stage in communication.

> "weaker", perhaps you mean "more restrictive"?

Yes. Sorry, non native english speaker ;-)

> Why would backup servers have different MPC than the servers they back up?

This has been discussed in this thread meanwhile ;-)
Nothing new to contribute from my side.

> accomplished with private network connections (i.e., using privately-signed 

I don't understand that.
Assume the following example:
 Dialin-User  at DialinProvider A
 -1-> In-MTA at EmailProvider B
    -2-> Out-MTA at EmailProvider B
       -3-> MTA at ISP C
	  -4-> MailGate at Customer D (of ISP C)
	     -5-> Internal Mailserver at Customer D
This is a scenario happening on the Internet millions of times each day.
All MTAs in that scenario either would have to use ACCEPT */* als MPC
declaration or may not have a less restrictive MPC declaration than
"Internal Mailserver at Customer D" or else their policy will dictate
the what the recipient will (not) see.

-1-> will be authenticated, probably SMTP AUTH
-2-> will not be authenticated (internal conn, time/CPU overhead)
-3-> will use AMTP
-4-> will use AMTP
-5-> might or might not be authenticated (internal conn, time/CPU overhead)

The weak point is -1->. The AMTP connection will not gain much
authentication or security. It is unlikely that "MailGate at Customer D"
does not trust "MTA at ISP C" and still use it as MX to protect itself.
It is unlikely that -3-> will get denied. No ISP can block yahoo,
hotmail, AOL, ... for policy reasons and keep it's customer base.
So except for having some clear evidence that "In-MTA at EmailProvider B"
accepted the evil spam initially it doesn't help much.

> certificate. I don't see an easy way to do that without TLS.

Ok, didn't think of that.

> email. If I'm wrong about that, please let me know.

It would add security. DNS spoofying still takes places as there are
enough broken DNS caches out there. Requiring a valid (and CA signed) key
not only on the sending but also on the receiving side would IMHO be
fair and add security. And as the receiving MTA probably wishes to send
out emails itself it would be required to have a valid (and CA signed)
key anyway.

> eventually die of natural causes.

Dan Bernstein describes MXPS - the Mail Exchanger Protocol Switch
    http://cr.yp.to/im/mxps.html
He utilises the distance (prio) field of MX records to indicate
different protocols. E.g. QMTP is at 12801, 12817, 12833, 12849, 12865,
..., 13041

    space.net       IN      MX      12816   mail.space.net.
		    IN      MX      12801   moebius.space.net.

This signals (12801) that a QMTP connection to moebius.space.net is
wanted most. If that fails it falls back to a SMTP connection to
moebius.space.net. If that fails if falls back to the next distant MX
record and as 12816 is not particularly assigned to a protocol is
tries a SMTP connection to mail.space.net.

> it's best to leave it out of the specification.

IMHO it is important to even talk about implementation details. Look at
HTML and missing details and what the Browser Wars make out of it.
Not specifying this will lead to some MTAs implementing AMTP will fall
back and some won't. So with a misconfigured system some emails will
arrive and some won't. IMHO either all should arrive to compensate for
the misconfiuration or none should arrive to signal the admin that
something is horribly wrong.

> acknowledgements section in the next draft.

Oh .. thanks!

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 02 Oct 2003 12:54:46 -0400

Bill Weinman wrote:
>> It would be very useful to the group in general if we had an analysis 
>> of whether SMTP needs to be replaced in line with Dave's suggestion 
>> above.
> 
> 
>    With all due respect, I have my hands full already. I am not here to 
> be "useful to the group". Please don't take it personally, but if I were 
> to set that as a goal I would never get my work done.
> 

This was not meant to you, rather to the group in general.

>    I brought the AMTP draft to ASRG to get feedback, and I am getting 
> that and I appreciate it. Several changes are going into the next draft 
> based on feedback from this group. I think that's an excellent outcome.
> 

Excellent.

> the other hand, I also think it's valuable for people like me should 
> reach out and try something bold, as I am doing. The IETF cannot do that 
> -- they have a large and diverse constituency. I don't have that 
> constraint.
> 

Bill - I admire your persisetnce and willingness to stand up! Now, that 
we have cleared up that you are aware of the opposition, I will not 
bother you on this anymore. Please keep the ASRG updated on the AMTP 
protocol.

ALSO, if it is possible - please make it VERY clear in your draft that 
AMTP is meant to replace SMTP. When I read it, that was not clear to me.

Yakov

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 14:12:42 -0500

At 04:15 AM 10/2/2003, Brad Knowles wrote:
> settings for the other machine, how are you going to control what spam 
> gets into your system?

You don't seem to belive that trust can be created between two systems. If 
you're right, AMTP will not work. Personally, I think it will.

In my vision, *most* systems will follow the rules. Those that don't will 
try to obfuscate and hide and lie. With authenticated connections they will 
be easier to find and isolate. That sounds to me more manageable than what 
we have today.

> to everyone is not going to be a particularly large subset of users.

My research suggests that a significant number of corporate and community 
(co-ops, municipalities, user groups, etc.) admins want server-wide 
policies. ISPs have more complex needs and will use per-recipient settings, 
and even some per-sender settings. (Note that per-sender settings *can* be 
advertised in the EHLO reply.)

> communicate this information later in the SMTP dialog.

Yes, that's done in response to the RCPT command (section 4.4.3 -- see the 
last example, page 11).

> via EHLO, everyone would be better off -- homogenous network environments 
> applying the same policy to everyone would be able to continue to do so, 
> while heterogeneous network environments with per-user control over these 
> features would also be able to make use of this functionality.

That's done in the RCPT response. You seem to be suggesting a per-recipient 
advertisement of MPC values. I decided against that to keep down the number 
of round-trips. As the spec currently stands, a client doesn't get per-user 
MPC values, it just gets 250 or 550 (or occasionally 451) reply codes for 
each RCPT.

I considered advertising the per-recipient settings as a way to preempt 
further transmissions from a sender, but that quickly became overly complex 
to implement. In the EHLO response, the MPC advertisement is really only 
there as a convenience to preemptively abort conversations that are 
guaranteed to result in a 550 response later on. It's not vital to the 
operation of the protocol, but it can be handy in some circumstances.

> senders that ignore this feature because it is inconvenient.

Do you mean "senders that ignore the MPC values in the EHLO response"? They 
will get a 550 later in the conversation. And they risk getting added to a 
CRL.

Backup AMTP servers may well need some extra logic. I will give that some 
more thought and see if I can find something that needs to be addressed in 
the spec.

--Bill

---

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 21:38:34 +0200

At 2:12 PM -0500 2003/10/02, Bill Weinman wrote:

>  policies.

	Agreed.

>            ISPs have more complex needs and will use per-recipient
>  settings, and even some per-sender settings. (Note that per-sender
>  settings *can* be advertised in the EHLO reply.)

	Also true.  The issue is that the protocol must be designed so as 
to handle the more complex case, while the simpler case falls out 
naturally.

	And you do have to keep in mind how to handle situations where 
the backup MXes do not have the same policies as the primaries, or 
where they may not be MCP-enabled at all.

>  That's done in the RCPT response. You seem to be suggesting a
>  per-recipient advertisement of MPC values. I decided against that to
>  keep down the number of round-trips. As the spec currently stands, a
>  client doesn't get per-user MPC values, it just gets 250 or 550 (or
>  occasionally 451) reply codes for each RCPT.

	You could advertise site-wide policies in the EHLO greeting, but 
otherwise you could only advertise that your server is MCP-enabled, 
which may have some impact in the interpretation of SMTP reply codes 
or extended response codes.

>  Do you mean "senders that ignore the MPC values in the EHLO response"?
>  They will get a 550 later in the conversation. And they risk getting
>  added to a CRL.

	If the sender is not MPC-enabled, you might end up blacklisting 
your backup MX.  If you ensure that doesn't happen, what you 
guarantee is that people can by-pass your MPC settings by going 
through the backup MX instead.

	Putting us right back to where we are today.

>  Backup AMTP servers may well need some extra logic. I will give that
>  some more thought and see if I can find something that needs to be
>  addressed in the spec.

	Even if you can't solve the problem, you need to be explicit in 
the acknowledgement of the issue and point out what the 
administrators will need to do.

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 2 Oct 2003 22:46:03 +0200

> be easier to find and isolate. That sounds to me more manageable than what 

RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer
Security - describes STARTTLS that can be used for TLS connections.
Clients can e.g. make a normal SMTP connection and switch to TLS
immediately. This (though patches) is available for nearly all MTAs I
know of. I have never seen it used, however. A friend of mine told me 3
or 4 months ago that he has about 10 TLS connections a week (out of some
10000 a day) and it is always the same server.
RFC 3207 provides already the TLS/X.509 part on AMTP.

> MPC values, it just gets 250 or 550 (or occasionally 451) reply codes for 

Hmmm ... you can save the round trip making ESMTP PIPELINING mandatory.

> will get a 550 later in the conversation. And they risk getting added to a 

You surely mean "block list" and not CRL.
CAs certify identity and if I'd buy a cert that correctly says "you are
mail.example.com" and they'd revoke it because I don't stick to MPC
I'd sue them to Pluto and back.
And exactly this is the reason why I don't "trust":
1) I don't trust CAs in general, because they have done (Verisign/Microsoft)
   and probably do enough bullshit with certs. (If I look at what happens
   when customers buy certs ... oh my god).
2) Certs do say nothing about "good" or "bad". They *try* to help with
   identification. A CA certifies: "this domain/address belongs to company X
   or person Y". That's all. And just like I don't trust everyone on the
   street and give him my house key only because he can show me a valid
   (governmental) identity card, I don't trust any connecting host more than
   I would do without a cert.
With all the webservers and https the real meaning of a cert has been
perverted by Joe Loser and Jane Journalist.

And no, I don't want a centralised CA for mailservers.
Look at the DNS wildcard issue and you can see what happens if you give
one company too much power. And coincidentially this company is also a CA.
Holy bullshit.

	\Maex

---

From: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 23:38:13 +0200

>  Security - describes STARTTLS that can be used for TLS connections.

	TLSSMTP can really screw things up.  I keep getting these bounces 
from a person on Declan McCullagh's Politech mailing list:

From: Mail Delivery Subsystem <[email-masked]>
To: <[email-masked]>
Subject: Returned mail: see transcript for details

The original message was received at Thu, 25 Sep 2003 15:55:23 -0400 (EDT)
from vhost109.his.com [216.194.225.101]

    ----- The following addresses had permanent fatal errors -----
<[email-masked]>
     (reason: 403 4.7.0 TLS handshake failed.)

    ----- Transcript of session follows -----
<[email-masked]>... Deferred: 403 4.7.0 TLS handshake failed.
Message could not be delivered for 5 days
Message will be deleted from queue

Reporting-MTA: dns; smtp-4.his.com
Arrival-Date: Thu, 25 Sep 2003 15:55:23 -0400 (EDT)

Final-Recipient: RFC822; [email-masked]
Action: failed
Status: 4.4.7
Diagnostic-Code: SMTP; 403 4.7.0 TLS handshake failed.
Last-Attempt-Date: Wed, 1 Oct 2003 02:19:25 -0400 (EDT)

	The problem is that if TLSSMTP is advertised, the systems try to 
use that instead and ignore anything else.  If there is a failure, 
they don't fall back to unencrypted channels.  This may be what you 
want in situations requiring encryption, but you shouldn't be forced 
down this path in the case of opportunistic encryption.

	You need to be careful to avoid creating the same kind of trap in 
other circumstances.

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 20:06:18 -0500

>i.e. oviously "lie" about the initial MPC policy declaration :-)))

Yes, it's legal and (yeah, I saw the emoticon) I wouldn't call it a lie. ;^)

I've clarified the meanings of the preemptive declarations in the EHLO 
reply for the next draft -- and I'll revisit it to make sure the intent is 
clear.

> > >[snip]
>[ snip ]

The server doesn't have to wait for the AUTH command to know who is 
connecting. The certificate is presented during the TLS handshake. In a 
circumstance like that, the various servers involved in the agreement could 
all agree to accept a certain private CA signer, and choose a policy set 
that conforms to that agreed upon in the contract.

> > accomplished with private network connections (i.e., using 

I suggest you read section 5 and section 7 more closely, then ask your 
question again. You and I are talking apples and oranges on this subject.

>              -5-> Internal Mailserver at Customer D

According to my vision all except 2->3 are "private network connections".

>the what the recipient will (not) see.

Actually I think a *lot* of ISPs (especially free mail providers) will use 
"ACCEPT */individual", with some adding "ACCEPT */autoresponder".

All of those connections can benefit from AMTP. The private connections can 
gain tremendous flexibility by authenticating the connecting client and 
using specific policies for those clients.

>>>Why don't you also define authentification/trust policies for the 
>>>receiving host?
>>>[snip]
>>[snip]

Can you document that? I have not seen evidence of DNS spoofing in email 
sufficient to warrant an extra burden on the whole system to protect 
against it. If DNS is the problem, wouldn't DNS be a better place to deal 
with it?

>     http://cr.yp.to/im/mxps.html

I considered that approach, but I felt that it was messy and overloaded the 
MX distance field. It could also confuse an SMTP server that didn't 
understand the unconventional usage. SRV seems to me a perfect fit.

What exactly is your objection to SRV?

>IMHO it is important to even talk about implementation details.

Yes, it's important to discuss them and I intend to. I'm writing a separate 
paper about it. But I don't see it as a subject for the protocol 
documentation. I may submit my transitional whitepaper as an I-D. I haven't 
really decided that yet.

--Bill

---

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 20:17:53 -0500

At 02:38 PM 10/2/2003, Brad Knowles wrote:
> your backup MX.

AMTP does not allow a sender that is "not MPC-enabled". The MPC argument in 
the MAIL command is REQUIRED (section 4.4.3).

--Bill

---

---

From: Brad Knowles <[email-masked]>
Date: Fri, 3 Oct 2003 03:28:35 +0200

At 8:17 PM -0500 2003/10/02, Bill Weinman wrote:

>  AMTP does not allow a sender that is "not MPC-enabled". The MPC argument
>  in the MAIL command is REQUIRED (section 4.4.3).

	So, people can't implement AMTP until they can guarantee that all 
of their backups do?  That's going to cut down on the acceptance 
rate....

---

From: Bill Weinman <[email-masked]>
Date: Thu, 02 Oct 2003 20:32:49 -0500

>RFC 3207 provides already the TLS/X.509 part on AMTP.

RFC 3207 section 4 has this statement: "A publicly-referenced SMTP server 
MUST NOT require use of the STARTTLS extension in order to deliver mail 
locally." That makes it impossible to use as a way of combating email abuse.

Also, SMTP requires backward compatibility with non-extended versions of 
the protocol (RFC 2821, section 4.1.1.1). That's why AMTP couldn't work as 
an SMTP extension.

--Bill

---

---

From: Brad Knowles <[email-masked]>
Date: Fri, 3 Oct 2003 03:27:35 +0200

At 8:06 PM -0500 2003/10/02, Bill Weinman wrote:

>  Can you document that? I have not seen evidence of DNS spoofing in
>  email sufficient to warrant an extra burden on the whole system to
>  protect against it. If DNS is the problem, wouldn't DNS be a better
>  place to deal with it?

	Over 50% of the ccTLD nameservers are open public 
caching/recursive nameservers and vulnerable to cache 
pollution/poisoning.  Jon Postel accidentally poisoned the caches of 
many of the nameservers on the net, and damn near took the whole 
thing down.  Eugene Kashpureff did the same thing in 1997, for 
malicious reasons.

	Hell, with companies like VeriSign/NetSOL putting up wildcard 
records in gTLD zones and UltraDNS handing out bogus glue with the 
"authoritative answer" set (not to mention their use of just two 
exclusively anycast nameserver IP addresses), there's lots and lots 
of danger here.

	Most providers do not do edge filtering.  Nor do they do bogon 
filtering.  Nor do they do anti-spoof protection.  The result is that 
spammers can boldly infect hundreds of thousands of machines across 
the 'net, and then use them as a DDoS tool to take out RBL operators 
with impunity.  Even if people have collected the packets, traced the 
lines, and know precisely who is sitting where doing what, the police 
and the governments still won't do a damn fscking thing.

	If there is a potential security hole that we can perceive today 
and that we can reasonably address now, we should do so.

	If we can help mitigate this by requiring certificates, then I'd 
say we should require certificates.

---

From: Bill Weinman <[email-masked]>
Date: Fri, 03 Oct 2003 02:17:18 -0500

At 08:28 PM 10/2/2003, Brad Knowles wrote:
> of their backups do?  That's going to cut down on the acceptance rate....

    No, they can run AMTP and SMTP in parallel. Outgoing MTAs look for an 
SRV RR and use AMTP if available, otherwise fallback to SMTP.

--Bill

---

---

From: Bill Weinman <[email-masked]>
Date: Fri, 03 Oct 2003 02:39:35 -0500

At 08:27 PM 10/2/2003, Brad Knowles wrote:
> caching/recursive nameservers and vulnerable to cache pollution/poisoning.
>[[snip]]

I recognize that there is a problem with DNS that has potential for abuse, 
but I seriously question whether the mail transfer protocol is the 
appropriate place to deal with it.

Is this problem, by itself, justification for the additional overhead of 
X.509 authentication for the *receiving* MTA as a requirement in the mail 
transfer protocol? I tend to think it's a problem that should be dealt with 
in DNS.

--Bill

---

---

From: Brad Knowles <[email-masked]>
Date: Fri, 3 Oct 2003 12:26:34 +0200

At 8:32 PM -0500 2003/10/02, Bill Weinman wrote:

>  RFC 3207 section 4 has this statement: "A publicly-referenced SMTP
>  server MUST NOT require use of the STARTTLS extension in order to
>  deliver mail locally." That makes it impossible to use as a way of
>  combating email abuse.

	As I've proven with a previous post, plenty of MTAs out there are 
sufficiently hosed that this requirement is not (and perhaps cannot 
be) enforced.

	We need to walk before we can run.

>  Also, SMTP requires backward compatibility with non-extended versions
>  of the protocol (RFC 2821, section 4.1.1.1). That's why AMTP couldn't
>  work as an SMTP extension.

	Which will seriously cut down the acceptance rate.

---

From: Bill Weinman <[email-masked]>
Date: Fri, 03 Oct 2003 10:43:08 -0500

>         Which will seriously cut down the acceptance rate.

I personally belive the opposite is true. Time will tell.

--Bill

---

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Oct 2003 12:26:22 -0400

Bill Weinman wrote:
>> pollution/poisoning.
> I recognize that there is a problem with DNS that has potential for 
> abuse, but I seriously question whether the mail transfer protocol is 
> the appropriate place to deal with it.
> 
> X.509 authentication for the *receiving* MTA as a requirement in the 
> mail transfer protocol? I tend to think it's a problem that should be 
> dealt with in DNS.
>

Please take a look at the archive, we had an extensive discussion a 
while back in regards to DNS security and DNS-SEC.

Also I would like to point out that certain technical nitty gritties of 
proposals might be better debated off-list as per RFC 2014:

"     The Chair should attempt to ensure that the discussions on this
       list are relevant and that not devolve to "flame" attacks or rat-
       hole into technical trivia.
"

Some of the discussion around AMTP has been getting pretty close to 
"technical trivia". In particular, AMTP has two mailing lists setup for 
discussion and I would encourage folks to use them. However, I am sure 
that Bill will keep us updated on regular intervals on AMTP and will 
come back seeking more comments.

Yakov

---

From: "Ken Hirsch" <[email-masked]>
Date: Mon, 6 Oct 2003 17:42:36 -0400

From: "Markus Stumpf" <[email-masked]>
> I'd sue them to Pluto and back.

This is not generally true. There are different kinds of certificates that
are created for different purposes and their use is subject to contracts.
The certificate can be revoked if you fail to abide by the terms of the
contract.

See, e.g.
http://www.verisign.com/repository/agreements/codesigning/subscriber.html

I have proposed a specific anti-spam certificate which would only be issued
when the subscriber states what anti-spam policy will be followed and
contractually agrees to it.

>    when customers buy certs ... oh my god).

The fact that Verisign made a mistake is not a good argument.  No system
will ever be perfect and certainly the PKI is relatively new.  Verisign
detected the mistake within a reasonably short period of time and acted to
correct it.

If someone has suggestions for improvement to the PKI, or an alternative to
it, by all means let us know.  I haven't seen any system (e.g. "web of
trust") that was actually workable.

There is now an independent system for standards and auditing of CAs
(http://www.webtrust.org/certauth.htm) and many CAs have been
credentialed under this program.

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 7 Oct 2003 02:19:01 +0200

On Mon, Oct 06, 2003 at 05:42:36PM -0400, Ken Hirsch wrote:
> This is not generally true.

Agreed.

> contractually agrees to it.

We're still lacking a classification of anti-spam policies ;-)

> detected the mistake within a reasonably short period of time and acted to

Granted.
But there is no working way to revoke certs currently (and I don't mean
any experimental services). If a CA revokes a cert for a servername within
the expiration period I'd bet 98% of all browsers/mail clients in the
Internet will /not/ recognize it as revoked.

Sorry, but the fact that PKI is relatively new is IMHO even lesser an
argument. CAs charge a lot of money and they sell dreams and they try to
fake the users into trust (and that's what really makes me angry).
A proof that revocations don't work is the fact that even antivirus
companies had to add the cert to their lists to make them detectable.

See Thawtes' SiteSeal for example (another VeriSign company). It is used
to display an image on a website to tell the visitor "this site is
secure and you can trust it and this is certified by Thawte". This is
IMHO bullshit, as the users don't look at the security information of
their browser anymore but rather at the image. Suppose I have
    www.thawet.com
how long does it need with a graphics program to fake that sign and all
will ignore the warning, because they see the image that says "trust me".
And no CA will give me any cent back if the certified website takes the
money from my (and others) credit cards and lives happily thereafter on
the Cayman Islands. They will however say "it's your fault, why did you
trust them?".

So why should I trust any cert that I haven't made myself?

> trust") that was actually workable.

That's why I said that I trust neither of them.
IMHO there should be international binding guidelines what has to be
checked and validated before a cert is issued. And there has to be
a common jurisdiction in that area. As long as I can patch my documents
I have to send to the CA and they have to believe it as they don't
contact e.g. german Authorities to validate it the certs are for
/dev/null and only useable for the CA as cash machine (as is every new
TLD ;-)

But this is getting way off topic IMHO so we should stop here and not
have Yakov to remind us.

	\Maex

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 6 Oct 2003 20:55:06 -0400

>contractually agrees to it.

AOL currently blocks 2 billion spam messages a day.  Over 5% of the 
internet is in their blacklist.  All the major ISPs use trust-based 
systems based on IP address.  Doing triage at that level is the only 
way they can decide who will get through without heavy filtering, who 
needs to be filtered, and who needs to be blocked outright.  The 
major "good" bulk senders all know this, and split their mailings 
onto different IP addresses, depending on whether it's a known good 
customer, or one about whom they know less.  Big customers get a 
dedicated IP address for their outbound mail.

Consider the following DNS entries and think about what they mean.

webtv.net.              300     IN      MX      10 smtpinvite.mx.webtv.net.
webtv.net.              300     IN      MX      20 smtpin.mx.webtv.net.

This triage isn't just done because they want to avoid false 
positives, it's done because they want to avoid the cost of filtering 
so many messages.

All those decisions are made *before* the HELO prompt.  Trusted email 
already exists, but the token isn't a cryptographic code--it's an IP 
address.

Where in that environment do you put the code to check a certificate 
on a particular sender, and what is the performance penalty?  Do you 
think the ISP is actually going to accept the email and begin the 
transaction before they make a decision?  Let alone do a per-domain 
lookup?  The number of IP addresses may be large--but the number of 
legit mail servers is far smaller than the number of domains.

I would assert that the only place that a certificate, or any 
trust-based system, will be adopted is at the DNS level.  As such it 
will provide an initial level of trust for the given IP address, 
negating the need for negotiations between ISPs and senders (which is 
how it's currently done for the big senders).  And of course the 
result will be cached--they certainly won't be decoding certs on 
every connection. Such a trust system doesn't replace the current 
system used by the major ISPs, but it makes it more available to 
smaller companies who can't build their own trust database, and it 
augments those databases that exist.

Yes, this approach has nasty side-effects.  Your IP is trusted only 
as well as the average quality of your users.  If you're on a 
floating IP address you will never be trusted, and often not even 
allowed to send mail directly.  If you don't control your reverse DNS 
you're in the same boat.  But the fact of the matter is that in those 
cases the major ISPs *already* treat you as a second-class citizen. 
Your email is never going to be accepted by that smtpinvite MX entry, 
and it's always going to get maximum filtering--if indeed it's 
accepted at all.

Domain-based or sender-based certificates are nice for techies and 
cool end-user software that doesn't exist yet, but they provide no 
value at all to the major ISPs.  They don't scale; ISPs are iffy 
about doing one more DNS lookup on a connection, let alone validating 
certs.  And never mind the infrastructure changes.  If you want to 
provide an authentication system that will get adopted, design one 
that solves the problem for AOL, MSN, RoadRunner, Earthlink and the 
other big ISPs.
-- 
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 7 Oct 2003 02:14:37 -0400

From: "Kee Hinckley" <[email-masked]>
> internet is in their blacklist.

So they trust 95% of IP addresses, instead of the 0.1% that they should be
trusting..

[...]
> certs.

Where is the analysis that it won't scale?  It seems to me that the current system
where AOL has to block 2 billion spams a day is the one that has high overhead.

Does anybody have actual numbers on the overhead for establishing an SSL/TLS
session?  Compared to, say, a DNS-based scheme?

> And never mind the infrastructure changes.  If you want to

I won't mind the infrastructure changes because that's what this group is all about.
I won't try to redesign the PKI or DNSSEC or TLS; those protocols and systems have
already been designed by people who know more than I.

But I won't give up on authentication, because without it all the other proposals
are a joke.  The criminals will run their own name servers and abuse any
consent-framework.

If authentication must be DNS-based, so be it, but it must be POSITIVE, white-list
based authentication, not blacklists, and authentication against a trusted third
party, not against name servers of unknown control.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 7 Oct 2003 10:33:46 +0200

>  So they trust 95% of IP addresses, instead of the 0.1% that they should be

	Not true.  Many of those IP addresses are perfectly trustable. 
Even the ones in DSL/dial-up space.  They're used by responsible 
people who run reasonably secure MTAs, or they don't run MTAs at all.

	The problem is that you don't know which ones are trustable and 
which ones are not.  Nor do you know whether this address which was 
trustable fifteen minutes ago is still trustable now.

	Worst, there is no feasible way of determining whether or not a 
particular IP address is trustable, except to watch its behaviour and 
see if it does anything untrustworthy.  Even then, you'd have to make 
sure that the IP address wasn't spoofed, or that the connection 
wasn't hijacked, etc....

	This is a fundamentally unsolvable problem.

>  Where is the analysis that it won't scale?  It seems to me that the
>  current system where AOL has to block 2 billion spams a day is the
>  one that has high overhead.

	The blocking of 2 billion spams a day is not scalable.  Trust me, 
I worked there, and I helped create the first generation of the 
anti-spam controls that were used.  We ended up having to write our 
own MTA in order to get the level of control we needed.

	However, this issue is not relevant to the subject of whether or 
not they decide to trust a given set of IP addresses, or refuse to 
trust a different set of IP addresses.  The concept as a whole is not 
scalable, regardless of which trust model is employed.

>  But I won't give up on authentication, because without it all the
>  other proposals are a joke.  The criminals will run their own name
>  servers and abuse any consent-framework.

	Right, and they'll be perfectly happy to be completely 
authenticated and identifiable.  And they'll exist in other countries 
where you can't touch them legally, and you're right back where you 
were.

	Most DDoS attacks these days don't even bother with spoofing 
source IP addresses, because it's not necessary.  I see no difference 
here.

>  If authentication must be DNS-based, so be it, but it must be POSITIVE,
>  white-list based authentication, not blacklists, and authentication
>  against a trusted third party, not against name servers of unknown
>  control.

	Authentication does not help solve the problem.  However, towards 
the end that so many people are focussed on the issue of 
authentication as opposed to the end result, I agree that it must be 
done as a white-list based method.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 7 Oct 2003 08:21:00 -0400

>So they trust 95% of IP addresses, instead of the 0.1% that they should be

Not at all.  Those are the ones that they know have zero trust. 
Trust isn't an on/off switch.  Different sources have different 
levels of trust.  You can take any sender, whether it be a bulk 
mailer, ISP or individual company, and judge what percentage of their 
email will be unwanted.  Based on that, you can make certain 
filtering decisions.

>Where is the analysis that it won't scale?  It seems to me that the current

Having to check the trust level by performing crytographic protocols 
on each message won't scale.

>session?  Compared to, say, a DNS-based scheme?

SSL/TLS is expensive enough that companies make their business 
selling dedicated hardware to do the processing.  However it has far 
lower latency than a DNS query.  So you've got a time/cpu trade-off. 
However that analysis falls apart in the long run because DNS 
information can be cached, whereas SSL has to be done every single 
time.  So, I would say that DNS is more expensive the first time you 
see a new IP, cheaper thereafter.

---

From: "Ken Hirsch" <[email-masked]>
Date: Tue, 7 Oct 2003 10:33:54 -0400

> This is a fundamentally unsolvable problem.

Of course you can't absolutely guarantee that a server won't be hijacked,
but that's no argument for the current system where all IP addresses are
presumed innocent.  Barring perfection, you can have a system where you do
have some assurance of trustworthiness.  The very minimum standard should be
that you know who's responsible for the server.

> own MTA in order to get the level of control we needed.

I don't get what point you're trying to make here.  If we have an effective
system for deterring spam, that's going to reduce the load on the servers.

> scalable, regardless of which trust model is employed.

Analysis, please.  And define "scalable" please.  I see there's overhead but
it looks to me that the overhead scales linearly and the work can be
distributed among servers rather easily.

Also, remind me what scalable solution to spam you are for.  If I recall
correctly, you're against RMX, challenge-response, as well as PKI
authentication.  So what solution are you for?  Does it have less overhead
than authentication?

> where you can't touch them legally, and you're right back where you

If it turns out that some countries decide to become spam havens, then there
are means for controlling that.  Systems that require cash up front (e.g.
www.bondedsender.org) do not require cooperation of the authorities in
another country to enforce agreements nor particularly strong identity
requirements.  And there are other ways.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 7 Oct 2003 18:34:19 +0200

>  that you know who's responsible for the server.

	That's never going to happen.  We can't get ISPs to do edge 
filtering, or bogon filtering.  Over 50% of the ccTLD servers are 
still open public/recursive caching nameservers.

	The level of incompetence, and total lack of interest in being 
competent, is overwhelming.

	You can't even really use transactional authentication (which is 
only good for a single connection), because the root CA is inherently 
untrustworthy themselves -- VeriSign/NetSOL wants to pimp the entire 
Internet for their own personal private profit.

>  system for deterring spam, that's going to reduce the load on the servers.

	If it can be deterred, yes.

	I submit that the only effective deterrence can come from 
providers who find it unprofitable to provide access or bandwidth to 
spammers, and who enforce the restrictions at the edge.  That will 
happen the same day that we get ISPs around the world to implement 
edge and bogon filtering in their routers, so that packet spoofing 
becomes impossible anywhere on the Internet.

	Meanwhile, I'm waiting for pigs to fly under their own power and 
for hell to freeze over.

>  distributed among servers rather easily.

	Scalable means that providers the size of AOL all the way down to 
one-person shops with less than a dozen customers can implement the 
same methods, and continue to have a viable business model that 
allows them to get sleep at night.

	Scalable means that you don't have to buy a hundred thousand 
servers with custom hardware accelerators, just to handle the load 
this week, and then have to dump them and completely replace them 
with five hundred thousand servers with the next generation of even 
faster hardware accelerators, next week.

	Scalable means that the worst reasonable case you can project for 
workload growth doesn't put us into these kinds of situations.

>  authentication.  So what solution are you for?  Does it have less overhead

	I'm coming around to the view espoused by Paul Vixie where the 
real problem isn't the spammers, it's the things that the 
anti-spammers are willing to do to try to "solve" the problem.

	As bad as the disease is, many of the proposed cures seem to be worse.

>  are means for controlling that.

	I doubt it.  They're already using hijacked PCs today.  Why not 
continue to use hijacked PCs with their SETI@Home-style distributed 
CPU power to continue to pose as legitimate systems?

>                                   Systems that require cash up front (e.g.

	I have yet to see any.

---

From: david nicol <[email-masked]>
Date: 07 Oct 2003 23:59:41 -0500

On Mon, 2003-10-06 at 19:55, Kee Hinckley wrote:
>  Big customers get a 

And therefore IP address matching is IMO sufficient security to
defacilitate spam forgery as a way to steal from a large
spammer's sender-pays account.

.
-- 
david nicol / in 1310 the Dutch invented insurance