Subject: Re: RFC2821bis new section 2.3.4 host-requirements
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 26 Aug 2005 10:47:17 -0700
List-Id: <ietf-smtp.imc.org>

--On 24. august 2005 12:17 -0400 [email-masked] wrote:

> On Wed, 24 Aug 2005 12:42:52 BST, [email-masked] said:
>
>> There are rules for internet hosts, that they should have A and PTR
>> records.  (But to be honnest I could not found the RFCs in which this is
>> spelled out)
>
> That's because it isn't spelled out in any RFC I'm aware of.

draft-ietf-dnsop-inaddr-required-07.txt is the one you'll be looking for.

Despite the draft name, it does NOT say "PTR required" - that got beaten 
out of the document pretty early. Instead, it talks about what they're good 
for and why you might want to install them.

                  Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Naming of optional  message header fields
Date:  Thu, 25 Aug 2005 21:25:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 9
Sender: [email-masked]

Chris Haynes wrote:
 
> Any disagreements?

IANA has a registry for provisional header fields:
http://www.iana.org/assignments/message-headers/prov-headers.html

                        Bye, Frank

From: "Chris Haynes" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject:  Re: Naming of optional  message header fields
Date:  Thu, 25 Aug 2005 16:50:33 +0100
Sender: [email-masked]

[email-masked] advised:
> [I asked:]
>> During my private engineering trials, I am using an X-  prefix for the 
>> headers I
>> add.
>>
>> It would make engineering sense to use production header names (without an X-
?> prefix) as soon as I release code to other people for multi-party trials.
...
>>
>> I conclude that it would be acceptable for me to use header names of the 
>> form:
> ">SchemeName-function".
>>
>>Any disagreements?
>>
>> Chris Haynes
...
>

>You should ask this to the  [email-masked] mailing list
>see http://www.imc.org/ietf-822/mail-archive/thrd5.html
>for what is said before about it...

Your reference has led me to RFC 3864, which seems to describe the process I was 
looking for.

Many thanks,

Chris Haynes 

To: Chris Haynes <[email-masked]>, <[email-masked]>
From: [email-masked]
Subject: Re: Naming of optional  message header fields
Date: Thu, 25 Aug 2005 15:41:33 +0100
Sender: [email-masked]

--================_5267324_2==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>.
>
> During my private engineering trials, I am using an X-  prefix for the headers I
> add.
>
> It would make engineering sense to use production header names (without an X-
> prefix) as soon as I release code to other people for multi-party trials.
>
> I note that:
>
> 1)  RFC 2822 Sect. 3.6.8 states simply that optional fields MUST NOT have have
> the same names as those defined elsewhere in that RFC.
>
> 2) Domain Keys are using headers of the form "DomainKey-function" (example
> below)
>
>
> I conclude that it would be acceptable for me to use header names of the form:
> "SchemeName-function".
>
> Any disagreements?
>
> Chris Haynes
>
>
> -------------------------
> Sample Domain Keys header from a recent message (specifics hidden):
>
> DomainKey-Signature:  a=rsa-sha1; s=***; d=***; c=nofws; q=dns;
>  h=received:message-id:date:from:to:subject:in-reply-to:
>  references:x-mailer;
>  b=KkVbW***
>

You should ask this to the  [email-masked] mailing list
see http://www.imc.org/ietf-822/mail-archive/thrd5.html
for what is said before about it...

--================_5267324_2==_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<DIV>&gt;.<BR>&gt;<BR>&gt; During my private engineering trials, I am using an X- &nbsp;prefix for the headers I </DIV>
<DIV>&gt; add.<BR>&gt;<BR>&gt; It would make engineering sense to use production header names (without an X- <BR>&gt; prefix) as soon as I release code to other people for multi-party trials.<BR>&gt;<BR>&gt; I note that:<BR>&gt;<BR>&gt; 1) &nbsp;RFC 2822 Sect. 3.6.8 states simply that optional fields MUST NOT have have <BR>&gt; the same names as those defined elsewhere in that RFC.<BR>&gt;<BR>&gt; 2) Domain Keys are using headers of the form "DomainKey-function" (example <BR>&gt; below)<BR>&gt;<BR>&gt;<BR>&gt; I conclude that it would be acceptable for me to use header names of the form:<BR>&gt; "SchemeName-function".<BR>&gt;<BR>&gt; Any disagreements?<BR>&gt;<BR>&gt; Chris Haynes<BR>&gt; <BR>&gt; <BR>&gt; -------------------------<BR>&gt; Sample Domain Keys header from a recent message (specifics hidden):<BR>&gt; <BR>&gt; DomainKey-Signature: &nbsp;a=rsa-sha1; s=***; d=***; c=nofws; q=dns;&nbsp;</DIV>
<DIV>&gt; &nbsp;h=received:message-id:date:from:to:subject:in-reply-to:<BR>&gt;&nbsp; references:x-mailer;<BR>&gt;&nbsp; b=KkVbW***</DIV>
<DIV>&gt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>You should ask this to the&nbsp;&nbsp;<A href="mailto:[email-masked]">[email-masked]</A> mailing list </DIV>
<DIV>see <A href="http://www.imc.org/ietf-822/mail-archive/thrd5.html">http://www.imc.org/ietf-822/mail-archive/thrd5.html</A></DIV>
<DIV>for what is said before about it...</DIV>
<DIV><BR><BR><BR><BR><BR><BR><BR>&nbsp;</DIV><br><p></p>
--================_5267324_2==_--

Date: Thu, 25 Aug 2005 06:02:48 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Tony Finch <[email-masked]>
cc: Chris Haynes <[email-masked]>, [email-masked]
Subject: Re: Naming of optional  message header fields
Sender: [email-masked]

On Thu, 25 Aug 2005, Tony Finch wrote:

> On Thu, 25 Aug 2005, Chris Haynes wrote:
>>
>> I am designing a message verification system, broadly similar in concept to
>> Domain Keys
>
> Why reinvent the wheel?

Perhaps because DK(IM) is badly designed with its use of dns, and 
oversimplified and limited in extendability in its field syntax...

-- 
William Leibzon
Elan Networks
[email-masked]

