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

From: Bill Weinman <[email-masked]>
Date: Sun, 28 Sep 2003 21:24:41 -0500

I have just finished a new draft of the AMTP specification. I would welcome 
comments from this group.

I've submitted it to the I-D editor, but until they get to it you'll find a 
copy here:

    http://amtp.bw.org/docs/draft-weinman-amtp-01.txt

Yakov invited me to join this group after the original draft, but I found 
myself overwhelmed with response from slashdot and on the amtp-discuss 
list. Anyway, this draft is a lot more complete.

TIA for your comments,

--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: Phil Miller <[email-masked]>
Date: Sun, 28 Sep 2003 23:02:04 -0400

Bill Weinman wrote:
> 
> I have just finished a new draft of the AMTP specification. I would 
> welcome comments from this group.
> 
> I've submitted it to the I-D editor, but until they get to it you'll 
> find a copy here:
> 
> Yakov invited me to join this group after the original draft, but I 
> found myself overwhelmed with response from slashdot and on the 
> amtp-discuss list. Anyway, this draft is a lot more complete.
> 
> TIA for your comments,
> 

Major nitpick: "roll" is a kind of bread; you mean "role".

Now, for my real beef: the DNS requirements break the use of 
'residential' ISP lines for hosting AMTP servers. I currently host an 
SMTP server on my local network that would do direct delivery, except 
that a certain large network doesn't accept delivery from 
dynamic/residential pools. So, I have to use my ISP's slow, unreliable 
'smart' host SMTP server as a relay. Your design codifies this 
irritating standard as mandated policy on an Internet-wide basis.
Even if I used my ISP-provided rDNS as the argument for EHLO, and 
purchased a certificate from an outside CA with the same as the CN, my 
ISP can change this value at any time, thus invalidating my certificate 
and making mail delivery impossible.
You do address this, but with the assumption that the ISP is willing and 
able to be helpful. This is not a valid assumption in many circumstances.

Philip Miller

---

From: Bill Weinman <[email-masked]>
Date: Sun, 28 Sep 2003 22:58:30 -0500

>Major nitpick: "roll" is a kind of bread; you mean "role".

Sheeesh! It's also a popular delivery mechanism for toilet paper.

That's embarrassing. The first fix is in place for -02. Thanks.

>Now, for my real beef: the DNS requirements break the use of 'residential' 
>ISP lines for hosting AMTP servers.

This needs to go in the FAQ. It's by far the most common objection.

I too would rather not have to break that functionality, but the 
requirement that the certificate match the PTR RR seems to me valuable, and 
I can see ways to replace the functionality of a home-based mail server.

Allow me to explain:

Without the PTR requirement, a blackhat could get a certificate and upload 
it to zillions of compromised home-based PCs along with a small AMTP 
daemon, much like they do today with SMTP. After a while, the major AMTP 
servers would discover the certificate signature and block it, but a lot of 
spam would go out in the mean time.

With the PTR requirement, all those home-based PCs become unusable as 
distribution points. But now a whitehat needs a fixed IP address and/or a 
moderately clueful provider to run an AMTP server.

(An exceptionally clueful provider could create low-ttl dynamic rDNS for 
selected parts of their IN-ADDR.ARPA zone, but that seems like it's asking 
a lot from an industry that can barely manage a SWIP.)

There are a few ways around this, but I fancy this one: Find a few friends 
and set up a small co-op mail server. You can get a decent low-traffic 
dedicated *nix server for about $99/month, or a colo for about $199. With 
five or ten folks in a co-op, that's not a very big pill to swallow.

Another possibility is that someone will set up a business that will relay 
mail for people like you using the "private network" provision in AMTP. A 
side-benefit for this approach is that you don't need to get your own 
certificate. I forsee this as a moderately popular niche market for someone 
who is interested. (Actually, I think some of these exist now with 
alternate-port SMTP for those who have outgoing port 25 blocked.)

I know it's a PIA, and I would love to find a way around it, but also I see 
it as a reasonable price to pay if it makes the rest of the package work.

--Bill

---

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 29 Sep 2003 00:13:25 -0400

Bill Weinman wrote:
>> 'residential' ISP lines for hosting AMTP servers.
> 
> 
> ...

Hi Bill,