Date: Thu, 25 Aug 2005 13:43:57 +0100
From: Tony Finch <[email-masked]>
To: Chris Haynes <[email-masked]>
cc: [email-masked]
Subject: Re: Naming of optional  message header fields
Sender: [email-masked]

On Thu, 25 Aug 2005, Chris Haynes wrote:
>
> I am designing a message verification system, broadly similar in concept to
> Domain Keys

Why reinvent the wheel?

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

From: "Chris Haynes" <[email-masked]>
To: <[email-masked]>
Subject:  Naming of optional  message header fields
Date:  Thu, 25 Aug 2005 10:34:02 +0100
Sender: [email-masked]

I am designing a message verification system, broadly similar in concept to 
Domain Keys, in that sending equipment adds headers to the RFC2822 message, and 
automated recipient systems extract, parse and interpret these headers.

The scheme is intended be offered for standardisation via RFCs, and the main 
code will be made available under Open Source conditions.

During my private engineering trials, I am using an X-  prefix for the headers I 
add.

It would make engineering sense to use production header names (without an X- 
prefix) as soon as I release code to other people for multi-party trials.

I note that:

1)  RFC 2822 Sect. 3.6.8 states simply that optional fields MUST NOT have have 
the same names as those defined elsewhere in that RFC.

2) Domain Keys are using headers of the form "DomainKey-function" (example 
below)

I conclude that it would be acceptable for me to use header names of the form:
"SchemeName-function".

Any disagreements?

Chris Haynes

-------------------------
Sample Domain Keys header from a recent message (specifics hidden):

DomainKey-Signature:  a=rsa-sha1; s=***; d=***; c=nofws; q=dns;
   h=received:message-id:date:from:to:subject:in-reply-to:
   references:x-mailer;
   b=KkVbW***

To: [email-masked]
Cc: [email-masked]
Subject: Re: RFC2821bis new section 2.3.4 host-requirements 
From: [email-masked]
Date: Wed, 24 Aug 2005 12:17:53 -0400
Sender: [email-masked]

--==_Exmh_1124900273_3593P
Content-Type: text/plain; charset=us-ascii

On Wed, 24 Aug 2005 12:42:52 BST, [email-masked] said:

> There are rules for internet hosts, that they should have A and PTR records. 
> (But to be honnest I could not found the RFCs in which this is spelled out)

That's because it isn't spelled out in any RFC I'm aware of.

--==_Exmh_1124900273_3593P
Content-Type: application/pgp-signature

--==_Exmh_1124900273_3593P--

Date: Wed, 24 Aug 2005 14:16:14 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: RFC2821bis new section 2.3.4 host-requirements
Sender: [email-masked]

On Wed, 24 Aug 2005 [email-masked] wrote:
>
> My idea was to distinghuis two differend kinds of SMTP-clients. Clients
> that are conforming and should be allowed to send emails to any
> Mailserver that has MX records pointing at him. And Clients that should
> use their Submission servers. (not fully capable clients)

This is what CSA aims to do in a backwards-compatible way.

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

To: [email-masked]
From: [email-masked]
Subject: Re: RFC2821bis new section 2.3.4 host-requirements
Date: Wed, 24 Aug 2005 12:42:52 +0100
Sender: [email-masked]

>> >That A record MUST point to the SMTP Client.
>> >And the IP address of the SMTP client MUST resolve back to the hostname.
>>
>> That may not be possible with multi-homing.
>
> out-mail.example1.com     A    192.168.0.10
>                           A    10.0.5.10
> out-mail.example2.com     A    192.168.0.10
>                           A    10.0.10.5
> 10.0.168.192.in-addr.arpa PTR  out-mail.example1.com
>                           PTR  out-mail.example2.com
> 10.5.0.10.in-addr.arpa    PTR  out-mail.example1.com
> 5.10.0.10.in-addr.arpa    PTR  out-mail.example2.com
>
> It's *possible* to set it up.  The biggest problems you hit are:
>
> 1) A *lot* of software doesn't understand that PTR records can be multi-valued.
>
> 2) An even more incredibly large number of sites don't do DNS-over-TCP or EDNS0,
> so if the list of PTRs ends up over 512 bytes, things go pear-shaped quickly.

My idea was to distinghuis two differend kinds of SMTP-clients.
Clients that are conforming and should be allowed to send emails to any Mailserver that has MX records pointing at him.
And Clients that should use their Submission servers. (not fully capable clients)

There are rules for internet hosts, that they should have A and PTR records. (But to be honnest I could not found the RFCs in which this is spelled out)
And this is just a reminder of that, fully conforming SMTP-clients ARE internet host and therefore should conform to the rules of internet hosts. (As fas as they are resonable, so that is open to discussion on this forum)

I also want that RFC2821bis in its main sections only describes the interaction between fully capable systems.
But i agree in the (new) section about limited capable systems this requirements should be mitigated.

Hope this makes it clear.
And I hope somebody can give me references to the RFCs where these requirements are spelled out.

From: [email-masked]
Cc: Claus Assmann <[email-masked]>, [email-masked]
To: Tony Finch <[email-masked]>
Date: Tue, 23 Aug 2005 11:35:22 -0700 (PDT)
Subject: Re: RFC 3207 (STARTTLS) question
Sender: [email-masked]

> On Mon, 22 Aug 2005, Claus Assmann wrote:
> >
> > However, in some cases you don't want to speak to a particular
> > "personality" (virtual host) of a server but to several of them
> > because you figured out that <A@Z> and <B@Y> are both served by
> > the same host. This is one of the problems when I looked into
> > session reuse (as well as sending multiple RCPTs in a single
> > transaction): under which circumstances is it ok to do that?

> This is why the distinction between hostnames and mail domains is
> important. It is the *host* that you are talking to (not a mail domain) so
> that is what a TLS cert should verify. That host should be prepared to
> handle any recipient address at any mail domain for which it is the
> advertised MX target, regardless of other recipients of the message or
> other messages in the session. Virtual hosts, as in web server
> terminology, usually don't make sense for email because MX records provide
> the necessary indirection.

I will also add that failure to distinguish between hosts and the mail domains
they serve is often a significant source of confusion, even for experienced
operators. I've lost track of the number of customers problems that traced back
to this basic misunderstanding.

I always recommend using naming conventions to make the distinction clear.
Sadly, I often deal with existing large)deployments where naming
choices - sometimes extremely poor ones - are essentially cast in stone.

				Ned

Date: Tue, 23 Aug 2005 10:41:15 +0100
From: Tony Finch <[email-masked]>
To: Claus Assmann <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 (STARTTLS) question
Sender: [email-masked]

On Mon, 22 Aug 2005, Claus Assmann wrote:
>
> However, in some cases you don't want to speak to a particular
> "personality" (virtual host) of a server but to several of them
> because you figured out that <A@Z> and <B@Y> are both served by
> the same host. This is one of the problems when I looked into
> session reuse (as well as sending multiple RCPTs in a single
> transaction): under which circumstances is it ok to do that?

This is why the distinction between hostnames and mail domains is
important. It is the *host* that you are talking to (not a mail domain) so
that is what a TLS cert should verify. That host should be prepared to
handle any recipient address at any mail domain for which it is the
advertised MX target, regardless of other recipients of the message or
other messages in the session. Virtual hosts, as in web server
terminology, usually don't make sense for email because MX records provide
the necessary indirection.

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

Date: Mon, 22 Aug 2005 22:17:22 -0700
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: RFC 3207 (STARTTLS) question
Mail-Followup-To: Claus Assmann <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, Aug 22, 2005, Harald Tveit Alvestrand wrote:

> another place to put it would be as a parameter to the starttls command 
> (tell me that you're authorized for server X) - I wonder why that wasn't 
> considered earlier (or rejected)?
> 
> probably too late to do that change now....

You could add a new ESMTP command which is the equivalent to "Can
I speak to Y please?" when you call someone on the phone.  The "Hi,
my name is X" part of the introduction is available (EHLO/HELO),
but not the other part; the initial greeting of the server is just
"Hi, this is Z". Such a command might be restricted to TLS or
it might be useful for other functionality too.

However, in some cases you don't want to speak to a particular
"personality" (virtual host) of a server but to several of them
because you figured out that <A@Z> and <B@Y> are both served by
the same host. This is one of the problems when I looked into
session reuse (as well as sending multiple RCPTs in a single
transaction): under which circumstances is it ok to do that?

Date: Mon, 22 Aug 2005 16:51:40 -0700
From: Harald Tveit Alvestrand <[email-masked]>
To: Cyrus Daboo <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 (STARTTLS) question
Sender: [email-masked]

--On 22. august 2005 18:59 -0400 Cyrus Daboo <[email-masked]> wrote:

>> (For the MX case, the answer might be "content of the MX record" rather
>> than "domain that contains the MX record" - doesn't help for the A case,
>> and is not obvious from the text)
>>
>> Am I missing something obvious?
>
> No - this is a 'known' problem. Its an issue for IMAP and other types of
> services too, where people want to run virtual domains off a single
> server.
>
> <draft-ietf-tls-rfc3546bis-01.txt> (Section 3.1) attempts to address this
> by extending TLS to allow the client to specify the server name it is
> using during the TLS handshake, thus allowing the server to pick the
> appropriate certificate for that name.

Yep.

another place to put it would be as a parameter to the starttls command 
(tell me that you're authorized for server X) - I wonder why that wasn't 
considered earlier (or rejected)?

probably too late to do that change now....

               Harald

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  esmtpa / esmtpsa (was: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and   extensions of current standards)
Date:  Tue, 23 Aug 2005 03:44:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 10
Sender: [email-masked]

Tony Finch wrote:
 
> See for example the "esmtpa" in this message header. This is
> useful for software like SpamAssassin which likes to be able
> to work out which Received: lines correspond to message
> submission and which to message relay.

Cute idea, noted just in case, I'm not sure whether SpamCop
already uses this as an "enough already" indicator.  Bye, Frank

Date: Mon, 22 Aug 2005 19:44:51 -0400
From: "Eric A. Hall" <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
CC: [email-masked]
Subject: Re: RFC 3207 (STARTTLS) question
Sender: [email-masked]

On 8/22/2005 3:02 PM, Harald Tveit Alvestrand wrote:

> How does my server know which certificate to present to the client, so that 
> the above general rule is satisfied?

The historical method (most commonly seen for HTTPS, less for others) was
to assign different IPs to each of the domain names. There was a lot of
griping about this practice during the supposed addressing crunch.

Tony is right that there isn't a very good definition of what's to be used
for the comparison. Does it mean the hostname entered into the client
application, the A name that the CNAME resolves to, or what?

> Am I missing something obvious?

The option of assigning distinct addresses to each domain name is still
there, if you can get them.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

Date: Mon, 22 Aug 2005 18:59:26 -0400
From: Cyrus Daboo <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>, [email-masked]
Subject: Re: RFC 3207 (STARTTLS) question
Sender: [email-masked]

Hi Harald,

--On August 22, 2005 12:02:49 PM -0700 Harald Tveit Alvestrand 
<[email-masked]> wrote:

> On reviewing T. Schorr's suggestion, I read this paragraph a few times:
>
>    The decision of whether or not to believe the authenticity of the
>    other party in a TLS negotiation is a local matter.  However, some
>    general rules for the decisions are:
>
>    -  A SMTP client would probably only want to authenticate an SMTP
>       server whose server certificate has a domain name that is the
>       domain name that the client thought it was connecting to.
>
> Now... I have a server that is an MX host for half-a-dozen domains, and
> has about 3 A records pointing to it (why is a long history).
>
> How does my server know which certificate to present to the client, so
> that the above general rule is satisfied?
>
> (For the MX case, the answer might be "content of the MX record" rather
> than "domain that contains the MX record" - doesn't help for the A case,
> and is not obvious from the text)
>
> Am I missing something obvious?

No - this is a 'known' problem. Its an issue for IMAP and other types of 
services too, where people want to run virtual domains off a single server.

<draft-ietf-tls-rfc3546bis-01.txt> (Section 3.1) attempts to address this 
by extending TLS to allow the client to specify the server name it is using 
during the TLS handshake, thus allowing the server to pick the appropriate 
certificate for that name.

-- 
Cyrus Daboo

Date: Mon, 22 Aug 2005 23:42:32 +0100
From: Tony Finch <[email-masked]>
To: Harald Tveit Alvestrand <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 3207 (STARTTLS) question
Sender: [email-masked]

On Mon, 22 Aug 2005, Harald Tveit Alvestrand wrote:

>   -  A SMTP client would probably only want to authenticate an SMTP
>      server whose server certificate has a domain name that is the
>      domain name that the client thought it was connecting to.
>
> Now... I have a server that is an MX host for half-a-dozen domains, and
> has about 3 A records pointing to it (why is a long history). How does
> my server know which certificate to present to the client, so that the
> above general rule is satisfied? (For the MX case, the answer might be
> "content of the MX record" rather than "domain that contains the MX
> record" - doesn't help for the A case, and is not obvious from the text)

There's a general problem with the SMTP RFCs that they don't make a clear
distinction between domain names in general, and domain names that are
host names (which resolve to A and/or AAAA records), and domain names that
are mail domains (which resolve to MX records). TLS is usually used with
host names (e.g. when connecting to web servers or when using SMTP in
message submission mode) so the server should probably have one or three
certificates, depending on whether the hostname(s) used as the target of
the MX records refer to all IP addresses or just one. As in the web
virtual hosting case you need at least one IP address per TLS cert so
that the server can decide which one to present.

I don't use TLS for inter-domain SMTP - there seems little point :-)

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

Date: Mon, 22 Aug 2005 12:02:49 -0700
From: Harald Tveit Alvestrand <[email-masked]>
To: [email-masked]
Subject: RFC 3207 (STARTTLS) question
Sender: [email-masked]

On reviewing T. Schorr's suggestion, I read this paragraph a few times:

   The decision of whether or not to believe the authenticity of the
   other party in a TLS negotiation is a local matter.  However, some
   general rules for the decisions are:

   -  A SMTP client would probably only want to authenticate an SMTP
      server whose server certificate has a domain name that is the
      domain name that the client thought it was connecting to.

Now... I have a server that is an MX host for half-a-dozen domains, and has 
about 3 A records pointing to it (why is a long history).

How does my server know which certificate to present to the client, so that 
the above general rule is satisfied?

(For the MX case, the answer might be "content of the MX record" rather 
than "domain that contains the MX record" - doesn't help for the A case, 
and is not obvious from the text)

Am I missing something obvious?

               Harald

Date: Mon, 22 Aug 2005 18:05:42 +0100
From: Tony Finch <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and   extensions of current standards
Sender: [email-masked]

On Sun, 21 Aug 2005, Frank Ellermann wrote:
>
> The "official" abbreviations are not very popular, see also
> <http://mid.gmane.org/[email-masked]>

Exim uses them in its Received: lines. See for example the "esmtpa" in
this message header. This is useful for software like SpamAssassin which
likes to be able to work out which Received: lines correspond to message
submission and which to message relay.

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

To: SM <[email-masked]>
Cc: Willemien <[email-masked]>, [email-masked]
Subject: Re: RFC2821bis new section 2.3 
From: [email-masked]
Date: Mon, 22 Aug 2005 12:41:22 -0400
Sender: [email-masked]

--==_Exmh_1124728882_26702P
Content-Type: text/plain; charset=us-ascii

On Mon, 22 Aug 2005 08:46:59 PDT, SM said:

> >That A record MUST point to the SMTP Client.
> >And the IP address of the SMTP client MUST resolve back to the hostname.
> 
> That may not be possible with multi-homing.

out-mail.example1.com		A	192.168.0.10
				A	10.0.5.10
out-mail.example2.com		A	192.168.0.10
				A	10.0.10.5
10.0.168.192.in-addr.arpa	PTR	out-mail.example1.com
				PTR	out-mail.example2.com
10.5.0.10.in-addr.arpa		PTR	out-mail.example1.com
5.10.0.10.in-addr.arpa		PTR	out-mail.example2.com

It's *possible* to set it up.  The biggest problems you hit are:

1) A *lot* of software doesn't understand that PTR records can be multi-valued.

2) An even more incredibly large number of sites don't do DNS-over-TCP or EDNS0,
so if the list of PTRs ends up over 512 bytes, things go pear-shaped quickly.

--==_Exmh_1124728882_26702P
Content-Type: application/pgp-signature

--==_Exmh_1124728882_26702P--

Date: Mon, 22 Aug 2005 08:46:59 -0700
To: "Willemien" <[email-masked]>, [email-masked]
From: SM <[email-masked]>
Subject: Re: RFC2821bis new section 2.3
Sender: [email-masked]

At 02:51 22-08-2005, Willemien wrote:
>2.3.4  Host
>[[ added requirements]]
>
>
>For the purposes of this specification, a host is a computer system
>attached to the Internet (or, in some cases, to a private TCP/IP network)
>and supporting the SMTP protocol.  Hosts are known by names (see the next
>section); they SHOULD NOT be identified by numerical address.
>Fully capable SMTP systems MUST conform to the following requirements:
>
>For fully capable SMTP Clients:
>The hostname given in the EHLO or HELO command  MUST resolve in a DNS A
>record.

SMTP clients behind a NAT may not be able to follow this requirement 
(see RFC 2821 section 4.1.3).

>That A record MUST point to the SMTP Client.
>And the IP address of the SMTP client MUST resolve back to the hostname.

That may not be possible with multi-homing.

Regards,
-sm 

From: "Willemien" <[email-masked]>
To: <[email-masked]>
Subject: RFC2821bis new section 2.3
Date: Mon, 22 Aug 2005 10:51:07 +0100
Sender: [email-masked]

I hereby post an new proposal for section 2.3 terminology from the
RFC2821bis draft.
draft-klensin-rfc2821bis-00.txt

In replying please reply to one section only and name the section number  in
the subjectline of your reply.

comments are placed  between [[ and ]]

Have a nice read.

Willemien

Index:
2.3  Terminology
2.3.A(new)  requirement levels
2.3.1  Mail Objects
2.3.1.1 (from 2.3.9) The SMTP envelope
2.3.1.2 (from 2.3.9) message SMTP-content
2.3.2  Senders and Receivers (unchanged)
2.3.B(new) originator
2.3.C(new) recipient
2.3.C.1 (new) postmaster recipient
2.3.3  Basic Mail Architecture / mail agents
(was Mail agents and message stores)
2.3.3.1 Mail User Agent MUA
2.3.3.2 Mail Submission Agent MSA
2.3.3.3 Mail Transfer Agents MTA
2.3.3.4 Mail Delivery agent MDA
2.3.3.5 Message Store   MS
2.3.D  Originator, Submission, Relay, Delivery, and Gateway Systems
2.3.D.1 Originator Systems
2.3.D.2 Submission Systems
2.3.D.3 Relay Systems
2.3.D.4 Delivery Systems
2.3.D.5 Gateway Systems
2.3.4  Host
2.3.5  Domain Names
2.3.6  Buffer and State Table
2.3.7  Lines
2.3.10   Mailbox and Address
2.3.11   Reply

The old section 2.3.8 is under 2.3.D
The old section 2.3.9 is under 2.3.2

2.3 Terminology

2.3.A(new) requirement levels

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

"may" "can" and other non-capitalised words refer to extensions that are
made in this draft and are not in RFC 2821 or other RFC's

2.3.1 Mail Objects

SMTP transports a mail object. A mail object contains an envelope and
content.

2.3.1.1 The SMTP envelope

The SMTP envelope is sent as a series of SMTP protocol units (described in
Section 3).  It consists of an originator address (to which error reports
should be directed); one or more recipient addresses; and optional protocol
extension material.  Historically, variations on the recipient address
specification command (RCPT TO) could be used to specify alternate delivery
modes, such as immediate display; those variations have now been deprecated
(see Appendix A.6 and Appendix A.6.6).

2.3.1.2 message SMTP-content

The SMTP content is sent in the SMTP DATA protocol unit. The terms
"message", "message content" and "mail data" are also referring to this term
and are used interchangeably in this document
They all describe the material transmitted after the DATA command is
accepted and before the end of data indication is transmitted.

Message content includes message headers and the possibly-structured message
body.  The MIME specification (RFC2979 [18]) provides the standard
mechanisms for structured message bodies.

The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
the headers and the body.
 If the content conforms to other contemporary standards, the headers form a
collection of field/value pairs structured as in the message format
specification (RFC2822 [9]);

The headers MUST conform to RFC 2822 to form a collection of field/value
pairs structured as in the message format specification (RFC2822 [9]).

The body, if structured, MUST be defined according to MIME (RFC2045 [19]).
The content is textual in nature, expressed using the US-ASCII repertoire
[1].  Although SMTP extensions (such as "8BITMIME", RFC1652 [26]) may relax
this restriction for the content body, the content headers are always
encoded using the US-ASCII repertoire.  A MIME extension (RFC2047 [28])
defines an algorithm for representing header values outside the US-ASCII
repertoire, while still encoding them using the US-ASCII repertoire.

[[ in 3.1 and 3.2 message is used in another way {an 220 (welcome) message}
I suggest to change welcome message in these sections to server greeting.
Also in 4.2.2  and 4.2.3 there is mentioned an 214 help message reply,
If we can rename this to something else (without message) then message will
only refer to the message to be transferred ]]

2.3.2 remains Unchanged

2.3.B(new) Originator
For this draft the originator is the address that is indicated by the MAIL
command (see section XXX) because there can be messages that have an "null"
MAIL command (MAIL FROM:<>)
there can be messages without originator.
An message without originator MUST NOT be regarded as a fake email for this
reason only

The originators address is used to send the
notification message for an delivery failure.

Commonly the originator is also indicated by the RFC2822 /822 Sender: or
From: message header but for this draft only the originator as described in
the first paragraph is important.

If the originator is not "<>" the originator MUST be a valid address, SMTP
servers MAY reject messages if this address is malformed, has an
non-existent domain part, or without a FQDN.

2.3.C(new) recipient

For this draft the recipients are the addresses that are indicated by the
RCPT command (see section XXX) there can be messages that have more than one
recipient.

Commonly the recipients are also indicated by the RFC2822 /822 To: or Cc:
message header but for this draft only the recipients as described in the
first paragraph is important.

A Recipient can be a list, an alias or an mailbox, Only the delivery system
can know what it is, other systems MUST NOT change there behaviour according
to the recipient.

2.3.C.1(new) POSTMASTER recipient

All SMTP servers MUST support the reserved address [[was mailbox]]
"postmaster" as a case-insensitive local name.
The POSTMASTER address is the contact point for mail and mailserver
problems,

This postmaster address is not strictly necessary if the server always
returns 554 on connection opening (as described in Section 3.1).  The
requirement to accept mail for postmaster implies that RCPT commands which
specify a mailbox for postmaster at any of the domains for which the SMTP
server provides mail service, as well as the special case of "RCPT
TO:<Postmaster>" (with no domain specification), MUST be supported

SMTP systems are expected to make every reasonable effort to accept mail
directed to Postmaster from any other system on the Internet.
In extreme cases --such as to contain a denial of service attack or other
breach of security-- an SMTP server may block mail directed to Postmaster.
However, such arrangements SHOULD be narrowly tailored so as to avoid
blocking messages which are not part of such attacks.

[[ The first paragraph is a simplification and variation from section 4.5.1,
in the old version there are some more options NOT to have a postmaster
recipient although I did not see to what kind of SMTP servers this refers,
and in the old section 4.5.1 it did not say why you needed a postmaster
mailbox, mailbox is replaced by address]]

[[ looking at the impossibility to identify delivery servers, is it not an
idea to also include postmaster@hostname as a necessary mailbox to
support, ]]

2.3.3. Basic Mail architecture / Mail Agents

Since RFC 821 and RFC 2821 were published more specific mail terminology
became common.
Were convenient they are used in this specification.
This section describes the MUA (mail user agent) MSA (Mail submission
agent), the MTA (mail transfer agent) and the MDA (mail delivery agent) .
SMTP clients and servers provide a mail transport service and therefore
usually act as "Mail Transfer Agents" (MTAs).
While these terms are used with at least the appearance of great precision
in other environments, the implied boundaries between MUAs, MSAs, MTAs and
MDAs often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader SHOULD NOT infer strong relationships and
responsibilities that might be implied if these terms were used elsewhere.
In general implementations SHOULD NOT without reason assume that they are
only one of the Agent types described here. Full capacity SMTP servers
should be capable to provide all services off MSAs MTAs MDAs and provide MS.

2.3.3.1 (Mail) User Agent, MUA or UA

"Mail User Agents" (MUAs or UAs) are normally thought of as the sources and
targets of mail.
Common  Internet mail clients have limited capacity and are normally
arranged according a Split-(M)UA model, they use different protocols for
receiving and sending of mail.  For receiving POP3 or IMAP are the most
common protocols, while SMTP is used to send mail to an intermediate
receiving host. (MSA)

For this specification Mail User agents are comparable to limited capacity
originating systems (section 2.3.D.1.1)

2.3.3.2  Mail Submission Agent, MSA

MSAs are the SMTP-servers counterparts of (limited capacity) MUAs, they are
commonly intermediate servers that accept all messages from MUAs and process
them and takes responsibility of subsequent distribution.

For this specification Mail Submission agents are comparable to submission
systems (section 2.3.D.2)

2.3.3.3  Mail transfer agent, MTA

MTAs are the most common SMTP clients and servers they provide the transfer
of mail.

For this specification Mail Transfer Agents are comparable to relay and
gateway systems (see section 2.3.D.3 and section 2.3.D.5)

2.3.3.4 Mail Delivery Agent MDA

MDAs are the  final ("delivery") MTA and can be thought of as handing the
mail off to an  MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a mailbox or "message store").
MDA's are also the agents that  interpret and (where necessary,) process the
local part of an address. The MDA takes care of forwarding, aliassing and
list expansion of addresses.