First of all, thanks for keeping us updated on the progress of your 
proposal. I would like to point out that we have two documents, the 
requirements document 
(http://www.infobro.com/anon-FTP/infoSource/IRTF/ASRG/draft-irtf-asrg-requirements-xx-05.txt) 
and the technical considerations document 
(http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt) 
which both include an list of evaluation guidelines. 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. 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.

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:

"  AMTP inherits the specification of SMTP and builds upon it. This
    document specifies only the changes to SMTP and therefore implicitly
    incorporates the most recent SMTP specification [RFC2821] except
    where indicated."

If this is true, then I would like you to address the following 
objections from the technical considerations document:

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

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.

Yakov

---

From: Claus Assmann <[email-masked]>
Date: Sun, 28 Sep 2003 22:07:14 -0700

> comments from this group.

Question: what do you gain by requiring a cert? Whom do you trust
to be a CA? BTW: the hierarchical structure of X.509 certs is
fine for companies, but not for others, where a "web of trust"
would be more appropriate.

It seems that all you get is that the spammers just pay a bit of
money to some CA to send out their stuff.

It would be nice if someone categorizes the ways how spam reaches
the recipients (open relay, proxy, trojaned PCs, directly from
spammers, etc), and the explain how you can defeat those (DNS BLs
for the first two at least, rMX/designated sender can help in some
cases, etc).

Your requirement 4.2 (2) (unfortunately the items aren't numbered)
solves the first the entries from the list above, but it doesn't
do anything about the direct spammers. However, it would kill a lot
of legitimate MTAs (or force them to spend extra money which I
wouldn't do: I provide free software support, I certainly wouldn't
spend extra money on that). These financial requirements hurt the
wrong people, not the spammers. This looks like a way to generate
income for some companies. Why should CA issuers be any better
than ISPs providing connectivity for spammers?

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 29 Sep 2003 02:08:34 -0400

> money to some CA to send out their stuff.

Take a look at the list archive (use gmane.org). There is a very large 
number of messages exchanged on this topic.

> for the first two at least, rMX/designated sender can help in some

The inventory of problems seeks to do a part of that - it lists some of 
the problems with spam that cannot be dealt with existing methods. The 
requirements documents and technical considerations documents outline 
some of things to be used for evaluation. Hopefully, when the next draft 
of the inventory comes out it, all three of these can be reconciled.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 29 Sep 2003 08:50:18 +0200

>  would be more appropriate.

	I'm thinking that we might be able to do something like USENET 
PGP-signed message cancels, or even No-C-Em's.  Just add to your PGP 
keyring the keys you choose to trust, and then listen to the 
appropriate port.  Better yet, use an outbound connection from your 
server to a robust P2P network like freenet, and therefore use a 
relatively randomly assigned port.

>  for the first two at least, rMX/designated sender can help in some

	Regretfully, we've seen that DNS BLs can be taken off the 'net. 
I'm afraid that this tool is going to rapidly become unusable, or at 
least considerably less useful, as the spammers get more and more 
aggressive about DDoS'ing anyone out of existence that stands in 
their way.

	Next on the chopping block would be tools like DCC, Vipul's 
Razor, Pyzor, etc....  Any kind of shared centralized mechanism would 
be a target.

-- 
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: Steven F Siirila <[email-masked]>
Date: Mon, 29 Sep 2003 09:18:35 -0500

> irritating standard as mandated policy on an Internet-wide basis.

I, too, host my own MTA on a residential DSL line.  However, I have a fully
functional rDNS on it was well.  For those that cannot do this, I'd suggest
finding another ISP that allows this.  Until consumers demand it, ISP's such
as yours won't go out of their way to provide this service.

> and making mail delivery impossible.

The key is to have your in-addr.arpa netblock delegated to you.

-- 

Steven F. Siirila			Office: Lind Hall, Room 130B
Internet Services			E-mail: [email-masked]
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 29 Sep 2003 17:35:22 +0200

> comments from this group.

------------------------------------------------------------------------
Comment on MPC:
>From an ISPs point of view (and even from a multi-user/address
mailserver's point of view) per server MPCs are IMHO useless.

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.

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

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.

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

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.

------------------------------------------------------------------------

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.

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.

------------------------------------------------------------------------
SRV records

Why do you want to make MX records obsolete?

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

	\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: Brad Knowles <[email-masked]>
Date: Mon, 29 Sep 2003 21:33:18 +0200

>  as yours won't go out of their way to provide this service.

	That may be possible in some jurisdictions.  In others, there is 
a single dominant provider, and you get what they have to offer, and 
that's it.  For example, much of Europe is in this situation, and 
there are now more Internet users over here than in the US.

	This is an issue that must be addressed in whatever 
recommendations we make.