For this specification Mail Delivery Agents are comparable to delivery
systems (see section 2.3.D.4)

2.3.3.5 Message store,  MS

MDAs do the final SMTP- delivery by depositing the message in a mailbox or
"message store"
How an mailclient gets his messages from this mailbox falls outside this
specification.

For this specification Message Stores are part of delivery systems (see
section 2.3.D.4)

2.3.D  Originator, Submitter, Relay,  Delivery, and Gateway Systems

This specification makes a distinction among FIVE types of SMTP systems,
based on the role those systems play in transmitting electronic mail.
[[ sorry it became one more type ;-)]]

2.3.D.1 "originating" SMTP system

An "originating" system (sometimes called an SMTP originator, mail client,
(Mail) User Agent, MUA or UA) introduces mail into the Internet or, more
generally into a transport service environment.

There are two main types of "originating" SMTP systems:
Fully capable originating systems that are expected to support all of the
queuing, retrying, and alternate address functions discussed in this
specification. [[ and they SHOULD also  conform to all regulations for
internet hosts,to be described in section 2.3.4]]

and

Limited capable originating systems that are that transfer all traffic
[[messages??]], regardless of the target domain names associated with the
individual messages, or that do not maintain queues for retrying  message
transmissions or that do not or cannot conform to all regulations for
internet hosts.

2.3.D.1.1 Limited capable originating system

For Limited capable originating systems it is common practice to make
private arrangements to send all messages to a single server for processing
and subsequent distribution, an "submitter" SMTP system.(see below section
2.3.D.2)
SMTP, as specified here, is widely used but not ideally suited for this
role, and standardised mail submission protocols are being developed that
might eventually supersede the current practices (see, e.g., RFC2476 [22]).
In any event, because these arrangements are private and fall outside the
scope of this specification, they are not fully described here.

In any case, restricted-capability clients MUST NOT assume that any SMTP
server on the Internet can be used as their mail processing (relaying) site.

Not-fully capable originating systems SHOULD send all their messages to the
"submitter" SMTP system with which it has made a
private arrangement.

Limited capacity systems are further described in section XXX [[to make]]

2.3.D.2  "submitter" SMTP system
[[ in section 2.1 there is a pointer to section 2.3.8 that should point to
this section]]

"submitter" SMTP systems receive messages from a not-fully capable
originating systems and transfer them according this specification to there
destination.

"submitter" SMTP systems SHOULD have a prior arrangements and MUST do some
kind of authorisation with the "originator" SMTP clients from which they
accept messages. This can be done by SMTP over Transport Layer Security
(RFC3207), SMTP authorisation (RFC 2554), testing the Clients IP address
(from the TCP-info) or other ways

"submitter" SMTP systems SHOULD NOT relay mail from originators with which
it has no agreement to do so. (see the section on Open Relays,)

SMTP, as specified here, is often used but not ideally suited for this role,
and standardised mail submission protocols are being developed that might
eventually supersede the current practices (see, e.g., RFC2476 [22] and
RFC2476bis.).  In any event, because the arrangements between originator
system and submitter system  are private they fall outside the scope of this
specification, they are only informally described here.

"submitter" systems have functionality's that differ from the other SMTP
systems and are were they differ from the other systems specified in section
XXX

[[I think it is a good idea to put all "special" regulations for submitter
systems in one (big) section and that the rest of the draft only specifies
the other SMTP systems, (except many pointers to that section and
subsections....) ]]

SMTP servers that only supports submitting SHOULD NOT have MX records
pointing at them.

Although fully capable SMTP systems [[a term used in section 2.1]] may allow
message submitting it is recommended to have separate hosts for submitting
see [RFC 2476]

2.3.D.3  "relay" SMTP system
A "relay" SMTP system (usually referred to just as a "relay") receives mail
from an SMTP client and transmits it, without modification to the message
data other than adding trace information, to another SMTP server for further
relaying or for delivery.
"relay" SMTP systems differs from "submission" SMTP systems that there are
MX pointers pointing at relay systems, relay systems SHOULD NOT modify the
message data other than adding trace information, to another SMTP server for
further relaying or for delivery.
[[ in other words "submission" servers belong to the
mail-originating-network, relay servers belong to the
mail-recipients-network, but these terms are not RFC either they are from
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html
work in progress]]

2.3.D.4  "delivery" SMTP system

A "delivery" SMTP system is one that receives mail from a transport service
environment and passes it to a mail user agent or deposits it in a message
store which a mail user agent is expected to subsequently access.

A "delivery" SMTP system is the only system that can interpret the localpart
of an address, a "delivery" system therefore the only system that can give
an "authoritative" reply to the VRFY and EXPN commands for his particular
domain.
The "delivery" system takes care of forwarding, aliassing and list expansion
of addresses, and can therefore reintroduce messages in the transport
service environment.

DISCUSSION
An problem is that it is not possible for an common SMTP client to know if
he is transferring to an delivery or an relay system, This implies that the
client can not know if he has got an "authoritative" reply to an VRFY and
EXPN commands.

[[ section 5 mentions a "designated Mail eXchanger" is that an other name
for a "delivery" SMTP system]]

2.3.D.5 "gateway" SMTP system

A "gateway" SMTP system (usually referred to just as a gateway")
receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway system
perform transformations to the message that are not permitted to SMTP relay
systems.
For the purposes of this specification, firewalls that rewrite addresses
should be considered as gateways, even if SMTP is used on both sides of them
(see RFC2979 [18]).
Gateways are described in appendix XXX
[[they are not necessary in the main body of the draft]]

[[Note in draft/Placeholder: There has been a request to expand this
section, possibly into a more extensive model of Internet mail. Comments
from others solicited.]]

2.3.4  Host
[[ added requirements]]

For the purposes of this specification, a host is a computer system
attached to the Internet (or, in some cases, to a private TCP/IP network)
and supporting the SMTP protocol.  Hosts are known by names (see the next
section); they SHOULD NOT be identified by numerical address.
Fully capable SMTP systems MUST conform to the following requirements:

For fully capable SMTP Clients:
The hostname given in the EHLO or HELO command  MUST resolve in a DNS A
record.
That A record MUST point to the SMTP Client.
And the IP address of the SMTP client MUST resolve back to the hostname.

For fully capable SMTP Servers:
The hostname given in the server greeting [[was welcome message]] MUST
resolve in a DNS A record.
That A record MUST point to the SMTP server.
And the IP address of the SMTP server MUST resolve back to the hostname.

2.3.5  Domain Names
[[changed last line]]

A domain name (or often just a "domain") consists of one or more
dot-separated components.  These components ("labels" in DNS terminology,
RFC1035 [5]) are restricted for SMTP purposes to consist of a sequence of
letters, digits, and hyphens drawn from the ASCII character set [1].  Domain
names are used as names of hosts and of other entities in the domain name
hierarchy.
For example, a domain may refer to an alias (label of a CNAME RR) or the
label of Mail    eXchanger records to be used to deliver mail instead of
representing a host name.
See RFC1035 [5] and Section 5 of this specification.

The domain name, as described in this document and in RFC1035 [5], is the
entire, fully-qualified name (often referred to as an "FQDN").  A domain
name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted when
domain names are used in SMTP.  In other words, names that can
be resolved to MX RRs or A RRs (as discussed in Section 5) are permitted, as
are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
nicknames or unqualified names MUST NOT be used.
An exception is the domain name given in the EHLO command this MUST be a
primary host name (a domain name that resolves to an A RR)

DISCUSSION
in the old draft also address literal are allowed.
These should only be allowed for limited capacity systems and not for fully
capable systems, therefore this exception should be stated in section XXX
about limited capacity systems, not in the main section.

2.3.6 Unchanged

2.3.7 Unchanged

2.3.8 replaced by section 2.3.D

2.3.9 submerged in section 2.3.1

2.3.10  Mailbox and Address
[[last line is changed]]

As used in this specification, an "address" is a character string that
identifies a user to whom mail will be sent or a location into which mail
will be deposited.  The term "mailbox" refers to that depository.  The two
terms are typically used interchangeably unless the distinction between the
location in which mail is placed (the mailbox) and a reference to it (the
address) is important.
An address normally consists of user and domain specifications.
The standard mailbox naming convention is defined to be "local-part@domain":
contemporary usage permits a much broader set of applications than simple
"user names".
Consequently, and due to a long history of problems when intermediate hosts
have attempted to optimise transport by modifying them, the local-part MUST
be  interpreted and assigned semantics only by the delivery system that
takes care of  the domain part of the address.
[[last line is changed]]

2.3.11   Reply  unchanged

Content-class: urn:content-classes:message
Subject: RE: RFC 2487 [5]: Suggest dropping of
Date: Sun, 21 Aug 2005 13:32:24 -0400
From: "Eric Burger" <[email-masked]>
To: "thomas schorpp" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

And, by the way, my mail client suggests I not trust your message, as I
cannot verify your signature :)

Signatures are easy; trust relationships are hard.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Sunday, August 21, 2005 10:17 AM
To: thomas schorpp; [email-masked]
Subject: Re: RFC 2487 [5]: Suggest dropping of

You are 3 years to late

See
RFC 3207
SMTP Service Extension for Secure SMTP over Transport Layer Security
(februari 2002)

<original message>
hi there,

i cant find the appropriate WG list to discuss this.
so i posted it here.

item:

Hoffman                     Standards Track                     [Page 1]

RFC 2487                 SMTP Service Extension             January 1999

5. The STARTTLS Command

A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of
the Internet's SMTP infrastructure. A publicly-referenced SMTP server
is an SMTP server which runs on port 25 of an Internet host listed in
the MX record (or A record if an MX record is not present) for the
domain name on the right hand side of an Internet mail address.

suggestion:

1. will be dropped
2. standards will be extended with requirement to present valid
approved-CA-signed certificates at using tls with mailservers
3. standards will be extended to require connection with xsmtps first
with fallback to normal smtp or implement a fallforward to xsmpts if a
server/client requires it..

reasons:

- no more state of the art and technology (1999), nearly all products
support tls
- ongoing criminal phishing activity over smtp
- strong and free certificates for everyone availlable at CACert inc.,
etc.
- ongoing ucbe activity, spammers could be caught and charged more
easily with their certificates as evidence, same to phishers.
- the current state breaks xsmtps networking since theres no method to
notify clients to reattempt with xsmtps.
- expected more systems ressources needed for this are more economical
than current damage from ucbe and phishing
- S/MIME is spreading too slow and unergonomical, risky and too high
effort for simple end users.
- see https, better lets do it on transport layer
- most end users and their certificate trust/intend is controlled mainly
by a well known u.s. software company charging horrent and unreasonable
fees to distribute so even approved CA Certificates cant be easily
mass-provided.
- several local country signature law issues
- information freedom and privacy

.. RFC...

y
tom

To: thomas schorpp <[email-masked]>, [email-masked]
From: [email-masked]
Subject: Re: RFC 2487 [5]: Suggest dropping of
Date: Sun, 21 Aug 2005 15:17:11 +0100
Sender: [email-masked]

You are 3 years to late

See
RFC 3207
SMTP Service Extension for Secure SMTP over Transport Layer Security
(februari 2002)

<original message>
hi there,

i cant find the appropriate WG list to discuss this.
so i posted it here.

item:

Hoffman                     Standards Track                     [Page 1]

RFC 2487                 SMTP Service Extension             January 1999

5. The STARTTLS Command

A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally. This rule
prevents the STARTTLS extension from damaging the interoperability of
the Internet's SMTP infrastructure. A publicly-referenced SMTP server
is an SMTP server which runs on port 25 of an Internet host listed in
the MX record (or A record if an MX record is not present) for the
domain name on the right hand side of an Internet mail address.

suggestion:

1. will be dropped
2. standards will be extended with requirement to present valid
approved-CA-signed certificates at using tls with mailservers
3. standards will be extended to require connection with xsmtps first
with fallback to normal smtp or implement a fallforward to xsmpts if a
server/client requires it..

reasons:

- no more state of the art and technology (1999), nearly all products
support tls
- ongoing criminal phishing activity over smtp
- strong and free certificates for everyone availlable at CACert inc., etc.
- ongoing ucbe activity, spammers could be caught and charged more
easily with their certificates as evidence, same to phishers.
- the current state breaks xsmtps networking since theres no method to
notify clients to reattempt with xsmtps.
- expected more systems ressources needed for this are more economical
than current damage from ucbe and phishing
- S/MIME is spreading too slow and unergonomical, risky and too high
effort for simple end users.
- see https, better lets do it on transport layer
- most end users and their certificate trust/intend is controlled mainly
by a well known u.s. software company charging horrent and unreasonable
fees to distribute so even approved CA Certificates cant be easily
mass-provided.
- several local country signature law issues
- information freedom and privacy

... RFC...

y
tom

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards
Date:  Sun, 21 Aug 2005 15:31:19 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

thomas schorpp wrote:
 
> - esmpts, asmptps...? "x" is a general placeholder/variable
> (basic math, 5th grade) ;)

The "official" abbreviations are not very popular, see also
<http://mid.gmane.org/[email-masked]>

What you really want most probably isn't ESMPTPS - unknown
stranger sends mail, adding encryption won't help you.  You
want "reputation", something telling you that the unknown
stranger is a good guy / new kid / known troublemaker.

For better ideas in this direction see MTAMARK, CSV, and the
HELO part of SPF.   For products in this direction check out
senderbase / ironport / spamcop.
                                 Bye, Frank

Date: Sun, 21 Aug 2005 14:11:28 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards
Cc: thomas schorpp <[email-masked]>
Sender: [email-masked]

thomas schorpp writes:
> Arnt Gulbrandsen wrote:
>>  What is XSMTPS? http://www.google.com/search?q=xsmtps finds only one 
>>  reference to it, and that's the archive of this mailing list thread 
>>  ;)
>
> - esmpts, asmptps...? "x" is a general placeholder/variable (basic math,
> 5th grade) ;)

Why don't you get that requirement into the hypothetical future RFCs for 
esmtps, asmtps and whatever, then?

Arnt

Date: Sun, 21 Aug 2005 13:15:17 +0200
From: thomas schorpp <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
CC: Arnt Gulbrandsen <[email-masked]>
Subject: Re: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards
Sender: [email-masked]

Arnt Gulbrandsen wrote:
> What is XSMTPS? http://www.google.com/search?q=xsmtps finds only one
> reference to it, and that's the archive of this mailing list thread ;)

- esmpts, asmptps...? "x" is a general placeholder/variable (basic math,
5th grade) ;)

- You take google for a knowlegde base ... ? :D

> 
> Arnt
> 
> 

tom

Date: Sun, 21 Aug 2005 10:36:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards
Cc: [email-masked]
Sender: [email-masked]

What is XSMTPS? http://www.google.com/search?q=xsmtps finds only one 
reference to it, and that's the archive of this mailing list thread ;)

Arnt

Date: Sun, 21 Aug 2005 01:50:23 +0200
From: thomas schorpp <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: RFC 2487 [5]: Suggest dropping of "TLS Required"- forbid and extensions of current standards
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms000101000408010809060008
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

hi there,

i cant find the appropriate WG list to discuss this.
so i posted it here.

item:

Hoffman                     Standards Track                     [Page 1]

RFC 2487                 SMTP Service Extension             January 1999

5. The STARTTLS Command

   A publicly-referenced SMTP server MUST NOT require use of the
   STARTTLS extension in order to deliver mail locally. This rule
   prevents the STARTTLS extension from damaging the interoperability of
   the Internet's SMTP infrastructure. A publicly-referenced SMTP server
   is an SMTP server which runs on port 25 of an Internet host listed in
   the MX record (or A record if an MX record is not present) for the
   domain name on the right hand side of an Internet mail address.

suggestion:

1. will be dropped
2. standards will be extended with requirement to present valid
approved-CA-signed certificates at using tls with mailservers
3. standards will be extended to require connection with xsmtps first
with fallback to normal smtp or implement a fallforward to xsmpts if a
server/client requires it..

reasons:

- no more state of the art and technology (1999), nearly all products
support tls
- ongoing criminal phishing activity over smtp
- strong and free certificates for everyone availlable at CACert inc., etc.
- ongoing ucbe activity, spammers could be caught and charged more
easily with their certificates as evidence, same to phishers.
- the current state breaks xsmtps networking since theres no method to
notify clients to reattempt with xsmtps.
- expected more systems ressources needed for this are more economical
than current damage from ucbe and phishing
- S/MIME is spreading too slow and unergonomical, risky and too high
effort for simple end users.
- see https, better lets do it on transport layer
- most end users and their certificate trust/intend is controlled mainly
by a well known u.s. software company charging horrent and unreasonable
fees to distribute so even approved CA Certificates cant be easily
mass-provided.
- several local country signature law issues
- information freedom and privacy

... RFC...

y
tom

--------------ms000101000408010809060008
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms000101000408010809060008--