Subject: Re: "Header Reordering", yet again
From: "Robert A. Rosenberg" <[email-masked]>
To: [email-masked]
Date: Wed, 1 Jun 2005 00:41:39 -0400
List-Id: <ietf-smtp.imc.org>

At 16:33 -0400 on 05/31/2005, Bruce Lilly wrote about Re: "Header 
Reordering", yet again:

>On Tue May 31 2005 15:51, Robert A. Rosenberg wrote:
>
>>  Or link them by having the ID field from the Received Header
>  > replicated in the Received-SPF Header.
>
>Been there, discussed that. The "id" component is optional.
>You can't replicate what isn't there.

If you say so. I've never seen a Received Header that is missing it. 
In any case, I fail to see why replicating it IF IT EXISTS is worse 
than not using it at all since it would help to link the Received-SPF 
and Received Headers when some poorly designed MTA has scrambled the 
order of the headers that were in the message when it was handed off 
to the MTA instead of it just prefixing its Received (and 
Received-SPF) Headers to the front of the header block.

IMO, NO alteration of the header block contents of the message as it 
arrived at the MTA should be permissible unless it is acting as a MSA 
(ie: Accepting a Message from a MUA) when it should restrict its 
alterations to inserting a missing DATE Header (or correcting an 
invalid timestamp) or Message-ID  Header (or other required by 
missing Headers).

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 01 Jun 2005 05:12:38 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 33
Sender: [email-masked]

Bruce Lilly wrote:

>> Now it sounds like an ordinary alias-style forwarder to
>> third parties (5.3.6(a) in 1123).

> No, manual mailing from me.

Okay, that was my third and last attempt to guess what you're
talking about, if you want WXYZ puzzles with W = X = 2 we're
on the wrong list.

>> if the receivers white list your mailouts
[...]
> You're grasping at straws.

That was an enumeration of theoretical possibilities, I said
_could_ and not should.

It's a perfectly normal case for SPF that a primary MX getting
mail from a secondary MX white lists the latter.  If somebody
trusts your manual relaying or whatever it is he _could_ white
list you - of course not for a dyn. IP and an invalid HELO.

>> Reliable MX services are something you can arrange (e.g. buy),

> It's amazing how willing some FUSSP proponents are to spend
> other peoples' money...

And that was an idea how to run your own MTA with a dyn. IP and
a reliable MX.  If you're not interested in those bounces, fine,
stay away from SPF FAIL protected MAIL FROMs.  You simply have
no business to use their MAIL FROMs, otherwise they'd permit it.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Tue, 31 May 2005 22:07:48 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Tue May 31 2005 09:56, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
>   [problem with the mail provider]
> >> your solution was sending direct-to-MX with a MAIL FROM
> >> [email-masked] and a HELO bruces.box.example
>  
> > No, neither MAIL FROM nor HELO/EHLO were changed. no point in
> > changing MAIL FROM, as the intent was not to change where
> > delivery notices were sent.
> 
> Now it sounds like an ordinary alias-style forwarder to third
> parties (5.3.6(a) in 1123).

No, manual mailing from me.

> In fact it _could_ work in several ways, e.g. if the senders
> add your mailouts to their sender policies,

Not applicable.

> Or if the receivers white 
> list your mailouts as "trusted forwarders", maybe depending
> on the RCPT TO, it's also okay.

You're grasping at straws.  That's more onerous than your "use
additional providers" approach.
 
> > You're presuming that there's an MX record (actually >= 2)
> 
> Second time you mention MX > 1, are you sure that you don't
> confuse this with NS > 1 ?

Probably. Anyway, there are none, so my error doesn't matter.
 
> > (due to DHCP, the first is impractical at best, and the
> > second is prohibited by terms of service: "no servers").
> 
> Reliable MX services are something you can arrange (e.g. buy),

It's amazing how willing some FUSSP proponents are to spend
other peoples' money...

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "David MacQuigg" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 19:24:06 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "David MacQuigg" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 31, 2005 3:16 PM
Subject: Re: "Header Reordering", yet again

> I would go even further and say re-ordering of headers by forwarders is
> very rare, but at this point I'm just guessing, so I'll keep  looking for
> any facts to the contrary.

No need to guess.  Its common sense.

First, if it was happening, obviously it isn't something that cause
problems.  Something that tends to cause a noticeable problem will typically
be a) public knowledge, and b) the vendor made aware.   When it comes to
non-isolated problems (a problem related to networking with others), the
problem is usually addressed pronto.  No company NDA will prevent the
exposure of public knowledge for a problem that is noticeable across points.

Point: Mail Distribution Software are the first to find out of problems when
it causes disruption or in the case of something new like a security
concept - a possible reordering issue.

Second,  Where is this Receive-SPF: analysis suppose to take place?

Think about it.   Here is a basic summary framework outline of our decades
old system that has evolved over time:

(01)  network
(02)  --> transport
(03)  --> (DATA) "passive" processor (MFA - mail filter agent)
(04)  -->  gateway (post smtp)
(05)  -->  host system storage
(06)       --o passthru (remote hosting)
(07)           --> push or pull transport
(08)           --> network
(09)       --o local (user hosting)
(10)           --o user online access (text, gui, web)
(11)           --o user offline access
(12)               --o interactive (i.e, pop3, imap)
(13)               --o automated (mail doors)

The possible Receive-SPF analysis points would or could be at:

Point 3 - mail filtering "passive" processor

Point 4 - Gateway?? Local or Domain

So far no damage due to header re-ordering issues.  It can't be presumed to
be incorrect because that means the software is broken.

Point 6?    Out of the question. Typically not something that would be
                part of the passthru/routing process.  But I open to discuss
                this in principle in regards to the chain of trust ideas.

Point 10?  This would be in interesting point, but usually
                the mail is already classified for the user at
                this point. No further server-side checking is done.

Point 11   Offline POP3/IMAP users?   This is what I was
               discussing with Paul  about.

Point 13:   Out of the question.

Overall, in regards to Received-SPF, I would only consider it be useful at
point 3 or point 11 and possibly point 4 if the MFA (mail filter agent) is a
post smtp concept.

Today, our 3rd party vendors use things like SpamAssasin at point 3 MFA
which is the done at the DATA state thus allowing for a dynamic rejection.
I can't tell you if SA is supporting the Receive-SPF: the SMTP processor
adds.

Point: By the time the SPF analyzer needs the header, there is no idea of a
possible reordering of the header.  It will be guarantee to be intact.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Frank Ellermann" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 18:46:42 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, May 31, 2005 3:28 PM
Subject: Re: "Header Reordering", yet again

> [email-masked] wrote:
> 
> > Why do you expect the unwashed heathen masses to upgrade
> > anytime soon?
> 
> If they install SPF checks _and_ add SPF-Received header
> fields _and_ manage to shuffle these header fields before
> the mail arrives in your mailbox tell them to stop this.
>
> Or as RfC 3834 put it for the case of a missing Return-Path:
> 
> | It is better to fix the problem with the mail delivery
> | system than to rely on heuristics to guess the appropriate
> | destination of the response.  Such heuristics have been
> | known to cause problems in the past.

Hey Crash Mail! 

You are making way too much sense!  stop it! <g>

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "David MacQuigg" <[email-masked]>, <[email-masked]>
Subject: Is it really FUD?  [Re: "Header Reordering", yet again]
Date: Tue, 31 May 2005 18:08:15 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: <[email-masked]>
Cc: "David MacQuigg" <[email-masked]>
Sent: Tuesday, May 31, 2005 4:31 PM
Subject: Re: "Header Reordering", yet again

> You have been told about as plainly as possible that you are unlikely
> to see specifics because of NDAs.  And your response has been to say
> "nobody answered" and -- having complained of a bruised ego after
> what appears to have been very professional responses to your messages --
> accusing others with "this is FUD".

How does a NDA stop the viewable presence of bugs and its end results in
mail software?

I hope this doesn't bruise your ego,  but you would seem to be the type who
is a heavy cyberspace participating techie end-user and typically the first
to be yelling non-compliance and rudely putting anyone down who doesn't come
close to agreeing with you.

The fact is, it is YOU who seems not to be listening or EVEN wish to give
anyone outside of a small click of people, the benefit of the doubt,
regardless of any experience they may have.

The fact is, sysops do not sign NDAs.  If the software is broken and causes
uplink and downlink problems, no NDA will ever stopped it from being public
knowledge.  And even if there is a NDA, it comes with the understanding the
vendor is will be fixing the problem.

The fact is you can't come up with one instance this is a problematic,
especially with a concept where a Received-SPF: could come into place.

> The simple matter is that you have been told that your assumption of
> particular ordering is invalid, you have been provided with documentation
> in the form of IETF specifications (RFCs) which clearly and distinctly
> say so, you have been assured that in fact reordering is known to have
> taken place, and you have been told why you are unlikely to be provided
> with an example.  Yet you persist with an insistence that there is some
> requirement forbidding reordering.  One gets the impression that you're
> just not listening.

This seems to be your modus operandi when you can't prove your point.

But it is YOU who is not listening.

Bruce, you don't design software on the presumption that headers could be
out of order or reordered, or what have you. Why would you presume that a
NEW header will be added randomly or in the wrong place?

Really, it seems to me you are a power end-user who wants to use his MUA for
everything and uses this as the basis for his mail operation reality.

In regards to SPF,  the only headers that should be concern is that of the
last transaction.  At best, the SPF analyzer could have:

    Return-Path:
    Received-SPF:
    Received:

Now why would anyone presume NEW SOFTWARE,  out of the gate could be out of
order with the rest of the message/trace headers is beyond me.

Again, this all seems that you are probably thinking in terms of your MUA
software.  That is the only thing that make sense.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>, <[email-masked]>, "Paul Smith" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 16:42:47 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Paul Smith" <[email-masked]>
To: "Hector Santos" <[email-masked]>; "Frank Ellermann"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, May 31, 2005 10:31 AM
Subject: Re: "Header Reordering", yet again

> >Is this what you are doing?  Using SPF in your VPOP3?  (Assuming VPOP3 is
> >some user's pop3 proxy application)
>
> Don't get me involved ;)
> It wasn't my original suggestion..

Right. I knew that. :-)

I was thinking in terms WHO could be faced with this situation?  I figued
you would be one vendor facing this and were providing some insight on how
you was addressing it. :-)  It would be after it was all send and done, at
some MUA, maybe with POP3, like the Thunderbird MUA, which I believes has
SPF checking at the MUA..

> But - we do get requests for SPF support on incoming SMTP via an ISP's
> server, or on incoming POP3 mail. At the moment, we're reluctant to do it
> because of the problem of knowing exactly which mail server in the trace
> headers was the one we should be checking. This could be handled by a
> knowledgeable user telling our software which mail server(s) were the
> recipients' ISPs - but knowledgeable users are few and far between in our
> market (SMEs) so you need to do it automatically, or not at all..

Right.

You can't guarantee original header information will be provided by the POP3
server.  The mail could of storage in native format.

Do you know (if you explored it) if Thunderbird faces these issue?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 16:33:31 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Tue May 31 2005 15:51, Robert A. Rosenberg wrote:

> Or link them by having the ID field from the Received Header 
> replicated in the Received-SPF Header.

Been there, discussed that. The "id" component is optional.
You can't replicate what isn't there.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 16:31:51 -0400
Cc: David MacQuigg <[email-masked]>
Sender: [email-masked]

On Tue May 31 2005 15:16, David MacQuigg wrote:
> 
> At 01:33 PM 5/31/2005 -0400, Bruce Lilly wrote:
> >On Tue May 31 2005 12:34, David MacQuigg wrote:
> >
> > > Nobody answered my challenge to provide an example of a big forwarder that
> > > re-orders headers, so I'm coming to the conclusion that this is FUD.
> >
> >Funny, my conclusion is that many people have taken Keith Moore's
> >suggestion: http://www.imc.org/ietf-smtp/mail-archive/msg01559.html
> 
> You raised this topic with your out-of-context quote from RFC-2822, and the 
> implication that that header reordering is a big problem, something that 
> would stop any reliance on header order.

What I said was that there is no guarantee of order, and I cited
RFC 2822 (and could also have cited RFC 2046 section 5.2, last
paragraph) which explicitly notes that reordering in fact occurs.

> I'm new to this list, so it wasn't clear to me that this is one of those 
> "rathole" topics.

I didn't categorize the topic per se as a rathole, and I note that
that's not all that Keith mentioned.  I'll leave it at that.

> I suggest that if you raise the topic again, you do it in a less "forceful" 
> way.  You could say for example - While it is common practice for MTAs to 
> comply with RFC-2822, and not re-order headers,

In spite of it being pointed out several times, you have again made
the error of equating RFC 2822 compliance (FWIW) with "not re-order
headers [sic]".  One last time; "SHOULD" is not a compliance requirement,
it is merely a recommendation.  If you didn't get the message with a
direct quote and referral to BCP 14 for the meaning of "SHOULD", it is
inconceivable that the concept would have sunk in with "a less 'forceful'"
pointer to the facts.

> I would go even further and say re-ordering of headers by forwarders is 
> very rare, but at this point I'm just guessing, so I'll keep  looking for 
> any facts to the contrary.

You have been told about as plainly as possible that you are unlikely
to see specifics because of NDAs.  And your response has been to say
"nobody answered" and -- having complained of a bruised ego after
what appears to have been very professional responses to your messages --
accusing others with "this is FUD".

The simple matter is that you have been told that your assumption of
particular ordering is invalid, you have been provided with documentation
in the form of IETF specifications (RFCs) which clearly and distinctly
say so, you have been assured that in fact reordering is known to have
taken place, and you have been told why you are unlikely to be provided
with an example.  Yet you persist with an insistence that there is some
requirement forbidding reordering.  One gets the impression that you're
just not listening.

From: "Hector Santos" <[email-masked]>
To: "Paul Smith" <[email-masked]>, "Frank Ellermann" <[email-masked]>, <[email-masked]>, "David MacQuigg" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 16:24:24 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "David MacQuigg" <[email-masked]>
To: "Paul Smith" <[email-masked]>; "Hector Santos"
<[email-masked]>; "Frank Ellermann" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 31, 2005 12:34 PM
Subject: Re: "Header Reordering", yet again

> Nobody answered my challenge to provide an example of a big forwarder that
> re-orders headers, so I'm coming to the conclusion that this is FUD.

Most people did already come to this conclusion long ago.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>, <[email-masked]>, "Paul Smith" <[email-masked]>
Subject: Re: "Header Reordering", yet again 
Date: Tue, 31 May 2005 16:18:51 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>
Sent: Tuesday, May 31, 2005 12:03 PM
Subject: Re: "Header Reordering", yet again

> If (hypothetically - I've not caught either actually
> *doing* this) we found a case where Sendmail or Exchange
> was doing this, you would have to:

> a) Get the vendor to fix it.
> b) Wait for sites to actually *install* the update.

> Why do you expect the unwashed heathen masses to upgrade anytime soon?

Lets not talk about general situations. Sure, the problem can linger.

In the specific case in mail operations where there is something that is
seriously have interface issues with uplinks and downlinks, these things
usually get resolved.  If the problem bothers you, I'm sure you as will most
people
will do something about it, like upgrade, as will most vendors will provide
the fix.

This is especially those operating in the commericial environment.  Most
people
will not tolerate severily broken software if it is caused issues across
points.

I don't see that here with Re-Ordering and even it was happening, it
would be at points where its job is already done of delivering mail.

Also, we are talking about SPF software that will do the insertion. Why
do you assume to they will be broken in the first place to add an header
in the wrong place?     What software is between reception and the point
where Receiver-SPF: is analyzed will do header re-ordering?

Are the old sendmail systems re-ordering headers at reception?
Clearly it is not doing SPF directly.  So at which point are you talking
about where this SPF header issue become a potential consideration?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 31 May 2005 15:51:08 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 14:05 +0100 on 05/31/2005, Paul Smith wrote about Re: "Header 
Reordering", yet again:

>If you specified that the timestamp on the Received-SPF field MUST be
>IDENTICAL to the timestamp on the Received: line added by the same server,
>that might solve some problems.

Or link them by having the ID field from the Received Header 
replicated in the Received-SPF Header.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: "Header Reordering", yet again
Date:  Tue, 31 May 2005 21:28:21 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

[email-masked] wrote:

> Why do you expect the unwashed heathen masses to upgrade
> anytime soon?

If they install SPF checks _and_ add SPF-Received header
fields _and_ manage to shuffle these header fields before
the mail arrives in your mailbox tell them to stop this.

Or as RfC 3834 put it for the case of a missing Return-Path:

| It is better to fix the problem with the mail delivery
| system than to rely on heuristics to guess the appropriate
| destination of the response.  Such heuristics have been
| known to cause problems in the past.

                             Bye, Frank

Date: Tue, 31 May 2005 12:16:25 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 01:33 PM 5/31/2005 -0400, Bruce Lilly wrote:
>On Tue May 31 2005 12:34, David MacQuigg wrote:
>
> > Nobody answered my challenge to provide an example of a big forwarder that
> > re-orders headers, so I'm coming to the conclusion that this is FUD.
>
>Funny, my conclusion is that many people have taken Keith Moore's
>suggestion: http://www.imc.org/ietf-smtp/mail-archive/msg01559.html

You raised this topic with your out-of-context quote from RFC-2822, and the 
implication that that header reordering is a big problem, something that 
would stop any reliance on header order.

I'm new to this list, so it wasn't clear to me that this is one of those 
"rathole" topics.  It seemed to me that it was worth exploring, even 
pushing a little to see if there was some substance behind the claim.  I 
have my answer now, so in the future, I will just refer to this thread.

I suggest that if you raise the topic again, you do it in a less "forceful" 
way.  You could say for example - While it is common practice for MTAs to 
comply with RFC-2822, and not re-order headers, as always there are 
non-compliant systems, and we should be careful that anything we design can 
deal with those systems.

I would go even further and say re-ordering of headers by forwarders is 
very rare, but at this point I'm just guessing, so I'll keep  looking for 
any facts to the contrary.

--
Dave

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 31 May 2005 11:37:23 -0700 (PDT)
From: "william(at)elan.net" <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Frank Ellermann <[email-masked]>, Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>, Paul Smith <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1747400512-1122050169-1117562362=:24390
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <[email-masked]>

On Tue, 31 May 2005, Arnt Gulbrandsen wrote:

>
> Valdis Kltnieks writes:
>> If you're planning to go down this bad-idea path, you *really* need to 
>> specify
>> that the two headers are linked with some glob that has msgid-like 
>> uniqueness
>> properties....
>
> Or just use DomainKeys to sign the Received-SPF header field ;)

You should be more serious, this can actually be quite good if properly
developed.

--------
Now, since this is IETF list IPR declaration/info is appropriate as I have 
recently filed patent application in this area that would in part cover
domainkeys-like MTA cryptographic signature system signing message 
data with information about previous hop (i.e. its address, etc) and/or
information about how that hop was authorized. The recipient (MUA or MDA) 
would be expected to authorize the signature using signing system hostname
as "sender" and if it recognized that hostname as being "trusted forwarder"
(or authorization can be based on cryptographically verifiable relationship
with recipient which establishes this trust), it can then use signed data 
about source system entered by the forwarder (either info about authorization
results or it can do its own SPF or like path authorization based on 
original connection source and identity data that forwarder saw).

Note: Domainkeys itself can not be used because it can only add signature
if signing system is working on behalf of the sender and then dk signing
system would be expected to have access to sender's private key. Where as 
forwarding systems are not working on behalf of the sender, but on behalf 
of the recipient so different type of cryptographic relationship can be 
used and different type of signature authorization. But META Signatures 
can be used here if authorization is based on signing system name (entered
as sender name, this is more clear in upcoming 0.21 spec which actually 
allows to specify type authorization sender relationship).
--------

As for identification trace data entered by one system and making sure
trace data is properly ordered and recognized, I've been working on this 
concept as well and decided to just add starting and ending trace header 
fields to identify trace block added by one system. Yes, I know new trace 
fields can not be relied to not have been reordered and you'll see me 
deal with that in future draft. Below is an example of how this trace data 
block might look like (and sorry about long example and fields with syntax
from documents not yet released):

Trace-End: ml.example.com ; seq=101; time="Thu, 26 May 2005 05:20:05-0700"
META-Signature: ver=1.0 i=ml.example.com t=1094844754.338503 x=432000 ;
       cont=hlist h=Received,Redirected,Trace-*,Saved-*,EDigest,Message-ID,
         From,To,Date,Content-* ;
       sig=rsa-sha1 d="grUU7EOwzCbuoejh39KE+epT3zGdmAP693IOGujxSBb+4qtI1..."
 	e="Iw==" m="zCnd+ByA23/7WMiIwaIZ7Ez3DplzVMdRKP138IXLOvBV..." ;
��    id=host s=ml.example.com ;
       auth=txt u="dns:ml.example.com?type=SPF" fp="fp1="
EDigest: v=1.0 a=sha1 c=nofws e=7bit i=ml.example.com t=1094844765.334354
       d="51f0483a89e441e2fc45a12a4303ca217f34617e="
Received: (from majordom@localhost)
     by ml.example.com (8.12.11/8.12.9/Submit) id abcderfg;
     Thu, 26 May 2005 05:20:04 -0700 
Saved-Subject: "[list] Test"
Saved-Reply-To: [email-masked]
Saved-List-ID: <list.example.com>
Redirected: by ml.example.com (ip=[10.5.0.1])
             on-behalf-of [email-masked] process-type mail-list
             original-envelope recipient=[email-masked]
               return-path=[email-masked]
             new-envelope recipient=[email-masked]
               return-path=[email-masked]
             changed-header Reply-To, List-ID, Subject ;
 	    Thu, 26 May 2005 05:20:04 -0700
Received: from origin.example.com (origin.example.com [10.0.0.1]
     by ml.example.com (8.12.11/8.12.9) with SMTP id abcdefg
     for <[email-masked]>; Thu, 26 May 2005 05:20:03 -0700 
Trace-Start: ml.example.com ; seq=101; time="Thu, 26 May 2005 05:20:03-0700"

P.S. I'm also going to take into account (in the draft) that most end-users 
don't want to see that much trace data (or in fact any trace data and 
certainly don't want to have to download 5k message when it really has
only 10 words in the body) and its only of interest during mail processing 
or debugging errors or abuse in most cases.

-- 
William Leibzon
Elan Networks
[email-masked]
---1747400512-1122050169-1117562362=:24390--

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 13:33:08 -0400
Sender: [email-masked]

On Tue May 31 2005 12:34, David MacQuigg wrote:

> Nobody answered my challenge to provide an example of a big forwarder that 
> re-orders headers, so I'm coming to the conclusion that this is FUD.

Funny, my conclusion is that many people have taken Keith Moore's
suggestion: http://www.imc.org/ietf-smtp/mail-archive/msg01559.html

Date: Tue, 31 May 2005 10:15:48 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again 
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:06 PM 5/31/2005 -0400, [email-masked] wrote:

>On Tue, 31 May 2005 09:46:57 PDT, David MacQuigg said:
>
> > I would accept as proof two messages, one sent directly to the receiver,
> > the other through the forwarder, both identical going in.
>
>a) This tells you something between zero and diddly about any of the headers
>that were acquired along the route through the forwarder - and we could 
>*easily*
>be talking 20-25 of them if the forwarder is a mailing list.

Doesn't matter.  All I care about is that the Trusted Forwarder not 
re-order the headers he receives.  He can add whatever headers he wants 
within his own administrative domain.

>b) The fact that your test case shows up without anything reordered doesn't
>prove that there's no misbehavior in other cases (or did you actually *test*
>cases like "more than 900 local recipients *and* more than 100 recipients at
>another host that happens to have us as a secondary MX forwarder" - had *that*
>give some software some indigestion.  Worst part was that it actually 
>manifested
>as a doubly-linked file in the message store - seems when a %3d rolled over in
>the same message, the same filename got created for the 3rd and 1003rd 
>recipients ;)

If this were a widespread problem, you would be able to show an example and 
explain it in simple words.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: David MacQuigg <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: "Header Reordering", yet again 
From: [email-masked]
Date: Tue, 31 May 2005 13:06:02 -0400
Sender: [email-masked]

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

On Tue, 31 May 2005 09:46:57 PDT, David MacQuigg said:

> I would accept as proof two messages, one sent directly to the receiver, 
> the other through the forwarder, both identical going in.

a) This tells you something between zero and diddly about any of the headers
that were acquired along the route through the forwarder - and we could *easily*
be talking 20-25 of them if the forwarder is a mailing list.

b) The fact that your test case shows up without anything reordered doesn't
prove that there's no misbehavior in other cases (or did you actually *test*
cases like "more than 900 local recipients *and* more than 100 recipients at
another host that happens to have us as a secondary MX forwarder" - had *that*
give some software some indigestion.  Worst part was that it actually manifested
as a doubly-linked file in the message store - seems when a %3d rolled over in
the same message, the same filename got created for the 3rd and 1003rd recipients ;)

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

--==_Exmh_1117559161_3502P--

Date: Tue, 31 May 2005 09:46:57 -0700
To: [email-masked], Frank Ellermann <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again 
Cc: [email-masked]
Sender: [email-masked]

At 12:05 PM 5/31/2005 -0400, [email-masked] wrote:
>On Tue, 31 May 2005 17:19:41 +0200, Frank Ellermann said:
> > Arnt Gulbrandsen wrote:
> >
> > > just use DomainKeys to sign the Received-SPF header field ;)
> >
> > Try `nslookup -q=mx` and find the corresponding header fields,
> > for an environment where they arrive out of order.
> >
> > In an environment where these headers are only sometimes added,
> > _and_ arrive out of order, _and_ a spammer finds the way where
> > they are not added, _and_ the spammer forged a PASS you lose -
> > or you ask your postmaster to fix it.
>
>Identifying conclusively that headers were added out of order is problematic
>when not everybody runs NTP or other timesync.

I would accept as proof two messages, one sent directly to the receiver, 
the other through the forwarder, both identical going in.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 31 May 2005 09:34:54 -0700
To: Paul Smith <[email-masked]>, "Hector Santos" <[email-masked]>, "Frank Ellermann" <[email-masked]>, <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 03:31 PM 5/31/2005 +0100, Paul Smith wrote:
>At 14:58 31/05/2005, Hector Santos wrote:
>>From: "Paul Smith" <[email-masked]>
>>
>> > >Now you might be able to sort the timestamp lines by their
>> > >timestamps, or more likely by "I know what happens behind
>> > >my MX".  Or you just use `nslookup -q=mx`.
>> >
>> > If you specified that the timestamp on the Received-SPF field MUST be
>> > IDENTICAL to the timestamp on the Received: line added by the same server,
>> > that might solve some problems.
>>
>>Good point,
>>
>>but I'm still scratching my head on this issue,  what's the problem again?
>
>Not entirely sure.. I've lost the start of this discussion as the subject 
>has changed a few times.. :)

http://www.imc.org/ietf-smtp/mail-archive/threads.html does a good job of 
keeping these long threads in order.

We are still on Header Reordering, I assume.  I started this sub-thread 
with the statement - Legitimate MTAs should leave existing headers alone. 
Only the final MTA will be looking at the trace headers to determine the 
border MTA (the MTA on first entry to our trust zone). The border MTA will 
attempt to authenticate the prior hop, and before that, we don't care.

I haven't heard anything sufficient to change my mind.  I would only change 
the words "legitimate MTAs" to "Trusted Forwarders".  This business of 
time-stamps seems like a digression.  If we can trust an MTA to add a 
properly synchronized time-stamp, we can trust it to not re-order headers, 
with a lot less effort and opportunity for screw up, I might add.  The 
requirement is simply - DON'T MESS WITH THE HEADERS!!

I know, the temptation to diddle the headers can be irresistible :>), but 
if we are going to change the world, we have to start somewhere.  Nothing 
will ever happen if we follow the Bruce Lilly policy - reject any proposal 
that doesn't have a guarantee that all MTAs will conform.  Even DomainKeys 
will fail that test.  There is no guarantee that some MTA, somewhere on the 
planet, won't alter the message, and DomainKeys cannot tell the difference 
between a forgery and a message altered by a non-conformant MTA.

>>Why would a downlink software assume the headers are or could be out of
>>order?  and why would it assume mediocrity exist or even allow it to be
>>used?    I mean, if a piece of software was doing this,  then you go to the
>>developer and shame them for screwing things up.  If they don't bother to
>>fix it, then you dump it and get something else.  That's how it usually
>>works.
>
>Unless that other developer is Microsoft or that of any other widely 
>deployed software or used by any big ISP. In that case, they are unlikely 
>to change just for you, and you'll lose customers if you do anything bad 
>because of the faulty data.

Nobody answered my challenge to provide an example of a big forwarder that 
re-orders headers, so I'm coming to the conclusion that this is FUD.

>But - we do get requests for SPF support on incoming SMTP via an ISP's 
>server, or on incoming POP3 mail. At the moment, we're reluctant to do it 
>because of the problem of knowing exactly which mail server in the trace 
>headers was the one we should be checking. This could be handled by a 
>knowledgeable user telling our software which mail server(s) were the 
>recipients' ISPs - but knowledgeable users are few and far between in our 
>market (SMEs) so you need to do it automatically, or not at all..

I agree 100% that the process of scanning headers to locate the domain to 
be rated, should be automatic, simple, and unambiguous.  A standard 
authentication header could do that.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: "Header Reordering", yet again 
From: [email-masked]
Date: Tue, 31 May 2005 12:05:04 -0400
Sender: [email-masked]

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

On Tue, 31 May 2005 17:19:41 +0200, Frank Ellermann said:
> 
> Arnt Gulbrandsen wrote:
>  
> > just use DomainKeys to sign the Received-SPF header field ;)
> 
> Try `nslookup -q=mx` and find the corresponding header fields,
> for an environment where they arrive out of order.  
> 
> In an environment where these headers are only sometimes added,
> _and_ arrive out of order, _and_ a spammer finds the way where
> they are not added, _and_ the spammer forged a PASS you lose -
> or you ask your postmaster to fix it.

Identifying conclusively that headers were added out of order is problematic
when not everybody runs NTP or other timesync.

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

--==_Exmh_1117555504_3502P--

To: Hector Santos <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked], Paul Smith <[email-masked]>
Subject: Re: "Header Reordering", yet again 
From: [email-masked]
Date: Tue, 31 May 2005 12:03:01 -0400
Sender: [email-masked]

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

On Tue, 31 May 2005 09:58:58 EDT, Hector Santos said:

> Why would a downlink software assume the headers are or could be out of
> order?  and why would it assume mediocrity exist or even allow it to be
> used?    I mean, if a piece of software was doing this,  then you go to the
> developer and shame them for screwing things up.  If they don't bother to
> fix it, then you dump it and get something else.  That's how it usually
> works.

If (hypothetically - I've not caught either actually *doing* this) we found a
case where Sendmail or Exchange was doing this, you would have to:

a) Get the vendor to fix it.
b) Wait for sites to actually *install* the update.  Note that the mail I'm
replying to passed through a host claiming: (8.12.11/8.12.9).  Sendmail 8.12.11
came out 2004/01/18 - and their .cf file is against .9, which dates to 2003/03/29

Now if the site that's *hosting* this list (so we're presumably "preaching to
the choir" at that point) hasn't installed any of these Sendmails:

8.13.4/8.13.4   2005/03/27
8.13.3/8.13.3   2005/01/11
8.13.2/8.13.2   2004/12/15
8.13.1/8.13.1   2004/07/30
8.13.0/8.13.0   2004/06/20
8.12.11/8.12.11 2004/01/18
8.12.10/8.12.10 2003/09/24 (Released: 2003/09/17)
8.12.9/8.12.9   2003/03/29

Why do you expect the unwashed heathen masses to upgrade anytime soon?

I'm told that there's still some Sendmail 5.65 boxes occasionally spotted on
the open Internet.  Even *this year* I've personally seen 3 postings on NANOG from
somebody still running 8.6.9 (8.6.10 came out 1995/02/10).

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

--==_Exmh_1117555380_3502P--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: "Header Reordering", yet again
Date:  Tue, 31 May 2005 17:19:41 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

Arnt Gulbrandsen wrote:
 
> just use DomainKeys to sign the Received-SPF header field ;)

Try `nslookup -q=mx` and find the corresponding header fields,
for an environment where they arrive out of order.  

In an environment where these headers are only sometimes added,
_and_ arrive out of order, _and_ a spammer finds the way where
they are not added, _and_ the spammer forged a PASS you lose -
or you ask your postmaster to fix it.

                           Bye, Frank

Date: Tue, 31 May 2005 16:40:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Cc: Frank Ellermann <[email-masked]>, Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>, Paul Smith <[email-masked]>
Sender: [email-masked]

Valdis Klētnieks writes:
> If you're planning to go down this bad-idea path, you *really* need to 
> specify
> that the two headers are linked with some glob that has msgid-like uniqueness
> properties....

Or just use DomainKeys to sign the Received-SPF header field ;)

Arnt

Date: Tue, 31 May 2005 15:31:16 +0100
To: "Hector Santos" <[email-masked]>, "Frank Ellermann" <[email-masked]>, <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 14:58 31/05/2005, Hector Santos wrote:

>----- Original Message -----
>From: "Paul Smith" <[email-masked]>
>To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
>Sent: Tuesday, May 31, 2005 9:05 AM
>Subject: Re: "Header Reordering", yet again
>
>
> > >Now you might be able to sort the timestamp lines by their
> > >timestamps, or more likely by "I know what happens behind
> > >my MX".  Or you just use `nslookup -q=mx`.
> >
> > If you specified that the timestamp on the Received-SPF field MUST be
> > IDENTICAL to the timestamp on the Received: line added by the same server,
> > that might solve some problems.
> >
>
>Good point,
>
>but I'm still scratching my head on this issue,  what's the problem again?

Not entirely sure.. I've lost the start of this discussion as the subject 
has changed a few times.. :)

>Why would a downlink software assume the headers are or could be out of
>order?  and why would it assume mediocrity exist or even allow it to be
>used?    I mean, if a piece of software was doing this,  then you go to the
>developer and shame them for screwing things up.  If they don't bother to
>fix it, then you dump it and get something else.  That's how it usually
>works.

Unless that other developer is Microsoft or that of any other widely 
deployed software or used by any big ISP. In that case, they are unlikely 
to change just for you, and you'll lose customers if you do anything bad 
because of the faulty data.

>Is this what you are doing?  Using SPF in your VPOP3?  (Assuming VPOP3 is
>some user's pop3 proxy application)

Don't get me involved ;)
It wasn't my original suggestion..

We can do SPF in our VPOP3, but only on direct incoming SMTP (so header 
lines are irrelevant, it just looks at the sender's IP address)

(VPOP3 is a POP3/SMTP/IMAP4 mail server, not a proxy, BTW)

But - we do get requests for SPF support on incoming SMTP via an ISP's 
server, or on incoming POP3 mail. At the moment, we're reluctant to do it 
because of the problem of knowing exactly which mail server in the trace 
headers was the one we should be checking. This could be handled by a 
knowledgeable user telling our software which mail server(s) were the 
recipients' ISPs - but knowledgeable users are few and far between in our 
market (SMEs) so you need to do it automatically, or not at all..

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

To: Paul Smith <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: "Header Reordering", yet again 
From: [email-masked]
Date: Tue, 31 May 2005 10:20:01 -0400
Sender: [email-masked]

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

On Tue, 31 May 2005 14:05:13 BST, Paul Smith said:

> If you specified that the timestamp on the Received-SPF field MUST be 
> IDENTICAL to the timestamp on the Received: line added by the same server, 
> that might solve some problems.

Nope.  I've seen a piece of mail pick up 5 different Received: headers with
the same HH:MM:SS timestamp legitimately (OK, so it *was* a high-performance
mail system sized for max daytime loads, and 2AM on a holiday during a vacation ;)

And that was with 3 servers that were NTP-synched.  What happens if ServerA
sends mail to ServerB, and ServerB's clock is slightly behind? (I've seen
stuff go 8-10 hops, and the next hop still got a timestamp a few seconds earlier
than the first hop - if the clocks were closer together, they'd collide).

If you're planning to go down this bad-idea path, you *really* need to specify
that the two headers are linked with some glob that has msgid-like uniqueness
properties....

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

--==_Exmh_1117549201_3664P--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Tue, 31 May 2005 15:56:10 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 79
Sender: [email-masked]

Bruce Lilly wrote:

  [problem with the mail provider]
>> your solution was sending direct-to-MX with a MAIL FROM
>> [email-masked] and a HELO bruces.box.example
 
> No, neither MAIL FROM nor HELO/EHLO were changed. no point in
> changing MAIL FROM, as the intent was not to change where
> delivery notices were sent.

Now it sounds like an ordinary alias-style forwarder to third
parties (5.3.6(a) in 1123).  We already discussed this case,
it's also addressed in the SPF draft, and the short form is
"it doesn't work with SPF".

That's unrelated to your example "technical problem with the
mail provider", it doesn't work even without this problem.

In fact it _could_ work in several ways, e.g. if the senders
add your mailouts to their sender policies, then you're free
to keep their original MAIL FROM.  Or if the receivers white
list your mailouts as "trusted forwarders", maybe depending
on the RCPT TO, it's also okay.

Let's assume that it doesn't work, but you never noticed it,
because you mail provider handled it.  Now you're trying to
forward direct-to-MX.  The MAIL FROM is protected by an SPF
FAIL policy, it doesn't permit a:bruces.box.example, and the
MX checks SPF.

Then you get a reject from the MX, and you create a bounce
message to the original sender.  Ready, that's all, just like
a "551 user not local", working as designed.

There are essentially three ways to make it work with SPF:
- the sender policy adopts your MTAs ("Bruce is one of ours")
- the receiver white lists your MTAs ("I trust Bruce's MTAs")
- you take the responsibility for this mailing list, 5.3.6(b),
  using your own MAIL FROM

You're of course free to say that it's not your problem what
the sender and the receiver do, and if the pseudo-551 bounces
annoy you talk with the sender.

> your scheme to do what I achieved in about a minute would be
> to change SPF records under some domain

No, I would just take the responsibility for the redistribution
and use my own MAIL FROM.  In reality I'm not planning to host
a mailing list. 

For my original example "problem with A, therefore send via B"
SPF was irrelevant, my UA automatically uses the MAIL FROM for
B if I send via B.

And B was an SMTP-after-POP "MSA" enforcing submission rights
(2476 6.1), I had to say MAIL FROM:<[email-masked]> - it
wouldn't let me send any MAIL FROM:<nobody@xyzzy>.  That's as
it should be, especially for SMTP-after-POP.  Adding SPF FAIL
for A = @xyzzy didn't change anything for this MSA provider B.

> You're presuming that there's an MX record (actually >= 2)

Second time you mention MX > 1, are you sure that you don't
confuse this with NS > 1 ?

> (due to DHCP, the first is impractical at best, and the
> second is prohibited by terms of service: "no servers").

Reliable MX services are something you can arrange (e.g. buy),
the place where I got xyzzy.dnsalias.org offers it - no, I
don't use this "dnsalias" as mailout, therefore I also don't
need a reliable MX, but _in theory_ I'd know where to get it.

Again, _in theory_ and of course compatible with SPF.  This
theoretical case starts to get more interesting with MTAMARK.

                           Bye, Frank

From: "Hector Santos" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>, <[email-masked]>, "Paul Smith" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Tue, 31 May 2005 09:58:58 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Paul Smith" <[email-masked]>
To: "Frank Ellermann" <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 31, 2005 9:05 AM
Subject: Re: "Header Reordering", yet again

> >Now you might be able to sort the timestamp lines by their
> >timestamps, or more likely by "I know what happens behind
> >my MX".  Or you just use `nslookup -q=mx`.
>
> If you specified that the timestamp on the Received-SPF field MUST be
> IDENTICAL to the timestamp on the Received: line added by the same server,
> that might solve some problems.
>

Good point,

but I'm still scratching my head on this issue,  what's the problem again?

Why would a downlink software assume the headers are or could be out of
order?  and why would it assume mediocrity exist or even allow it to be
used?    I mean, if a piece of software was doing this,  then you go to the
developer and shame them for screwing things up.  If they don't bother to
fix it, then you dump it and get something else.  That's how it usually
works.

And in regards to SPF,  I suspect we are talking about some post SMTP
software, in which case,  at a minimum, the post smtp analyzer would be
seeing and only be interested in headers for the current transaction or last
route:

        Return-Path:
        Received-SPF:
        Received:

Anyway, I personally encounter any situation (nor would I tolerate it if I
did) that will be screwing around with mail tampering or changing of trace
and messages headers to the extent it is reordering it during the points
from reception to final storage.

After final storage, it is outside of my control or responsibility.

The only situation I can see where this *may* all matter for SPF is a some
hook for POP3 off-line systems attempting to do some offline SPF checking.
In this case, the only post final storage software that I can see that *may*
do some changes are:

- list servers (only because I hear from OTHERS that there are some that
might do this)

- gateways from native host mail formats back to RFC, in which case, the
original trace RFC information might be lost.

Is this what you are doing?  Using SPF in your VPOP3?  (Assuming VPOP3 is
some user's pop3 proxy application)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 31 May 2005 14:05:13 +0100
To: Frank Ellermann <[email-masked]>, [email-masked]
From: Paul Smith <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 15:51 29/05/2005, Frank Ellermann wrote:

> > it is much too late to change the syntax of Received: fields.
> > And even if it were applied to Received-SPF fields, it does
> > nothing to keep the Received-SPF ordered relative to
> > Received: fields.
>
>Let's assume the header fields in fact are reordered, among
>them some Received-SPF.
>
>Now you might be able to sort the timestamp lines by their
>timestamps, or more likely by "I know what happens behind
>my MX".  Or you just use `nslookup -q=mx`.

If you specified that the timestamp on the Received-SPF field MUST be 
IDENTICAL to the timestamp on the Received: line added by the same server, 
that might solve some problems.

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: MTAMARK
Date:  Tue, 31 May 2005 14:35:27 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Sender: [email-masked]

[email-masked] wrote:

> And there *was* general acceptance of the concept that the
> Sendmail could connect to whatever MX destinations it wanted
> to

No problem with a permanent Internet connection.  Without it -
only UUCP, or Internet connections on demand, both of course
not free - the smarthost concept had technical reasons.

> the concept of a 'smarthost' was merely to make the
> sysadmin's job easier, not for any innate technical reason...

Crash mail, modem, poll frequency, pathalias, world map, etc.,
forgotten, or did you never meet the persons paying the bills ?

                      Bye, Frank

To: Markus Stumpf <[email-masked]>
Cc: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt) 
From: [email-masked]
Date: Tue, 31 May 2005 01:16:14 -0400
Sender: [email-masked]

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

On Mon, 30 May 2005 22:40:18 +0200, Markus Stumpf said:

> IMHO it was never a fundamental principle of email that a MUA can
> connect to any MX and get a message delivered. In fact, before the
> Internet boom, MUAs like "mail" or "elm" couldn't even speak SMTP.

Actually, 'mail' and 'elm' never bothered to learn to speak SMTP themselves,
because there was always the assumption that the box that was running mail or
elm had a Sendmail running, and that you could just hand the whole mess off to
Sendmail and let *it* worry about it.

And that's been true since at least 1984, when I was hacking sendmail.cf
files with vi, and the arpanet/milnet had only some 3,000 or so hosts on it.
/bin/mail would just hand it to Sendmail.  I don't think Elm existed yet.

And there *was* general acceptance of the concept that the Sendmail could
connect to whatever MX destinations it wanted to - the concept of a 'smarthost'
was merely to make the sysadmin's job easier, not for any innate technical
reason...

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

--==_Exmh_1117516573_3664P--

Date: Mon, 30 May 2005 22:44:45 -0400
To: Markus Stumpf <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Cc: [email-masked]
Sender: [email-masked]

At 22:40 +0200 on 05/30/2005, Markus Stumpf wrote about Re: MTAMARK 
(was: SPF I-D for review: draft-schlitt-spf-cla:

>[...] if the connection originator cannot SMTP AUTH
>or SMTP after POP or whatever. As MSAs are not allowed to accept connections
>that are not authenticated
[due to being on Port587 which per the RFC requires SMTP AUTH]
>MTAMARK is irrelevant for them.

In my Opinion relying on SMTP AUTH is foolish so long as it is 
implemented (as it usually is) in an unsafe/insecure manner. So long 
as the ONLY SMTP AUTH methods that the MSA offers is Login and Plain 
you are NOT secure and your UserID/PW pair is not protected from 
anyone who is monitoring the connection (such as being the Hotel 
Ethernet or WiFi Provider, or is listening to the unencrypted WiFi 
Connections), has (as occurred a few months ago to my ISP [Panix]) 
hijacked the DNS to point at their own SMTP Servers, or is an ISP who 
does "Port25 Blocking" by not blocking the Port25 Connection Attempt 
but by Hijacking the connection and force routing it to a ISP 
Provided MSA Server. So long as the MUA attempts to use Login or 
Plain AUTH it is exposing the UserID/PW pair to anyone who is 
monitoring the connection. Only a use of AUTH CRAM-MD5 (or another 
one-time encryption handshake) or a Port465 SMTP-over-SSL Connection 
protects the UserID/PW pair during the handshake. Even the offer of 
CRAM-MD5 (along with Plain and Login) is insecure so long as the MSA 
does not support CRAM-MD5 and thus is forced to use the insecure 
handshakes.

Date: Mon, 30 May 2005 23:03:19 -0400
To: Markus Stumpf <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Cc: [email-masked]
Sender: [email-masked]

At 22:40 +0200 on 05/30/2005, Markus Stumpf wrote about Re: MTAMARK 
(was: SPF I-D for review: draft-schlitt-spf-cla:

>I have never seen a "legal" mailserver running on a dynamically changing,
>DHCP provided IP address before.

I have. My Connectivity provider Optimum Online (OOL) [AKA 
Cablevision] offers "Business Class OOL" (BOOL) to Bussinesses at a 
higher price than "Residential" OOL. The only difference other than 
the cost is that a BOOL User is allowed to run SMTP/POP/IMAP Servers. 
The actual IPNs are DHCP Supplied and (apparently) come from the same 
pool as the OOL IPNs. I am not sure how the rDns is handled (ie: If 
the mapping is to a Name in the Business's Domain or not and if it 
gets updated when the IPN gets updated). I think that the Business 
still needs dynamic DNS updating when the IPN changes but that does 
not help the x.x.x.in-addr.arpa issue.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Date: Mon, 30 May 2005 21:19:33 -0400
Cc: Markus Stumpf <[email-masked]>
Sender: [email-masked]

On Mon May 30 2005 16:40, Markus Stumpf wrote:
> 
> On Tue, May 24, 2005 at 05:40:49PM -0400, Bruce Lilly wrote:

> > 1. it speaks of MTAs and mail severs, however an MUA or MSA may also
> >    send mail, and there is at present no way for an SMTP receiver to
> >    determine whether the connected sending client is an MUA, an MSA,
> >    or an MTA.
> 
> This is the idea of MTAMARK.
> MUAs SHOULD NOT talk to other mailserver on port 25 but use 587 (submission)
> instead.

Exactly which MSA do you believe they should talk to?  The ISP which
receives mail for me also operates an SMTP server for sending mail, on
port 25 (nothing on ports 587 or 465).  At the moment I can't get to
it (port 25 blocking).  The ISP for the network I'm presently connected
to operates a server on port 25.  I know of a server which I can get to
which operates on port 587, but it mangles messages so badly that it's
unusable.

> The idea is to treat connections on port 25 (aka MTA <> MTA (pls read on))
> as unauthorized unless either
> - the sending IP has a MTA=1 flag
> - the connection is authenticated (SMTP AUTH, SMTP after POP, LAN
>   connection, ...)

I have an MTA on my laptop which will happily use SMTP AUTH with any
MSA or MTA that supports it.  I supply the certificates.  Do you
suppose that SMTP AUTH presents a difficulty for spammers?

> I always see a MSA as the letter box in real life.

Email doesn't work like postal services.  There is no central "post
office" concept in email.

> What IMHO we all have to recognize is that the Internet of today is not
> the Internet of 1995 or even 1990 or earlier.

OK so far...

> Times are changing and 
> - like with other growing schemes - some rules must be redefined for
> a better collaboration. If one of the changed rules is that MUAs can
> no longer connect to any MX they like and masquarade as a MTA I am all
> for it.

And I would be opposed.  I have seen too many problems with ISP-operated
MTAs -- knowledgeable users need a way to work around those problems by
sending directly to the recipient domain's MX hosts if necessary.

> > 3. like other IP based schemes, it doesn't play well with DHCP and
> >    NAT.
> 
> I have never seen a "legal" mailserver running on a dynamically changing,

Define "legal".  My laptop (mentioned above) is connected to a dynamic
IP address (AFAIK; it's behind two NAT boxes, so it thinks it has a fixed
RFC 1918 IP address).

> > 4. While some parts of IP address space might be managed in a way
> >    which is amenable to the approach, other parts have many widely
> >    separated class C ranges under one administrative entity, which
> >    would seem to mean managing each of those ranges separately.
> 
> I don't understand what you mean to say.
> 
> As an ISP we manage a few hundred /24 for our customers with regard to
> reverse DNS.

So you have to manage a few hundred zone files...

> > 7. Simply publishing information about which IP addresses might source
> >    messages may reveal information of potential use to an attacker
> >    (not mentioned in security considerations).
> 
> Connecting a host to the Internet is of potential use to an attacker.

Of course, but one expects security considerations sections to list
known security issues.

> Security through obscurity never worked. We see more than 50 full scans
> per day, so the scanners have probably more and better information
> about a host or a network than anyone else.
> Is there any specific attack you are thinking about?

If one says 192.0.2.1 is an MTA and 192.0.2.2 is not, then:
1. an attacker looking to exploit a known MTA vulnerability knows to
   try 192.0.2.1  and can ignore 192.0.2.2, without scanning
2. an attacker who wishes to exploit a vulnerability in some type of
   device that usually does not operate on hardware that has an MTA
   (e.g. a line printer using TCP port 515 lpd protocol) can ingore
   192.0.2.1 and concentrate efforts on 192.0.2.2 and other IP addresses
   which you have conveniently categorized for him

> What really drives me crazy is that the spam problem is omnipresent.
> Everyone from the big companies to the end user is frustrated and wants
> the problem to be solved.
> But it can only be solved with changes from the existing spam prone
> architecture to a more controlled system.

Not necessarily. Filtering does not necessarily involve architectural
changes, for example.

> But with *every* change everyone 
> from the big companies to the end user is whining that they don't want
> to have anything changed.

One could trivially solve the spam problem by making all email fail; no
email, no spam.  Some schemes come pretty close to that...

> I am running for 20 days now a reporter on one of our mailservers.
> It reports to a central database if the sending hosts doesn't pass a few
> *simple* tests:
> - IPs [...]
> The list of unique abusive IP addresses *grows* with a linear factor of
> about 350 entries per hour.

And this surprises you?  A host connected via DHCP may have a new IP
address every time it connects -- some ISPs assigning IP addresses via
DHCP have timeouts on the order of 1 hour.

That doesn't mean that every machine connected via every IP address that
has ever had a problem always has the same problem, forever.  A
Windows-infested virus box (or is it the other way around :-) may have
a particular IP address at one time, using it to spew spam, and a minute
later a legitimate user may be sending legitimate mail from the same IP
address. Or vice versa.

> If you think that no "legal" mailservers (as one might think) end up in
> this list you are all wrong. Most of them send/forward/relay "permdns" and
> virus messages.
> The question that remains is: why?

Maybe because you're assuming (consciously or not) that DHCP doesn't exist?

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Mon, 30 May 2005 22:40:18 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, May 24, 2005 at 05:40:49PM -0400, Bruce Lilly wrote:
> As I understand it from a quick skim, there are however some issues:

Thanks for your comments.

> 1. it speaks of MTAs and mail severs, however an MUA or MSA may also
>    send mail, and there is at present no way for an SMTP receiver to
>    determine whether the connected sending client is an MUA, an MSA,
>    or an MTA.

This is the idea of MTAMARK.
MUAs SHOULD NOT talk to other mailserver on port 25 but use 587 (submission)
instead. MTAMARK allows the administrator to mark IP addresses in the
Domain Name System as "This IP address is assigned to a MTA that is
intended to send messages across the Internet". If a receiver MTA (aka
MX) receives a connection this gives a hint and if no MTA=1 flag is set
it may reject the message if the connection originator cannot SMTP AUTH
or SMTP after POP or whatever. As MSAs are not allowed to accept connections
that are not authenticated MTAMARK is irrelevant for them.

> 2. it speaks of "unauthorized message transmission", but SMTP has
>    no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
>    used for sending (pushing) mail).

Ok. The problem here may be the semantic difference between "authorized" and
"authenticated". I must admit we mixed the two and we will review the draft
with regard to that.

The idea is to treat connections on port 25 (aka MTA <> MTA (pls read on))
as unauthorized unless either
- the sending IP has a MTA=1 flag
- the connection is authenticated (SMTP AUTH, SMTP after POP, LAN
  connection, ...)
In todays mail infrastructure most (nearly all) MTA work as combined
MX/MSA servers. If there is a clear separation there is no need for a MX
to talk to a MUA directly. Each MUA usually has a MSA to authorize with
and inject the message to the Internet mail system.
The goal has to be to make port 25 connections MTA<>MTA only (spamware,
viruses, worms and MUAs are no MTAs).

I always see a MSA as the letter box in real life. To get a message
delivered the person (MUA) has to put the letter into the letter box
(MSA). The postal system (MTA) transfers it to the destination where the
postman (MDA) puts it in the mailbox.
Some buildings allow access to the mailboxes of the inhabitants only to
authorized personal of the various postal companies. This solves the
problem of children hired to put advertising sheets in each and every
mailbox and of trespassers using the mailboxes to put in all kind of crap.

> 6. authentication is fine where there is a prior arrangement,
>    however one of the fundamental principles of email is that it
>    permits communications with no prior arrangement.

IMHO it was never a fundamental principle of email that a MUA can
connect to any MX and get a message delivered. In fact, before the
Internet boom, MUAs like "mail" or "elm" couldn't even speak SMTP.
The principle of "no prior arrangement" is still met for MTA<>MTA
connections but we need a way to distinguish them from
MUA/spamware/worm/virus connections.
This is one of the goals of MTAMARK.

What IMHO we all have to recognize is that the Internet of today is not
the Internet of 1995 or even 1990 or earlier. Times are changing and
- like with other growing schemes - some rules must be redefined for
a better collaboration. If one of the changed rules is that MUAs can
no longer connect to any MX they like and masquarade as a MTA I am all
for it.
And, IMHO, your "no prior arrangement" principle isn't a fundamental
principle of email it show only the shortfalls of the system that
ioriginate from a time when there was no need for it.

> 3. like other IP based schemes, it doesn't play well with DHCP and
>    NAT.

I have never seen a "legal" mailserver running on a dynamically changing,
DHCP provided IP address before. NATted networks should not be a problem
as the admin usually already configures which hosts are allowed to perfom
which actions, so adding MTA=1 to the NAT gateway is fine. If this can
be abused by internal clients the address will end up in a RBL despite
the MTA=1 flag. Problem solved.

> 4. While some parts of IP address space might be managed in a way
>    which is amenable to the approach, other parts have many widely
>    separated class C ranges under one administrative entity, which
>    would seem to mean managing each of those ranges separately.

I don't understand what you mean to say.

As an ISP we manage a few hundred /24 for our customers with regard to
reverse DNS. Customers do contact us to get rev DNS names so I don't see
(in fact we don't have) a problem in also adding MTAMARK records for
hosts they like to be sending MTAs.
Is this the problem you wanted to address above? If yes I don't see this
as a problem.

> 5. I'm not thrilled about the "unmarked" yes->no flag day concept.

Me neither. We're thinking about dropping this completely.

> 7. Simply publishing information about which IP addresses might source
>    messages may reveal information of potential use to an attacker
>    (not mentioned in security considerations).

Connecting a host to the Internet is of potential use to an attacker.
Security through obscurity never worked. We see more than 50 full scans
per day, so the scanners have probably more and better information
about a host or a network than anyone else.
Is there any specific attack you are thinking about?

What really drives me crazy is that the spam problem is omnipresent.
Everyone from the big companies to the end user is frustrated and wants
the problem to be solved.
But it can only be solved with changes from the existing spam prone
architecture to a more controlled system. But with *every* change everyone
from the big companies to the end user is whining that they don't want
to have anything changed.

So without changes they all get what they want: more and more spam.
... and one change alone will NOT solve the problem.

I am running for 20 days now a reporter on one of our mailservers.
It reports to a central database if the sending hosts doesn't pass a few
*simple* tests:
- IPs sending worms/viruses (virus)
- IPs using the IP/name of the receiving system in HELO/EHLO (badhelo)
- IPs using "localhost" HELO/EHLO (badhelo)
- IPs using "localhost.localdomain" HELO/EHLO (badhelo)
- IPs using "example.com" in HELO/EHLO when the RCPT TO is "[email-masked]"
  (helomatchrcpt)
- IPs sending a MAIL FROM: with a domain that has no A/MX record in DNS
  (permdns)
- IPs sending "XXXX" or "POST" as the first command in their SMTP
  dialogue (unimpl).

On an average day the mailserver makes around 4000-5000 incoming connections
per hour.
The list of unique abusive IP addresses *grows* with a linear factor of
about 350 entries per hour. A graphical representation (snapshot as of
now) is here:
    http://www.space.net/~maex/growth_month.png
(adding virus information has been started a few days later)

If you think that no "legal" mailservers (as one might think) end up in
this list you are all wrong. Most of them send/forward/relay "permdns" and
virus messages.
The question that remains is: why?

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

Date: Mon, 30 May 2005 12:36:49 -0700
To: John Leslie <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Chain of Trusted Forwarders
Cc: [email-masked]
Sender: [email-masked]

John,

I think the root of our misunderstanding is our different expectations for 
the future.  You seem to be assuming everyone will be using CSV.  While I 
would certainly prefer that outcome over what I see developing, I can't 
just assume it will be true.

Let's work through the example below, assuming you are bigforwarder.com, 
and I am the receiver.  Let's say it is 2007, and CSV is the only method 
blessed by the IETF.  Unfortunately, nobody is listening to 
them.  Microsoft has just won its court battle with SPF over re-definition 
of SPF1 records, and *SenderID*(TM)/spf now has 40% market share.  CSV is 
at 20% and the other 40% are either not participating, using some other 
method, or have old useless SPF1 records that they never bothered to update.

At 09:29 PM 5/29/2005 -0400, John Leslie wrote:
>David MacQuigg <[email-masked]> wrote:
> > At 08:59 PM 5/28/2005 -0400, John Leslie wrote:
> >> David MacQuigg <[email-masked]> wrote:
> >>>
> >>> I would establish three levels of compliance for servers wanting to be
> >>> listed as Public Mail Servers:
> >>>
> >>> 1) Servers that will declare their ID, and provide a DNS record to
> >>> authorize the use of that ID.
> >>
> >> This is, in fact, what CSV does.
> >
> > Tell me what is the declared identity for the following:
> >
> >    EHLO  building7.bigforwarder.com
> >    MAIL FROM:<[email-masked]>
>
>    The EHLO _is_ a declaration of the identity of the sending MTA. Thus
>CSV treats "building7.bigforwarder.com" as the declared identity. (We
>then try to match it to a declaration of authorization; failing that, it's
>not a _useful_ identity.)

I have no prior relationship with bigforwarder.com, so I don't know that 
you are using CSV.  My setup is to try SenderID first, since that method is 
the most prevalent.  If I find a PRA record, I run the SenderID check and 
don't bother with any others.  I would prefer CSV, but I must do whatever 
is quickest to keep my costs down.

If you are bigforwarder.com, how are you going to signal me that CSV is 
available?  Will you also offer SenderID?  Many of the 40% using it do not 
use any other method.  You don't know if I am one of those.

As a receiver, I cannot assume a sender is using CSV.  Without some prior 
arrangement, there is no way to tell what identity, if any, the sender is 
prepared to authenticate.  Even if we could assume the EHLO identity is 
always compliant with RFC-2821, it still is not an identity acceptable to 
the other methods.  Without the kind of compromise I am proposing, we are 
in for a long and wasteful battle.

> > Yes, I know that EHLO *could* be a declaration, but that is not current
> > practice.
>
>    Au contraire! It always _is_ a declaration of identity: it's just not
>always a useful identity in current practice. CSV declares it to be a
>useful identity if it matches a declaration of authorization.

I would say CSV "uses" the EHLO identity, and it "hopes" it will be a 
useful identity, but it certainly doesn't "declare" anything.  Methods 
don't declare.  They are not "actors", to use Dave Crocker's email 
architecture terminology.  Sending MTA's could "declare", but they 
typically just "state" or "show" or "pass on", maybe at best "reveal" 
various identities.

I hope I'm not being unreasonable in my insistence that we use the verb 
"declare" properly.  There is a vital distinction involving intent and 
deniability.  The sending MTA's declaration must be an explicit, formal, 
unambiguous assertion of the exact identity authorizing a transfer.  A 
false declaration must not be excused by the fact that an identity has 
never been checked before, has frequently been misused in the past, or may 
even have a definition that many people feel is contrary to its use as a 
sender's identity.

> > If we are worried about 1 in 1000 forwarders reordering headers,
> > we should be much more worried about the widespread misuse of the EHLO
> > identity.
>
>    CSV _does_ worry about that.
>
> > If we could extend the EHLO syntax, we might almost have it.  Maybe
> > something like
> >
> >    EHLO building7.bigforwarder.com.2
> >
> > meaning the last two pieces of the EHLO name are the declared ID.
>
>    No: that would be declaring the identity "building7.bigforwarder.com.2"
>(which could never pass CSV).

I'm talking about what *could* be done to salvage the EHLO identity without 
breaking existing MTAs.  I'm sure you could think of many alternatives.

>    Recall, the EHLO is the identity of the MTA, not the identity of its
>management.

This is a limitation that will make its use as a Sender's Identity 
unacceptable to other methods.

> >>> 3) Servers that will perform an authentication check on the declared ID,
> >>> using any widely-accepted method, and prepend the result of that check.
> >>
> >> This is the "chain of trust" idea. It is easy to ridicule any chain
> >> of trust, which is never stronger than its weakest link; but if we follow
> >> a prepending model, we have some genuine hope of reaching that strength.
> >> To paraphrase Thornton Wilder's Matchmaker, "The difference between a
> >> little trust and no trust at all can shake the world."
> >
> > As a receiver, the only part of the chain I care about is the last few
> > links.
>
>    Agreed. The shorter the chain, the more likely that the level of
>trust will be useful.
>
> >> And, in fact, level 3 is merely a nice-thing, not an essential.
> >> Reputation services could perfectly well rate forwarders on how well
> >> they do at rejecting bad-reputation sending MTAs.
> >
> > Rejection by a forwarder, based on reputation, should be done only by
> > prior arrangement with the final receiver.
>
>    Au contraire! Rejection (at SMTP time) is a matter of forwarder
>policy. So long as that policy is well-documented, the forwardee has
>no legitimate complaint.

If you take on this responsibility as a forwarder, you will have to 
implement different policies for different receivers, and will need some 
mechanism to rapidly change policies in response to customer requests.  At 
one time, I might be waiting for some mail from my sister in Baghdad, and 
want to send all C-rated mail to a special mailbox.  At another time, I 
might decide to have you reject it all.

>    In practice, forwarders that _don't_ reject enough suffer excessive
>bounce messages related to forwarding, which are a pain to evaluate.

No evaluation is necessary, other than making sure they are legitimate 
bounces, not backscatter.  As a Trusted Forwarder, you will be getting Spam 
Bounces.  Your responsibility is to immediately bounce them upstream.  You 
may also want to aggregate some statistics from all of your receivers, and 
file your own spam reports on any that look like widespread abuse.  In the 
case of outright mail bombing, you may want to take the extreme action of 
blocking selected IPs.  This should only be done if the owner of the IP is 
unresponsive.

> > In general, a forwarder won't know what the receiver's policy is.
>
>    Absolutely true! It would be nice to simply collect enough information
>and let the final receiver make the decision. Alas, it doesn't look
>practical...

I think it *will* be with an effective authentication standard in place, 
but I'll admit, my crystal ball is a little cloudy that far into the future.

> > Authentication failure, on the other hand, should cause an immediate
> > reject.
>
>    Again, not practical. Hard-failure of authentication is too rare;
>and there's no incentive for spammers to give it to you.

Let's not get too hung up on current operational problems.  Again, this is 
crystal-ball stuff, but I see the "softfails" and other interim 
complexities eventually falling away, and almost everything, including spam 
will be PASS.  Authentication failure will be like a broken communications 
link, something to be fixed quickly without bothering the user.

> > This depends on the authentication method delivering an unambiguous
> > PASS or FAIL, something we don't have now, even with CSV.
>
>    There are entirely too many clueless folks out there running MTAs
>for us to ever hope for 100% of email to have unambiguous PASS/FAIL.

The clueless will hire someone to help them get set up, just like they do 
now for setting up their routers.  They cannot operate a Public Mail Server 
until they get their authentication setup working.  More crystal ball, I know.

> > With an ID declaration, and a DNS record that calls for a
> > CSV check, then we have it nailed.
>
>    I can't agree, alas, though in fact CSV _does_ have all that.

Only if we assume the whole world will be using CSV.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Mon, 30 May 2005 12:26:38 -0700
To: "Robert A. Rosenberg" <[email-masked]>, [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Chain of Trusted Forwarders
Sender: [email-masked]

At 11:12 PM 5/29/2005 -0400, Robert A. Rosenberg wrote:
>At 12:07 -0400 on 05/29/2005, [email-masked] wrote:
>
>>Congrats.  You've re-invented the PGP Web Of Trust, although usually people
>>don't bother doing the extra step of running credit and police records.  The
>>fact is that the PGP Public Keyserver system has only several million e-mail
>>addresses in it, and only some 100K (last I checked) in the "well connected
>>set" (meaning keys that *have* done this sort of thing enough to be
>>identifiable to anybody else in the set).
>
>That number is dropping fast due to the new PGP Key server code that drops 
>any signature from a uploaded key if it is not already on the server. IOW: 
>If A has had his/her key signed by B, C, and D, these signatures will get 
>stripped off when stored on the server unless B, C, and D has uploaded 
>their keys to the Server. To get an accurate key onto the server, A must 
>reload his/her key again after B, C, and D (who must also reupload so the 
>copies signed by the others is the "official" copy that is stored.

The difference between the "chain of trust" you are talking about and email 
authentication is DNS.  When a sender puts its public key, or any other 
authentication information in its own section of the DNS hierarchy, we 
don't need further authentication of that information.  We assume the folks 
who delegate DNS zones, starting with the registrars of the 
top-level-domains, are competent and honest.  ( Yes, I know about Melbourne 
IT's mishandling of panix.com.  The exception proves the rule.  Hopefully, 
Melbourne and a bunch of other registrars have fixed their procedures.)

The security requirements needed to thwart spammers are luckily much less 
than needed to guard nuclear weapons data, or we would not be able to rely 
on DNS.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Sun, 29 May 2005 23:12:17 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: Chain of Trusted Forwarders
Sender: [email-masked]

At 12:07 -0400 on 05/29/2005, [email-masked] wrote about Re: 
Chain of Trusted Forwarders:

>Congrats.  You've re-invented the PGP Web Of Trust, although usually people
>don't bother doing the extra step of running credit and police records.  The
>fact is that the PGP Public Keyserver system has only several million e-mail
>addresses in it, and only some 100K (last I checked) in the "well connected
>set" (meaning keys that *have* done this sort of thing enough to be
>identifiable to anybody else in the set).

That number is dropping fast due to the new PGP Key server code that 
drops any signature from a uploaded key if it is not already on the 
server. IOW: If A has had his/her key signed by B, C, and D, these 
signatures will get stripped off when stored on the server unless B, 
C, and D has uploaded their keys to the Server. To get an accurate 
key onto the server, A must reload his/her key again after B, C, and 
D (who must also reupload so the copies signed by the others is the 
"official" copy that is stored.

Date: Sun, 29 May 2005 21:29:31 -0400
From: John Leslie <[email-masked]>
To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Chain of Trusted Forwarders
Sender: [email-masked]

David MacQuigg <[email-masked]> wrote:
> At 08:59 PM 5/28/2005 -0400, John Leslie wrote:
>> David MacQuigg <[email-masked]> wrote:
>>>
>>> I would establish three levels of compliance for servers wanting to be
>>> listed as Public Mail Servers:
>>>
>>> 1) Servers that will declare their ID, and provide a DNS record to
>>> authorize the use of that ID.
>>
>> This is, in fact, what CSV does.
> 
> Tell me what is the declared identity for the following:
> 
>    EHLO  building7.bigforwarder.com
>    MAIL FROM:<<mailto:[email-masked]>[email-masked]>

   The EHLO _is_ a declaration of the identity of the sending MTA. Thus
CSV treats "building7.bigforwarder.com" as the declared identity. (We
then try to match it to a declaration of authorization; failing that, it's
not a _useful_ identity.)

> Yes, I know that EHLO *could* be a declaration, but that is not current 
> practice. 

   Au contraire! It always _is_ a declaration of identity: it's just not
always a useful identity in current practice. CSV declares it to be a
useful identity if it matches a declaration of authorization.

> If we are worried about 1 in 1000 forwarders reordering headers, 
> we should be much more worried about the widespread misuse of the EHLO 
> identity.

   CSV _does_ worry about that.

> If we could extend the EHLO syntax, we might almost have it.  Maybe 
> something like
> 
>    EHLO building7.bigforwarder.com.2
> 
> meaning the last two pieces of the EHLO name are the declared ID. 

   No: that would be declaring the identity "building7.bigforwarder.com.2"
(which could never pass CSV).

   Recall, the EHLO is the identity of the MTA, not the identity of its
management.

>>> 3) Servers that will perform an authentication check on the declared ID,
>>> using any widely-accepted method, and prepend the result of that check.
>>
>> This is the "chain of trust" idea. It is easy to ridicule any chain
>> of trust, which is never stronger than its weakest link; but if we follow
>> a prepending model, we have some genuine hope of reaching that strength.
>> To paraphrase Thornton Wilder's Matchmaker, "The difference between a
>> little trust and no trust at all can shake the world."
> 
> As a receiver, the only part of the chain I care about is the last few 
> links. 

   Agreed. The shorter the chain, the more likely that the level of
trust will be useful. 

>> And, in fact, level 3 is merely a nice-thing, not an essential.
>> Reputation services could perfectly well rate forwarders on how well
>> they do at rejecting bad-reputation sending MTAs.
> 
> Rejection by a forwarder, based on reputation, should be done only by
> prior arrangement with the final receiver. 

   Au contraire! Rejection (at SMTP time) is a matter of forwarder
policy. So long as that policy is well-documented, the forwardee has
no legitimate complaint.

   In practice, forwarders that _don't_ reject enough suffer excessive
bounce messages related to forwarding, which are a pain to evaluate.

> In general, a forwarder won't know what the receiver's policy is. 

   Absolutely true! It would be nice to simply collect enough information
and let the final receiver make the decision. Alas, it doesn't look
practical...

> Authentication failure, on the other hand, should cause an immediate
> reject. 

   Again, not practical. Hard-failure of authentication is too rare;
and there's no incentive for spammers to give it to you.

> This depends on the authentication method delivering an unambiguous
> PASS or FAIL, something we don't have now, even with CSV. 

   There are entirely too many clueless folks out there running MTAs
for us to ever hope for 100% of email to have unambiguous PASS/FAIL.

> With an ID declaration, and a DNS record that calls for a 
> CSV check, then we have it nailed.

   I can't agree, alas, though in fact CSV _does_ have all that.

--
John Leslie <[email-masked]>

To: David MacQuigg <[email-masked]>
Cc: David MacQuigg <[email-masked]>, [email-masked]
Subject: Re: Chain of Trusted Forwarders 
From: [email-masked]
Date: Sun, 29 May 2005 16:51:52 -0400
Sender: [email-masked]

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

On Sun, 29 May 2005 12:18:27 PDT, David MacQuigg said:
> Have you ever set up a corporation?  The cost in time an money is easily
> more than the profit from of one hour of spamming.  Remember, you get only

That's only if you're setting up a *real* corporation.  Remember - *you* said
that it only has to look good enough to provide the corporate registration
you'd consider sufficient.  You can cut corners a lot if you're perpetrating
a scam....

> a B-rating if your new domain is "trusted, but not proven", and many
> receivers will be filtering the B-rated mail also.  Also, a spammer will
> have to use a different personal identity each time, so they get the state
> authorities after them also.

The same state authorities who are *already* in full pursuit of these guys
for all the *other* illegal things they're doing?  The ones who are so vigilant
that no spammer dares pay for a domain with a stolen credit card?  The ones
that are prosecuting them in droves for fraud and the like?  You *seriously*
expect those overburdened state attorneys general to add the fraudulent corporate
registrations to all the *OTHER* legal action they have pending against
the spammers???

"Hello, Airport Control? This is Pig N23FC7, fully fueled and requesting
clearance for takeoff...."

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

--==_Exmh_1117399911_6734P--

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Chain of Trusted Forwarders 
From: [email-masked]
Date: Sun, 29 May 2005 12:11:18 -0400
Sender: [email-masked]

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

On Sun, 29 May 2005 03:14:23 PDT, David MacQuigg said:

> The real question is, how easy will it be for spammers to move their 
> plentiful supply of C-rated (unknown) IDs up to B (trusted, but not yet 
> proven).  If I were a reputation service, considering an applicant for a B 
> rating, I would take a corporate registration as sufficient.

Almost overlooked this one - you don't think that spammers are *already*
very good at creating a new shell corporation (complete with registrations
and even credit cards) already?  How do you think they apply for connectivity
when they get bounced off one provider?  Of course, they apply at the next
under some other corporate identity.....

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

--==_Exmh_1117383078_6734P--

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Chain of Trusted Forwarders 
From: [email-masked]
Date: Sun, 29 May 2005 12:07:35 -0400
Sender: [email-masked]

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

On Sun, 29 May 2005 03:14:23 PDT, David MacQuigg said:

> Let's assume authentication works perfectly, so we are looking just at the 
> cost/benefit to spammers of acquiring/burning reputable IDs.  Let's also

Broken right there.  Authentication never works *perfectly*.  You're looking at
the cost/benefit of acquiring a reputable-*appearing* ID.

Wander over to the police station in any town that has both a large college
and bars, and ask if there's any problems at all with fake IDs.

> ignore the occasional hijacking of a reputable ID.  As you say, this must 
> be a production process involving large numbers of names.  Let's look at 
> the benefit first, as that seems easiest.  The system I imagine would give 
> a spammer about an hour of operation with a B-rated ID before the downgrade 
> notification propagates to all that care about a quick response.

Often, an hour is more than sufficient...

> easily checked, and will cover almost all wannabe operators of Public Mail 
> Servers.  For individuals, I would insist on a face-to-face with someone I 
> trust, maybe one of my subscriber ISPs in the same town.  My representative 
> could copy the individuals driver's license and credit cards, and snap his 
> picture.  I would also run a check of credit and police records.

Congrats.  You've re-invented the PGP Web Of Trust, although usually people
don't bother doing the extra step of running credit and police records.  The
fact is that the PGP Public Keyserver system has only several million e-mail
addresses in it, and only some 100K (last I checked) in the "well connected
set" (meaning keys that *have* done this sort of thing enough to be
identifiable to anybody else in the set).

You might want to think about what lesson that teaches us about the *reality*
of the workability of this solution before hand-waving and saying "This is easy".

> The fee for this service might include a bond, to be returned after the 
> first six months of operation.  I really don't care if individual 
> applicants find this burdensome.

The last I heard, Alan Ralsky was having no trouble making the mortgage on
a $1.5M home from his spamming operations.  Explain to me what level you will
set this bond at that will deter Mr Ralsky, but will *not* prove a major hardship
to the vast majority of the 5,000 or so ISPs in the US - most of whom are
small businesses that have perhaps 10% of Ralsky's profit margins.

More to the point - are *YOU* prepared to put up a bond that big for *your*
business?  You ready to put a quarter mill or so of *your own funds* up (no,
you can't borrow for this - your *own* cash, please..)

(Yes, you're going to have to make it that big - if a spammer can guarantee
that his mail Really Looks OK, they'll probably cough up the bucks.  And no
amount of hand-waving about "but they won't be able to do it multiple times"
will convince me - wander over to the ROKSO list and ask yourself why some
of the biggest names are on their 5th or 6th provider - if they're getting
connectivity via pink contracts, they *WILL* be able to get cut-rate bonds
posted via the same means....)

>                                   My customers are email receivers, and I 
> don't think I will lose much business if a few individuals decide that 
> using a reputable ISP to forward their mail is easier than getting a 
> "license" to operate their own Public Mail Server.

Let me guess - you're *also* OK with ClearChannel over half the radio stations,
and a total of 7 companies controlling 95% of record/CD sales?

Remember that *you* lose 100% of your business when you get borged by one
of the 'Big 5' ISPs in the upcoming consolidation that you seem to want to cause....

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

--==_Exmh_1117382854_6734P--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: "Header Reordering", yet again
Date:  Sun, 29 May 2005 16:51:09 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 42
Sender: [email-masked]

[email-masked] wrote:

> it is much too late to change the syntax of Received: fields.
> And even if it were applied to Received-SPF fields, it does
> nothing to keep the Received-SPF ordered relative to
> Received: fields.

Let's assume the header fields in fact are reordered, among
them some Received-SPF.

Now you might be able to sort the timestamp lines by their
timestamps, or more likely by "I know what happens behind
my MX".  Or you just use `nslookup -q=mx`.

Then you can match these Received: ... by FQDN ... and the
receiver=FQDN in Received-SPF.  Then there are two cases:

1   - you get _one_ match for the FQDN of your MX
1.1 - but this MX doesn't check SPF, so this is bogus
1.2 - and this MX used to check SPF, so this is valid
2   - you get more than one match, this must be wrong

Actually "two" is possible for separate HELO and MAIL FROM
results, but let's ignore these SPF details for the moment.

Of course there's an issue for an MX changing its strategy,
e.g. depeding on the route and white lists.  The value of
this header field depends very much on local considerations.

SpamCop invented a "mailhost configuration system" last year,
because its general solution was not more good enough for
_all_ odd cases (it's still good enough for _most_ cases).

Now what's the conclusion of what you said so far ?  Kick
this header field ?  Add some "security considerations" ?

Just keep it as it is, because spammers trying to abuse it
will probably shoot into their own foot ?  Maybe move it
to an "informative appendix" with a corresponding caveat ?

                             Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: "Header Reordering", yet again
Date:  Sun, 29 May 2005 16:10:50 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 26
Sender: [email-masked]

[email-masked] wrote:

> Of course it is impossible to prove a negative.

In that case (Received-SPF) it's also unnecessary, unlike
SID's Resent-* it's not very critical.  Of course spammers
try to forge timestamp lines.

Of course they will try the same with a Received-SPF.  But
what will they get for it ?

If the receiver is very sure that he never inserted this
header field with its own receiver=FQDN parameter, he has
a good spam indicator.

Otherwise he SHOULD add his result above old results.  If
that works, and it's a setup where nothing shuffles header
fields between MX and final delivery, it's fine.

Otherwise don't believe it (and don't submit it to SpamCop,
it would fail in Spamcop's chain test).

A note about this in the "Security Considerations" maybe ?

                          Bye, Frank

Date: Sun, 29 May 2005 03:14:23 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Chain of Trusted Forwarders 
Cc: [email-masked]
Sender: [email-masked]

At 12:46 AM 5/29/2005 -0400, [email-masked] wrote:
>On Sat, 28 May 2005 16:45:40 PDT, David MacQuigg said:
>
> > Spammer -->  Forwarder1 --> Forwarder2 -->  Receiver
> >
> > A Trusted Forwarder will authenticate the ID presented by the 
> Spammer.  The
> > Receiver will look at that ID, and rate it just as if the Spammer had
> > connected directly to the Receiver.  If one of the Trusted Forwarders
> > messes up an authentication, then that forwarder loses reputation.
>
>Exactly.  So every time Forwarder*2* accepts a bogus one, *it* loses...

Forwarders are not responsible for content.  The only way Forwarder2 loses, 
is if it fails to authenticate Forwarder1.

> > The game could get a little more complicated if Forwarder1 is the spammer's
>
>The whole point is that Forwarder1 can be *assumed* to be the spammer's...
>
> > friend, but not much.  About the fifth time a rating service has to deal
> > with a he-said-she-said situation involving Forwarder1, it will be pretty
> > clear who is faking authentication headers.
>
>And after a long run of Forwarder1A..Forwarder1Q.., Forwarder2 is starting to
>look pretty shaky in the reputation market as well.  Remember that we're 
>talking
>here about a class of opponents that have *literally* hundreds of thousands of
>drones to enlist, and throwing tens of millions of bogus authentications.
>"About the 5th time" gets you through the first 35 seconds of a concerted 
>attack
>against the reputation mechanism, if *that* long.
>
>And don't bother suggesting "slow-start" mechanisms for setting up 
>reputations -
>the spammers are *already* sometimes lining up domains and zombies well in 
>advance
>of the run they are to be used for.  There's no reason to believe they *won't*
>engage in a ramp-up of bouncing totally pointless mail back and forth just to
>drive up their reputation score before they make their spam run...

Now we are getting to some good stuff, and I will admit I haven't thought 
through all the details.

Let's assume authentication works perfectly, so we are looking just at the 
cost/benefit to spammers of acquiring/burning reputable IDs.  Let's also 
ignore the occasional hijacking of a reputable ID.  As you say, this must 
be a production process involving large numbers of names.  Let's look at 
the benefit first, as that seems easiest.  The system I imagine would give 
a spammer about an hour of operation with a B-rated ID before the downgrade 
notification propagates to all that care about a quick response.

The real question is, how easy will it be for spammers to move their 
plentiful supply of C-rated (unknown) IDs up to B (trusted, but not yet 
proven).  If I were a reputation service, considering an applicant for a B 
rating, I would take a corporate registration as sufficient.  This is 
easily checked, and will cover almost all wannabe operators of Public Mail 
Servers.  For individuals, I would insist on a face-to-face with someone I 
trust, maybe one of my subscriber ISPs in the same town.  My representative 
could copy the individuals driver's license and credit cards, and snap his 
picture.  I would also run a check of credit and police records.

The fee for this service might include a bond, to be returned after the 
first six months of operation.  I really don't care if individual 
applicants find this burdensome.  My customers are email receivers, and I 
don't think I will lose much business if a few individuals decide that 
using a reputable ISP to forward their mail is easier than getting a 
"license" to operate their own Public Mail Server.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Sun, 29 May 2005 02:29:40 -0700
To: John Leslie <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Chain of Trusted Forwarders
Cc: [email-masked]
Sender: [email-masked]

At 08:59 PM 5/28/2005 -0400, John Leslie wrote:
>David MacQuigg <[email-masked]> wrote:
> >
> > I would establish three levels of compliance for servers wanting to be
> > listed as Public Mail Servers:
> >
> > 1) Servers that will declare their ID, and provide a DNS record to
> > authorize the use of that ID.
>
>    This is, in fact, what CSV does.

Tell me what is the declared identity for the following:

    EHLO  building7.bigforwarder.com
    MAIL FROM:<<mailto:[email-masked]>[email-masked]>

Each of the methods, including CSV, *uses* an identity.  None of them 
*declare* an identity.  A declaration is an affirmative statement, made by 
the sending MTA.  "This is <ID> sending to you from <IP>".  An MTA 
declaring a fake ID should be the legal equivalent of a radio broadcaster 
using fake call letters.

Imagine you are a border guard not allowed to ask for an ID.  You must go 
through each person's bag, checking whatever IDs you might 
find.  Furthermore, it is common practice for travelers to carry lots of 
IDs, most of which are not theirs, and none of which *must* be theirs.

It seems strange to me how hard it is for techies to grasp this 
concept.  Maybe we should add a course in law, along with literature, 
history, etc.

Yes, I know that EHLO *could* be a declaration, but that is not current 
practice.  If we are worried about 1 in 1000 forwarders reordering headers, 
we should be much more worried about the widespread misuse of the EHLO 
identity.

If we could extend the EHLO syntax, we might almost have it.  Maybe 
something like

    EHLO building7.bigforwarder.com.2

meaning the last two pieces of the EHLO name are the declared ID.  This 
might run into some opposition from SPF and SenderID, but at least it gives 
us an unambiguous declaration, until someone comes up with an excuse to 
append a digit for some reason other than declaring an ID.

> > 2) Servers that will capture the IP address and any ID declared by the
> > previous sender, and prepend that information in a standard authentication
> > header.
>
>    This, while interesting, is not useful.

It would allow the final receiver to authenticate the ID, assuming of 
course, that the forwarder is lazy, but still trusted.

> > 3) Servers that will perform an authentication check on the declared ID,
> > using any widely-accepted method, and prepend the result of that check.
>
>    This is the "chain of trust" idea. It is easy to ridicule any chain
>of trust, which is never stronger than its weakest link; but if we follow
>a prepending model, we have some genuine hope of reaching that strength.
>To paraphrase Thornton Wilder's Matchmaker, "The difference between a
>little trust and no trust at all can shake the world."

As a receiver, the only part of the chain I care about is the last few 
links.  That will include my forwarder, and perhaps one designated by the 
sender, if it has a good rating.  We rate the ID at that point, and I don't 
care about any prior links.  I expect lots of spam will arrive with A-rated 
names, then an unknown forwarder, then my forwarder.  That unknown 
forwarder will be getting many spam bounces.

> > Servers which only originate, and do not forward mail from other domains,
> > need only reach Level 1.
>
>    Exactly.
>
>    And, in fact, level 3 is merely a nice-thing, not an essential.
>Reputation services could perfectly well rate forwarders on how well
>they do at rejecting bad-reputation sending MTAs.

Rejection by a forwarder, based on reputation, should be done only by prior 
arrangement with the final receiver.  In general, a forwarder won't know 
what the receiver's policy is.  Authentication failure, on the other hand, 
should cause an immediate reject.  This depends on the authentication 
method delivering an unambiguous PASS or FAIL, something we don't have now, 
even with CSV.  With an ID declaration, and a DNS record that calls for a 
CSV check, then we have it nailed.

Exception:  Depending on what the future is like, we may want to have some 
widely accepted policy of forwarders rejecting mail from D-rated 
IDs.  These would be known spamming domains.  My crystal ball says there 
won't be many of these, and spammers will be using mostly C-rated (unknown) 
IDs, and an occasional hijacked A or B-rated name.  I look forward to 
getting maybe one piece of spam per week.  I will drop what I'm doing, read 
it carefully to make sure it isn't some friend spoofing me about p3nis pilz 
from Nigeria, and try to be the first to report a leak in the system.

>    What this _does_ buy us is the ability to pass on useful reputation
>information, to be evaluated later in the forwarding chain.

Again, let's leave reputation assessment to the final receiver.  What we 
need is a format for trusted forwarders to pass on *authentication* results.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Chain of Trusted Forwarders 
From: [email-masked]
Date: Sun, 29 May 2005 00:46:27 -0400
Sender: [email-masked]

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

On Sat, 28 May 2005 16:45:40 PDT, David MacQuigg said:

> Spammer -->  Forwarder1 --> Forwarder2 -->  Receiver
> 
> A Trusted Forwarder will authenticate the ID presented by the Spammer.  The 
> Receiver will look at that ID, and rate it just as if the Spammer had 
> connected directly to the Receiver.  If one of the Trusted Forwarders 
> messes up an authentication, then that forwarder loses reputation.

Exactly.  So every time Forwarder*2* accepts a bogus one, *it* loses...

> The game could get a little more complicated if Forwarder1 is the spammer's

The whole point is that Forwarder1 can be *assumed* to be the spammer's...

> friend, but not much.  About the fifth time a rating service has to deal 
> with a he-said-she-said situation involving Forwarder1, it will be pretty 
> clear who is faking authentication headers.

And after a long run of Forwarder1A..Forwarder1Q.., Forwarder2 is starting to
look pretty shaky in the reputation market as well.  Remember that we're talking
here about a class of opponents that have *literally* hundreds of thousands of
drones to enlist, and throwing tens of millions of bogus authentications.
"About the 5th time" gets you through the first 35 seconds of a concerted attack
against the reputation mechanism, if *that* long.

And don't bother suggesting "slow-start" mechanisms for setting up reputations -
the spammers are *already* sometimes lining up domains and zombies well in advance
of the run they are to be used for.  There's no reason to believe they *won't*
engage in a ramp-up of bouncing totally pointless mail back and forth just to
drive up their reputation score before they make their spam run...

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

--==_Exmh_1117341985_6734P--

From: Dave Crocker <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: Tony Finch <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sun, 29 May 2005 04:12:19 +0200
Delivery-Date: Sun, 29 May 2005 04:12:19 -0000
Subject: Re: "CSV" [not comma-separated values]
Sender: [email-masked]

>  ...and as CSV doesn't
>  take that characteristic into account, there is a problem with CSV.>  Nice 
theory.  In practice, defining "an organization" and determining
....
>  organizational boundaries are necessary and non-trivial.

Folks,

This thread has long since gone the way of all impasses.  The impasse divides 
between some very different views of what a protocol is supposed to do and what 
it is not, as well as what constitutes theory and what does not.

It is hard to imagine this thread having any productive potential.  Hence 
further postings on it are likely only to be amusement, and we probably have 
enough sources for that, elsewhere.

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

Date: Sat, 28 May 2005 20:59:34 -0400
From: John Leslie <[email-masked]>
To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

David MacQuigg <[email-masked]> wrote:
> 
> I would establish three levels of compliance for servers wanting to be 
> listed as Public Mail Servers:
> 
> 1) Servers that will declare their ID, and provide a DNS record to 
> authorize the use of that ID.

   This is, in fact, what CSV does.

> 2) Servers that will capture the IP address and any ID declared by the 
> previous sender, and prepend that information in a standard authentication 
> header.

   This, while interesting, is not useful.

> 3) Servers that will perform an authentication check on the declared ID, 
> using any widely-accepted method, and prepend the result of that check.

   This is the "chain of trust" idea. It is easy to ridicule any chain
of trust, which is never stronger than its weakest link; but if we follow
a prepending model, we have some genuine hope of reaching that strength.
To paraphrase Thornton Wilder's Matchmaker, "The difference between a
little trust and no trust at all can shake the world."

> Servers which only originate, and do not forward mail from other domains, 
> need only reach Level 1.

   Exactly.

   And, in fact, level 3 is merely a nice-thing, not an essential.
Reputation services could perfectly well rate forwarders on how well
they do at rejecting bad-reputation sending MTAs.

   What this _does_ buy us is the ability to pass on useful reputation
information, to be evaluated later in the forwarding chain.

--
John Leslie <[email-masked]>

Date: Sat, 28 May 2005 16:45:40 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Chain of Trusted Forwarders
Cc: [email-masked]
Sender: [email-masked]

At 05:48 PM 5/28/2005 -0400, [email-masked] wrote:

>On Sat, 28 May 2005 13:05:20 PDT, David MacQuigg said:
>
> > I would establish three levels of compliance for servers wanting to be
> > listed as Public Mail Servers:
> >
> > 1) Servers that will declare their ID, and provide a DNS record to
> > authorize the use of that ID.
> >
> > 2) Servers that will capture the IP address and any ID declared by the
> > previous sender, and prepend that information in a standard authentication
> > header.
> >
> > 3) Servers that will perform an authentication check on the declared ID,
> > using any widely-accepted method, and prepend the result of that check.
>
>4) Servers that will prepend text that appears that they have performed one
>or more of the previous tests, with a claimed result.

You forgot the authentication part.  Let's be very specific with this 
example and avoid a long digression.

Spammer -->  Forwarder1 --> Forwarder2 -->  Receiver

A Trusted Forwarder will authenticate the ID presented by the Spammer.  The 
Receiver will look at that ID, and rate it just as if the Spammer had 
connected directly to the Receiver.  If one of the Trusted Forwarders 
messes up an authentication, then that forwarder loses reputation.

The game could get a little more complicated if Forwarder1 is the spammer's 
friend, but not much.  About the fifth time a rating service has to deal 
with a he-said-she-said situation involving Forwarder1, it will be pretty 
clear who is faking authentication headers.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: "Header Reordering", yet again 
From: [email-masked]
Date: Sat, 28 May 2005 17:48:50 -0400
Sender: [email-masked]

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

On Sat, 28 May 2005 13:05:20 PDT, David MacQuigg said:

> I would establish three levels of compliance for servers wanting to be 
> listed as Public Mail Servers:
> 
> 1) Servers that will declare their ID, and provide a DNS record to 
> authorize the use of that ID.
> 
> 2) Servers that will capture the IP address and any ID declared by the 
> previous sender, and prepend that information in a standard authentication 
> header.
> 
> 3) Servers that will perform an authentication check on the declared ID, 
> using any widely-accepted method, and prepend the result of that check.

4) Servers that will prepend text that appears that they have performed one
or more of the previous tests, with a claimed result.

Moral: Never trust a check not performed by yourself unless you are able to
validate the results yourself.  There's two interesting cases here:

A) Spammers/miscreants who append a bogus "Check XYZ Passed" to get it through
your filters.

B) Spammers/miscreants who intentionally append a bogus 'Check XYZ Failed" while
claiming some origin point, for the intention of poisoning any collaborative
reputation schemes and making people not trust them....

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

--==_Exmh_1117316930_6734P--

From: [email-masked]
Cc: [email-masked]
Date: Sat, 28 May 2005 13:30:07 -0700 (PDT)
Subject: Re: "Header Reordering", yet again
To: David MacQuigg <[email-masked]>
Sender: [email-masked]

> OK, you have convinced me that there are loopholes in RFC-2822, and the
> spec for an authentication header MUST close those loopholes.  Any spec I
> write will say something like - A Trusted Forwarder MUST NOT alter either
> the incoming headers nor the body of a message.

And in so doing you let the undeployable best be the enemy of the deployable
good enough, and you join the ranks of at least a dozen other proposals that
will never see the light of day.

> That still leaves open the question of how difficult it will be to enlist
> Trusted Forwarders.  Is this a situation like SPF screaming "forger" at
> anyone who follows a widespread use of the MAIL FROM identity, or like CSV
> saying - You damn well better fix your EHLO name, no excuse.  I'm leaning
> to the latter,

The issue of not modifyhing header or body content has been discussed ad
nauseum on this and other lists. It is a total and complete nonstarter. And no,
I'm not going to repeat the many hundreds of messages that have already been
exchanged on this topic. In fact now that you've taken off on the "no mods of
any kind" tangent my interest in discussing this matter has dropped to zero, so
this will be my last response on this topic.

> but I could be convinced otherwise, if someone gives me more
> than vague words about some big forwarder that diddles with incoming headers.

There's this little thing called "nondisclosure agreement" that effectively
precludes my, and I suspect many other contributors, from giving specific
examples of this and lots of other stuff.

It is, however, common knowledge that I work on Sun's messaging server. Large
deals involving such software being used by ISPs are often reported in the
trade press. So, while you won't be able to arrive at anything conclusive, you
can probably get some idea of what I cannot say if you want to do some
research.

				Ned

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sat, 28 May 2005 13:19:02 -0700 (PDT)
Message-hash: tEpbsqS93hF6GaBZAlNehQ==
Subject: Re: "Header Reordering", yet again
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Sat May 28 2005 13:44, Ned Freed wrote:

> > The X.400 issue is theoretical. I have never seen it happen in practice.

> I suspect that the only way to definitively state that reordering has
> happened would be to compare "before" and "after" snapshots, and I
> suspect that that has been done; RFC 2822 states "they have been known
> to be reordered occasionally when transported".

There are plenty of known cases of reordering fields of different types while
not changing the relative ordering of fields of the same type. I believe this
fact is what led to the statement you cite.

> Definitively stating that it has never happened -- which is more germane
> to the assumption and necessary condition for some schemes -- would
> involve "before" and "after" snapshots at each transfer, and I can guarantee
> that that has not been done (it's relevant to your comment about the
> difficulty of proving a negative).

Of course it is impossible to prove a negative. But experience does count for
something. Of course some folks seem to want to have it both ways - when I say
"I've never seen such and such" they latch on to it like it proves their point,
while simultaneously they choose to ignore the next statement of the form "but
I have seen so and so".

				Ned

Date: Sat, 28 May 2005 13:05:20 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 02:05 PM 5/28/2005 -0400, Bruce Lilly wrote:
>On Sat May 28 2005 13:19, David MacQuigg wrote:
>
> > I don't know what could be more clear than:
> > '''header fields SHOULD NOT be reordered when a message is transported or
> >     transformed.  More importantly, the trace header fields and resent
> >     header fields MUST NOT be reordered, and SHOULD be kept in blocks
> >     prepended to the message.
> > '''  RFC-2821, section 3.6.
>
>I think you might mean RFC 2822.

Correct.  Sorry for the slip.

>It's clear -- if and only if one understands BCP 14 (a.k.a. RFC 2119).
>In particular, note that "SHOULD" is a recommendation, not a requirement.
>
>[...]
>
> > Agreed.  My expectations are:
> > 2) Trusted forwarders will follow the RFC-2821 requirements.
>
>Note above re. the difference between "recommendation" and "requirement".
>Note also that compliance with RFC N only applies to implementations which
>are in fact compliant with the provisions of RFC N.  It is one thing for a
>vendor to claim compliance, it is another to achieve it with a particular
>version and configuration, and it is yet another to guarantee it regardless
>of configuration.  Note well that there is nothing in a message that
>indicates a claim of compliance (there may however be evidence of a failure
>to comply, though it is not always clear where the blame lies).  Finally,
>note that there is no enforcement mechanism for provisions in RFCs, even
>those which are "requirements"; compliance is purely voluntary.  In
>particular, there is no guarantee that all SMTP receivers comply with all
>provisions of RFCs 821, 2821, and 2822.  Some of those provisions are
>mutually contradictory, and it is a known fact that the vast majority of
>SMTP receivers in fact do not comply with some provisions of all of those
>RFCs.

OK, you have convinced me that there are loopholes in RFC-2822, and the 
spec for an authentication header MUST close those loopholes.  Any spec I 
write will say something like - A Trusted Forwarder MUST NOT alter either 
the incoming headers nor the body of a message.

That still leaves open the question of how difficult it will be to enlist 
Trusted Forwarders.  Is this a situation like SPF screaming "forger" at 
anyone who follows a widespread use of the MAIL FROM identity, or like CSV 
saying - You damn well better fix your EHLO name, no excuse.  I'm leaning 
to the latter, but I could be convinced otherwise, if someone gives me more 
than vague words about some big forwarder that diddles with incoming headers.

If this is the unresolved core of this debate, we may need to do a 
survey.  These mailing list discussions have put my BS detector on max.

>I also note that as there is no standard definition of "trusted forwarders",
>there is a danger that there is an attempt at a circular definition, which
>would be of no value.

I would establish three levels of compliance for servers wanting to be 
listed as Public Mail Servers:

1) Servers that will declare their ID, and provide a DNS record to 
authorize the use of that ID.

2) Servers that will capture the IP address and any ID declared by the 
previous sender, and prepend that information in a standard authentication 
header.

3) Servers that will perform an authentication check on the declared ID, 
using any widely-accepted method, and prepend the result of that check.

Servers which only originate, and do not forward mail from other domains, 
need only reach Level 1.

--
Dave

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Sat, 28 May 2005 14:36:24 -0400
Cc: [email-masked]
Sender: [email-masked]

On Sat May 28 2005 13:44, Ned Freed wrote:

> The X.400 issue is theoretical. I have never seen it happen in practice.

I suspect that the only way to definitively state that reordering has
happened would be to compare "before" and "after" snapshots, and I
suspect that that has been done; RFC 2822 states "they have been known
to be reordered occasionally when transported".

Definitively stating that it has never happened -- which is more germane
to the assumption and necessary condition for some schemes -- would
involve "before" and "after" snapshots at each transfer, and I can guarantee
that that has not been done (it's relevant to your comment about the
difficulty of proving a negative).

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Sat, 28 May 2005 14:05:59 -0400
Cc: David MacQuigg <[email-masked]>
Sender: [email-masked]

On Sat May 28 2005 13:19, David MacQuigg wrote:

> I don't know what could be more clear than:
> '''header fields SHOULD NOT be reordered when a message is transported or
>     transformed.  More importantly, the trace header fields and resent
>     header fields MUST NOT be reordered, and SHOULD be kept in blocks
>     prepended to the message.
> '''  RFC-2821, section 3.6.

RFC 2821, section 3.6:
3.6 Domains

   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.  There are two exceptions to the rule requiring FQDNs:

   -  The domain name given in the EHLO command MUST BE either a primary
      host name (a domain name that resolves to an A RR) or, if the host
      has no name, an address literal as described in section 4.1.1.1.

   -  The reserved mailbox name "postmaster" may be used in a RCPT
      command without domain qualification (see section 4.1.1.3) and
      MUST be accepted if so used.

I think you might mean RFC 2822.

It's clear -- if and only if one understands BCP 14 (a.k.a. RFC 2119).
In particular, note that "SHOULD" is a recommendation, not a requirement.

[...]

> Agreed.  My expectations are:
> 2) Trusted forwarders will follow the RFC-2821 requirements.

Note above re. the difference between "recommendation" and "requirement".
Note also that compliance with RFC N only applies to implementations which
are in fact compliant with the provisions of RFC N.  It is one thing for a
vendor to claim compliance, it is another to achieve it with a particular
version and configuration, and it is yet another to guarantee it regardless
of configuration.  Note well that there is nothing in a message that
indicates a claim of compliance (there may however be evidence of a failure
to comply, though it is not always clear where the blame lies).  Finally,
note that there is no enforcement mechanism for provisions in RFCs, even
those which are "requirements"; compliance is purely voluntary.  In
particular, there is no guarantee that all SMTP receivers comply with all
provisions of RFCs 821, 2821, and 2822.  Some of those provisions are
mutually contradictory, and it is a known fact that the vast majority of
SMTP receivers in fact do not comply with some provisions of all of those
RFCs.

I also note that as there is no standard definition of "trusted forwarders",
there is a danger that there is an attempt at a circular definition, which
would be of no value.

From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Sat, 28 May 2005 10:44:26 -0700 (PDT)
Message-hash: E8aF5j8MxOjJTDTFosL3Ew==
Subject: Re: "Header Reordering", yet again
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Sat May 28 2005 12:13, [email-masked] wrote:
> >
> > > At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
> > > >On Fri May 27 2005 18:49, David MacQuigg wrote:
> > > >
> > > > > We don't expect every sender to be
> [...]
> > > >
> > > >Past experience with SPF indicates that spammers -- who have financial
> [...]
> >
> > > We seem to be losing context again.  The question is whether we can specify
> [...]

> Something seems to be awry with attributions.

> > Valdis Kletnieks already
> > pointed out that SPF information could be piggybacked on existing Received:
> > fields. I have yet to see an agent that reorders Received: fields.

> How does that square with:

> > > On Fri, 27 May 2005 09:31:37 -0700 (PDT), <[email-masked]>
> > > wrote:
> >
> > > > This could even result in reordering of trace fields in some cases,
> > > > especially
> > > > if clocks are out of sync (which they often are). The mapping of trace
> > > > fields
> > > > to X.400 in particular is pretty complicated.
> >
> > I should have noted that this issue only applies to Recevied: and
> > X400-Received: fields.

> One statement says that Received fields have not been observed to have
> been reordered; the other implies that Received fields are at some risk
> of being reordered.

The X.400 issue is theoretical. I have never seen it happen in practice.

				Ned

From: [email-masked]
Cc: Ned Freed <[email-masked]>, [email-masked]
Date: Sat, 28 May 2005 10:27:22 -0700 (PDT)
Message-hash: DJ/2+0NNvqzCJm9iwzyIMw==
Subject: Re: "Header Reordering", yet again
To: David MacQuigg <[email-masked]>
Sender: [email-masked]

> > The problem is the language is ambiguous at best as to whether it covers
> > relative ordering of two different fields. It is also unclear as to whether
> > new fields can be added to the set of trace fields willy-nilly.

> I don't know what could be more clear than:

> '''header fields SHOULD NOT be reordered when a message is transported or
>     transformed.  More importantly, the trace header fields and resent
>     header fields MUST NOT be reordered, and SHOULD be kept in blocks
>     prepended to the message.
> '''  RFC-2821, section 3.6.

Well, let's see. It uses "SHOULD NOT" rather than "MUST NOT", which means you
cannot count on reordering not happening. And the statement that trace and
resent fields MUST NOT be reordered doesn't make it clear whether the
reordering is amongst themselves or relative to other fields. Finally, it is
far from clear that additional trace fields like received-SPF can be added to
the set after the fact. This means that received-SPF has to be thought of
as a non-trace field, which puts its order relative to received fields
in jeopardy.

> New header lines *have* been added with no apparent breakage.  Almost every
> email I see has lines like:

This is a strawman. Nobody is claiming that new fields cannot be added. Of
course they can be. The issue is whether or not new fields can be added along
with guarantees that their ordering relative to existing fields be preserved.
The language in the specifications simply doesn't stretch that far.

> A new authentication header would be ignored by old systems, and for new
> systems, we can require that it have a particular position, at the boundary
> of an administrative domain.

Sure, you could make such a rule, although good luck on getting it through the
process. But you cannot call for old systems to honor it, and the majority of
systems will be old ones for a very long time.

> > But as I have said before, you are insisting on pursuing a specific
> > problematic solution despite the fact that there are other ways to
> > deal with this that don't open this particular door.

> I haven't proposed a solution.

You haven't, but others have: A solution involving a new Received-SPF
field.

> This thread started with Bruce Lilly's
> statement that we could not depend on header order.

Unfortunately, he's right.

> > Valdis Kletnieks already
> > pointed out that SPF information could be piggybacked on existing Received:
> > fields. I have yet to see an agent that reorders Received: fields. I have
> > seen agents modify or drop Received: fields, but this behavior seems to be
> > fairly disjoint from the sorts of forwarders where we want order to be
> > preserved.

> Well, this is encouraging.  Maybe we can at least count on Public Mail
> Servers acting as forwarders on the open Internet to not screw with
> existing headers.

For the Nth time, you cannot count on any such thing. Your expectations have
to be more limited.

>  Perhaps you could clarify your earlier example of "large
> ISPs with millions of customers".  Which ISPs are you talking about?  Are
> they acting as forwarders, or final destination receivers?

Both.

> > It is all a question of using the right mechanism and having realistic
> > expectations.

> Agreed.  My expectations are:

> 1) Spammers can't mess with headers prepended after the email is out of
> their domain.

Hopefully true.

> 2) Trusted forwarders will follow the RFC-2821 requirements.

Which don't include the guarantees you seem to think they do.

> 3) Authentication headers added by a Trusted Forwarder will not break
> downstream MTA's.

Also hopefully true.

> 4) Header reordering will occur only before the first Trusted Forwarder, or
> after authentication at the final destination.

Again, it depends on the sort of reordering you're talking about,

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Sat, 28 May 2005 13:26:16 -0400
Cc: [email-masked]
Sender: [email-masked]

On Sat May 28 2005 12:13, [email-masked] wrote:
> 
> > At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
> > >On Fri May 27 2005 18:49, David MacQuigg wrote:
> > >
> > > > We don't expect every sender to be
[...]
> > >
> > >Past experience with SPF indicates that spammers -- who have financial
[...]
> 
> > We seem to be losing context again.  The question is whether we can specify
[...]

Something seems to be awry with attributions.

> Valdis Kletnieks already
> pointed out that SPF information could be piggybacked on existing Received:
> fields. I have yet to see an agent that reorders Received: fields.

How does that square with:

> > On Fri, 27 May 2005 09:31:37 -0700 (PDT), <[email-masked]>
> > wrote:
> 
> > > This could even result in reordering of trace fields in some cases,
> > > especially
> > > if clocks are out of sync (which they often are). The mapping of trace
> > > fields
> > > to X.400 in particular is pretty complicated.
> 
> I should have noted that this issue only applies to Recevied: and
> X400-Received: fields.

One statement says that Received fields have not been observed to have
been reordered; the other implies that Received fields are at some risk
of being reordered.

Date: Sat, 28 May 2005 10:19:10 -0700
To: Ned Freed <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Cc: [email-masked]
Sender: [email-masked]

Ned,  I like the tone of this response much better than your last.  It's OK 
to disagree, let's just avoid calling each other idiots.

At 09:13 AM 5/28/2005 -0700, Ned Freed wrote:
>>At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
>> >On Fri May 27 2005 18:49, David MacQuigg wrote:
>> >
>> > > We don't expect every sender to be
>> > > compliant, just the ones that want to be trusted as Public Mail
>> > > Servers.  This may be a small number at first.  Then others will 
>> discover
>> > > the benefits of becoming compliant - bypass the spam filtering.
>> >
>> >Past experience with SPF indicates that spammers -- who have financial
>> >incentive -- will be early adopters, and legitimate mailers who don't
>> >conform to your preconceived notions will be harmed.  The spammers
>> >will claim that because they comply with your scheme, they aren't
>> >really spammers at all.  The scheme -- like SPF -- would be doubly
>> >harmful.
>
>>We seem to be losing context again.  The question is whether we can specify
>>that Trusted Forwarders MUST NOT reorder trace headers, using the same
>>language as the words from RFC-2822 that you snipped.
>
>The problem is the language is ambiguous at best as to whether it covers
>relative ordering of two different fields. It is also unclear as to whether
>new fields can be added to the set of trace fields willy-nilly.

I don't know what could be more clear than:
'''header fields SHOULD NOT be reordered when a message is transported or
    transformed.  More importantly, the trace header fields and resent
    header fields MUST NOT be reordered, and SHOULD be kept in blocks
    prepended to the message.
'''  RFC-2821, section 3.6.

New header lines *have* been added with no apparent breakage.  Almost every 
email I see has lines like:
X-Persona: <yahoo>
X-Apparently-To: [email-masked] via 68.142.198.149; Sat, 28 May 
2005 09:33:48 -0700

A new authentication header would be ignored by old systems, and for new 
systems, we can require that it have a particular position, at the boundary 
of an administrative domain.

>But as I have said before, you are insisting on pursuing a specific
>problematic solution despite the fact that there are other ways to
>deal with this that don't open this particular door.

I haven't proposed a solution.  This thread started with Bruce Lilly's 
statement that we could not depend on header order.  The last time we had 
this discussion, the thread dissolved in noise before reaching a 
conclusion.  I'm attempting to keep this thread on track.

>Valdis Kletnieks already
>pointed out that SPF information could be piggybacked on existing Received:
>fields. I have yet to see an agent that reorders Received: fields. I have
>seen agents modify or drop Received: fields, but this behavior seems to be
>fairly disjoint from the sorts of forwarders where we want order to be
>preserved.

Well, this is encouraging.  Maybe we can at least count on Public Mail 
Servers acting as forwarders on the open Internet to not screw with 
existing headers.  Perhaps you could clarify your earlier example of "large 
ISPs with millions of customers".  Which ISPs are you talking about?  Are 
they acting as forwarders, or final destination receivers?

>It is all a question of using the right mechanism and having realistic
>expectations.

Agreed.  My expectations are:
1) Spammers can't mess with headers prepended after the email is out of 
their domain.
2) Trusted forwarders will follow the RFC-2821 requirements.
3) Authentication headers added by a Trusted Forwarder will not break 
downstream MTA's.
4) Header reordering will occur only before the first Trusted Forwarder, or 
after authentication at the final destination.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: [email-masked]
Cc: [email-masked]
Date: Sat, 28 May 2005 09:13:58 -0700 (PDT)
Subject: Re: "Header Reordering", yet again
To: David MacQuigg <[email-masked]>
Sender: [email-masked]

> At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
> >On Fri May 27 2005 18:49, David MacQuigg wrote:
> >
> > > We don't expect every sender to be
> > > compliant, just the ones that want to be trusted as Public Mail
> > > Servers.  This may be a small number at first.  Then others will discover
> > > the benefits of becoming compliant - bypass the spam filtering.
> >
> >Past experience with SPF indicates that spammers -- who have financial
> >incentive -- will be early adopters, and legitimate mailers who don't
> >conform to your preconceived notions will be harmed.  The spammers
> >will claim that because they comply with your scheme, they aren't
> >really spammers at all.  The scheme -- like SPF -- would be doubly
> >harmful.

> We seem to be losing context again.  The question is whether we can specify
> that Trusted Forwarders MUST NOT reorder trace headers, using the same
> language as the words from RFC-2822 that you snipped.

The problem is the language is ambiguous at best as to whether it covers
relative ordering of two different fields. It is also unclear as to whether
new fields can be added to the set of trace fields willy-nilly.

But as I have said before, you are insisting on pursuing a specific
problematic solution despite the fact that there are other ways to
deal with this that don't open this particular door. Valdis Kletnieks already
pointed out that SPF information could be piggybacked on existing Received:
fields. I have yet to see an agent that reorders Received: fields. I have
seen agents modify or drop Received: fields, but this behavior seems to be
fairly disjoint from the sorts of forwarders where we want order to be
preserved.

It is all a question of using the right mechanism and having realistic
expectations.

				Ned

From: [email-masked]
Cc: [email-masked], Bruce Lilly <[email-masked]>, [email-masked], David MacQuigg <[email-masked]>
Date: Fri, 27 May 2005 18:29:47 -0700 (PDT)
Message-hash: pmywazHCgnuJWeCvYq/sog==
Subject: Re: "Header Reordering", yet again
To: Paul Smith <[email-masked]>
Sender: [email-masked]

> On Fri, 27 May 2005 09:31:37 -0700 (PDT), <[email-masked]>
> wrote:

> > This could even result in reordering of trace fields in some cases,
> > especially
> > if clocks are out of sync (which they often are). The mapping of trace
> > fields
> > to X.400 in particular is pretty complicated.

I should have noted that this issue only applies to Recevied: and
X400-Received: fields. No other field mappings have similar characteristics,
and I doubt very much that mappings of newly defined trace fields to X.400
constructs will be done.

> So, why not have some explicit ordering of any new trace fields, rather
> than relying in their order in the header

It's a cute idea, one that might even be useful for future trace
header definitions. But it is much too late to change the syntax
of Received: fields. And even if it were applied to Received-SPF fields,
it does nothing to keep the Received-SPF ordered relative to Received: fields.

> Just a thought...

And not a bad one. I just don't see how it can be used to deal with problems
associated with existing fields and their relative ordering.

				Ned

Date: Sat, 28 May 2005 08:53:22 -0700
To: Dave Crocker <[email-masked]>, <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Cc: <[email-masked]>
Sender: [email-masked]

Dave,

I appreciate your comments, and I will do my best to include your 
objections in my summary at http://purl.net/macquigg/email - 
authent-declare-objections.htm.   I think I have most of these already, but 
I will use your wording where it is better.  See my responses below, and 
please correct me if I'm wrong on anything.  Some of the objections are not 
resolvable, as they involve assumptions about the future, but others are 
just a matter of finding the facts.  It would be nice if we could resolve 
the factual misunderstandings before presenting this to the IESG.

You may have read only the initial revision of the draft.  I have added 
many clarifications as a result of the discussions.  These are highlighted 
in yellow in all but the txt format.  See the link above.

At 09:13 AM 5/28/2005 +0200, Dave Crocker wrote:

>1. Your proposal presumes that there is a single, universal reference to be
>used, among protocols that have widely different semantics.  There isn't.

Response:  The ID declaration does not favor one authentication method over 
another.  It does not expect the methods to use the common identity.  It 
simply facilitates access to whatever methods the sending MTA provides.  It 
is the methods themselves that decide which identity to check.  CSV can 
continue to use the EHLO identity.  SPF may decide to let the declared ID 
override the MAIL FROM identity.  Each method can chose what is best.

This objection is very similar to one from this group I have listed already:

Obj:  Inter-operability and trust cannot involve different independent 
identities.  We must choose one identity, and that is what MARID tried to 
do already.  There is no point to having a common ID without an agreement 
as to which identity we mean.

Resp:  Inter-operability requires that each sender-receiver pair have at 
least one method in common.  It does not require one method or choice of 
identity for the entire Internet or even for all the MTA's along the path 
from originator to final destination.  MARID tried to reach agreement on 
some difficult questions, including the choice of identity.  The proposal 
is for a standard form to declare an identity, not a limitation on which 
identity that must be.  Agreement on this simple standard will help 
overcome the paralysis we have seen after the MARID failure.

Also this from [spf-discuss]:

Obj:  The ID method cannot authenticate all the permissions that various 
identities have granted the sending MTA.  These permissions may be 
important to a receiver.

Resp:  The ID declaration is just that - a declaration.  It is not an 
authentication method.  It does not take sides in the battle over 
authentication methods.  It simply facilitates access to whatever methods 
the sending MTA provides.  It does not prevent a receiver from trying other 
methods.  It does not prevent a receiver from rejecting a sender that 
doesn't provide a receiver's favorite method.

Also these paragraphs added to section 2:

The ID command provides a domain name independent of other names in the 
envelope and headers.  It should be a short, memorable name to enhance its 
value as a Public Mail Server identity.  There are three semantics 
associated with this new name.

1) It may be used for accreditation and reputation.
2) It may be used to specify the location for authentication records.
3) It may be used, after authentication, as a bounce address for complaints 
and challenges relating to spam.

>2. Your proposal presumes that exactly one mechanism will be used.  That's 
>not a
>safe assumption.

Response:  The owner of the ID can provide any methods that it 
chooses.  The receiver can use any or all of these methods.

>3. Your proposal seeks to modify the SMTP protocol exchange state diagram.
>That's rather a major change to the Internet infrastructure.  It is something
>that has been avoided throughout many, many changes since the creation of 
>smtp.

I don't understand.  The response to EHLO is a list of extensions.  We are 
adding one more extension.  If the ID extension is offered in the EHLO 
response, the sender may send an ID command, but it is not required to do so.

Somewhat related from [spf-discuss]:

Obj:  Getting an SMTP extension will take many years, and by that time 
everyone will be using <my method>, so no DNS hunting will be necessary.

Resp:  Getting an SMTP extension should not be that difficult if we follow 
the standard IANA procedure for registering keywords and their 
parameters.  Other keywords relating to spam, such as NO-SOLICITING, have 
been registered already.  See http://www.iana.org/assignments/mail-parameters.

>4. Your proposal adds a round-trip cost to the SMTP session.  That is 
>something
>that has been very, very forcefully avoided since the creation of 
>SMTP.  Please
>review the nature of EHLO as a means of adding options to SMTP and note 
>that it
>does not add a round-trip.

Using the ID command adds one round-trip (command - response) per SMTP 
session, and only for those sessions that wish to use authentication.  This 
is an insignificant cost compared to the DNS hunting that will be required 
otherwise.  It is not necessary to use the ID command, even if it is 
offered.  Older systems will not have any added round trip.

I am assuming the use of a normal EHLO extension.  Originally, I thought I 
could just add an extra string at the end of the EHLO command, but it 
appears that the RFC-2821 EHLO syntax did not anticipate any 
extensions.  Please explain what you mean by using EHLO to avoid adding a 
round trip.

>5. As others have quite forcefully noted, your proposal does not make a 
>case for
>it's solving a significant problem.

Are you saying that avoiding a DNS hunt is not solving a significant 
problem?  I understand others have noted quite forcefully, but usually this 
"forcefulness" only lowers the signal-to-noise ratio.  Unless we accept 
"hate it" as a valid objection, we need to tone down these discussions, and 
focus on getting at the facts and underlying assumptions.

One of the less forceful folks was able to explain his assumptions.  It was 
a plausible assumption, but one that I don't share.  This is one of the few 
issues that really will require wisdom and foresight to decide what is 
right, and one of the few that should be presented to the IESG.  Here is 
what I distilled from the earlier discussion:

Obj:  DNS hunts will not be necessary.  Receivers will use whatever method 
they prefer, and senders will have to offer all methods.

Resp:  This assumes a future in which receivers call the shots and senders 
have to offer every method receivers may want.  A more likely future is an 
extension of the current situation with receivers wanting to use any and 
all methods that will work, and senders wanting to do the minimum necessary 
to avoid losing reputation.

Whatever the future, DNS hunts or not, there are still advantages to having 
a universal ID declaration, and no disadvantages.

Email IDs can be a powerful motivator in changing our email culture.  A 
reputable ID will become a "broadcast license" to be treated with 
respect.  Anyone wanting to operate a Public Mail Server should have no 
objection to offering an ID.  Owners of reputable IDs will not tolerate 
abuse of those IDs.  Receivers will quickly learn which IDs they can 
trust.  The rest will be easily ignored, even if spammers own 99% of the 
Internet.

Having a neutral syntax for an ID declaration is one of the few things that 
all methods could agree on.  This is a small step away from a de-facto 
standard with a "lock in" for whatever method wins the marketing and PR 
battles ahead.
---

I think that last paragraph should be of special interest to CSV.  In spite 
of its technical advantages, CSV is losing the marketing and PR 
battles.  Wouldn't it be nice if you could deploy CSV without facing the 
"chicken-and-egg" problem?

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: Dave Crocker <[email-masked]>
To: David MacQuigg <[email-masked]>, <[email-masked]>
CC: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 28 May 2005 09:13:45 +0200
Delivery-Date: Sat, 28 May 2005 09:13:45 -0000
Subject: Re: Sender's Declaration of Identity
Sender: [email-masked]

>  And we don't know, when the message arrives, whether it uses Sender-ID,
>  SPF, or some other method.

David,

1. Your proposal presumes that there is a single, universal reference to be 
used, among protocols that have widely different semantics.  There isn't.

2. Your proposal presumes that exactly one mechanism will be used.  That's not a 
safe assumption.

3. Your proposal seeks to modify the SMTP protocol exchange state diagram.  
That's rather a major change to the Internet infrastructure.  It is something 
that has been avoided throughout many, many changes since the creation of smtp.

4. Your proposal adds a round-trip cost to the SMTP session.  That is something
that has been very, very forcefully avoided since the creation of SMTP.  Please
review the nature of EHLO as a means of adding options to SMTP and note that it
does not add a round-trip.

5. As others have quite forcefully noted, your proposal does not make a case for 
it's solving a significant problem.

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

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
CC: Frank Ellermann <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 28 May 2005 09:25:42 +0200
Delivery-Date: Sat, 28 May 2005 09:25:42 -0000
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

Bruce,

> >  The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
> >  do very different things, SPF covers some older ideas.
> >
>  They all suffer from similar problems involving the issues
>  described in previous messages:
>  1. conflating sending and receiving

How does CSV conflate sending and receiving?

>  2. failure to understand fundamental properties of SMTP, e.g.
>  MAIL FROM remains unchanged during transport

CSV does not use MailFrom.

>  3. attempts to assign a relationship between domain names
>  and IP addresses for sending email; there is no such
>  relationship
>  etc.

Oh?  Please cite the specific bits of CSV specification that asserts or requires 
a non-existent domain-name/IP-Address relationship.

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

From: Dave Crocker <[email-masked]>
To: Frank Ellermann <[email-masked]>, <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 28 May 2005 09:21:38 +0200
Delivery-Date: Sat, 28 May 2005 09:21:38 -0000
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

> >  The IESG intent at the closing of MARID was that the various
> >  drafts be submitted by individuals for "Experimental" status.
> >
>  I've never found out what the intent was of not discussing CSV
>  at all,

Marid had become non-functional, by the time that there might have been 
discussion of CSV.  We were asked to defer discussion of CSV to a new working 
group that would be formed.  

We were then told not to form the working group, in the fear that it would 
suffer the same degree of confusion that afflicted Marid.

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

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Fri, 27 May 2005 23:44:09 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Fri May 27 2005 23:03, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > In order to work around a problem *at the provider* (or at
> > least *affecting the provider*), it was necessary to go
> > directly to a recipient's MX host.  Your "solution", costs
> > aside, supposes that at least one of the providers is
> > unaffected by the problem
> 
> Okay, your solution was sending direct-to-MX with a MAIL FROM
> [email-masked] and a HELO bruces.box.example

No, neither MAIL FROM nor HELO/EHLO were changed. no point in
changing MAIL FROM, as the intent was not to change where
delivery notices were sent.  No way to change EHLO/HELO
(unconfigurable) [at least at that time], and in any event the
sending machine wasn't changed, so an EHLO/HELO change would
have been inappropriate.

> Not at the same time, BTW,

So your scheme to do what I achieved in about a minute would be to
change SPF records under some domain that I have no control over,
wait for to TTLs to expire, and try again?  Sounds rather cumbersome.

> > it won't work at all if you specifically want to delegate
> > handling of delivery notifications.
> 
> [email-masked] works.

No. You're presuming that there's an MX record (actually >= 2)
for such a thing and that there's a way to get mail there (due
to DHCP, the first is impractical at best, and the second is
prohibited by terms of service: "no servers").

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Sat, 28 May 2005 05:03:31 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 60
Sender: [email-masked]

Bruce Lilly wrote:

> In order to work around a problem *at the provider* (or at
> least *affecting the provider*), it was necessary to go
> directly to a recipient's MX host.  Your "solution", costs
> aside, supposes that at least one of the providers is
> unaffected by the problem

Okay, your solution was sending direct-to-MX with a MAIL FROM
[email-masked] and a HELO bruces.box.example

If bruces.box.example has no sender policy it works.  If it
has "v=spf1 include:provider.problem.example a -all" it also
works.  If you forgot the "a" although you sometimes send
direct-to-MX add it.

In theory you could arrange this for a DynDNS domain.  Yes, it
would cost something.  But the most expensive part of it is a
reliable MX provider, unless you think that an MX with a dyn.
IP is a cute idea.

> In your specific pet case of "misdirected bounces"

Yes, these TeraBytes of crap, not only real bounces.

> (think Comcast or RoadRunner)

Not at the same time, BTW, RR has an SPF policy.  I never use
the other word for spamcast, unless it's in an SPF example for
spambot nets.

>> when I now have a problem with A I simply send the mail via
>> B, just using the corresponding MAIL FROM:<[email-masked]>

> That's OK for you, assuming that's where you *want* to
> receive delivery notifications.

Of course.  If there's some mail problem between B and C, then
adding A to the equation would only muddy the waters.  And we
started with the assumption that there is a problem between A
and C, that's why I was forced to use the B-route.

> That might not work for others.

Then they'll use other means to discuss it with A and / or C.
Your direct-to-MX solution is also fine.  Just make sure that
you use a MAIL FROM corresponding to the route if you have SPF
policies, otherwise (no policy) do whatever pleaes you.

> it won't work at all if you specifically want to delegate
> handling of delivery notifications.

[email-masked] works.  Only if you insist on a
MAIL FROM:<listadminATxyzzy.claranet.de> you'd need a new ISP,
that won't work direct-to-MX or via other providers.  But as I
said I could manage it.  This ISP even offers an alias that's
not SPF protected.  So far I never needed it, zero problems.

                             Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Certified Server Validation (was: "CSV" [not comma-separated values])
Date:  Sat, 28 May 2005 04:04:33 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 14
Sender: [email-masked]

[email-masked] wrote:

> Shutting down open relays forced a lot of people to change
> their email practices. But does anyone still think keeping
> them open was viable?

Dean Anderson.  One unnecessary statement about this issue in
an early SPF draft was removed, anybody is free to "permit"
the IPs of open relays in his sender policy.  And I guess that
open relays are also "compatible" with MTAMARK or CSV in some
way.  Maybe they could even get an IADB rating, "yes, I am an
open relay".  <shrug />
                       Bye, Frank

Date: Fri, 27 May 2005 17:39:34 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 08:05 PM 5/27/2005 -0400, Bruce Lilly wrote:
>On Fri May 27 2005 18:49, David MacQuigg wrote:
>
> > We don't expect every sender to be
> > compliant, just the ones that want to be trusted as Public Mail
> > Servers.  This may be a small number at first.  Then others will discover
> > the benefits of becoming compliant - bypass the spam filtering.
>
>Past experience with SPF indicates that spammers -- who have financial
>incentive -- will be early adopters, and legitimate mailers who don't
>conform to your preconceived notions will be harmed.  The spammers
>will claim that because they comply with your scheme, they aren't
>really spammers at all.  The scheme -- like SPF -- would be doubly
>harmful.

We seem to be losing context again.  The question is whether we can specify 
that Trusted Forwarders MUST NOT reorder trace headers, using the same 
language as the words from RFC-2822 that you snipped.  What does it matter 
if spammers conform to this requirement?  How will legitimate mailers be 
hurt?  If they send through a forwarder that is not trusted, they have to 
go through the same spam filter that they have always gone through.  Using 
a Trusted Forwarder is a plus.  Not using one is not a minus.

You seem to have a "preconceived notion" that all change is wrong.  Let's 
avoid the personal attacks and focus on facts.  You could have said "don't 
conform to your expectations", and been less inflammatory.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Fri, 27 May 2005 20:05:18 -0400
Cc: David MacQuigg <[email-masked]>
Sender: [email-masked]

On Fri May 27 2005 18:49, David MacQuigg wrote:

> We don't expect every sender to be 
> compliant, just the ones that want to be trusted as Public Mail 
> Servers.  This may be a small number at first.  Then others will discover 
> the benefits of becoming compliant - bypass the spam filtering.

Past experience with SPF indicates that spammers -- who have financial
incentive -- will be early adopters, and legitimate mailers who don't
conform to your preconceived notions will be harmed.  The spammers
will claim that because they comply with your scheme, they aren't
really spammers at all.  The scheme -- like SPF -- would be doubly
harmful.

From: [email-masked]
Cc: [email-masked]
Date: Fri, 27 May 2005 16:07:57 -0700 (PDT)
Subject: Re: "Header Reordering", yet again
To: David MacQuigg <[email-masked]>
Sender: [email-masked]

> At 11:15 AM 5/27/2005 -0400, Bruce Lilly wrote:
> >On Fri May 27 2005 10:09, David MacQuigg wrote:
> > > At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:
> >
> > > >Except for a few inconvenient facts:
> > > >a) "It is important to note that the header fields are not guaranteed to
> > > >    be in a particular order.  They may appear in any order, and they
> > > >    have been known to be reordered occasionally when transported over
> > > >    the Internet." RFC 2822, section 3.6
> > >
> > > Here is the complete quote:
> >
> >That doesn't change the fact that there is no guarantee, and that any
> >assumption of a particular order is flawed.

> If we expect a guarantee, then no authentication method will work, not even
> signatures.

Nonsense. Authentication schemes are possible that don't depend on header
ordering being preserved through multiple hops. Or, to put it another way,
there are enough guarantees in place that workable solutions can be found. The
problem is people persist in either trying to promote stuff that's effectively
unworkable or they try to push workable stuff to the point where it becomes
unworkable.

> There will always be systems that don't comply with any standard.

But that's precisely the point: These systems DO comply with what's currently
standardized. You want to change what's standardized after the fact to fit your
preconcieved notions of how things are supposed to work.

> The key question is can we expect enough compliance that
> authentication will be useful?  We don't expect every sender to be
> compliant, just the ones that want to be trusted as Public Mail
> Servers.  This may be a small number at first.  Then others will discover
> the benefits of becoming compliant - bypass the spam filtering.

The systems I'm talking about tend to be one run by large ISPs with
millions of customers.

				Ned

Date: Fri, 27 May 2005 15:49:58 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Sender: [email-masked]

At 11:15 AM 5/27/2005 -0400, Bruce Lilly wrote:
>On Fri May 27 2005 10:09, David MacQuigg wrote:
> > At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:
>
> > >Except for a few inconvenient facts:
> > >a) "It is important to note that the header fields are not guaranteed to
> > >    be in a particular order.  They may appear in any order, and they
> > >    have been known to be reordered occasionally when transported over
> > >    the Internet." RFC 2822, section 3.6
> >
> > Here is the complete quote:
>
>That doesn't change the fact that there is no guarantee, and that any
>assumption of a particular order is flawed.

If we expect a guarantee, then no authentication method will work, not even 
signatures.  There will always be systems that don't comply with any 
standard.  The key question is can we expect enough compliance that 
authentication will be useful?  We don't expect every sender to be 
compliant, just the ones that want to be trusted as Public Mail 
Servers.  This may be a small number at first.  Then others will discover 
the benefits of becoming compliant - bypass the spam filtering.

> > Furthermore:
> >     """When an SMTP server
>
>Not all transport is via SMTP (while a given entity may use SMTP, there
>is no guarantee that *ALL* preceding "hops" in the store-and-forward
>transport chain used SMTP (nor, that *ALL* SMTP hops were conformant to
>RFC 2821, a Proposed Standard)).

If the non-SMTP hops are in private networks, we don't need to look inside 
their mail structure.  They will present an ID at their gateway to the 
Public Internet, and it is that ID that gets rated.

How much of the Public Internet mail transfer (not including private 
networks) is non-SMTP?  Where would these "bubbles" fit in Dave Crocker's 
mail architecture Protocols and Services diagram?

>Moreover, specific exceptions are granted
>to gateways and MSAs, and there is no reliable way to determine if an SMTP
>receiver operating on port 25 is a gateway or MSA; there are no gateway- or
>MSA-sepcific response codes nor are there any ESMTP keywords that indicate
>to a client "this is a gateway" or "this is an MSA".  There is certainly
>no way that a subsequent analysis of the message can make any kind of
>reliable assessment of whether or not any receiver that putatively handled
>the message in transit was a gateway or MSA.

Again, this sounds like "internal stuff" that we don't need to look 
at.  Any server that wants to be a trusted Public Mail Server must follow 
the rules, whether they are an SMTP MTA, an X.400 MSA, or a Gameboy.  The 
final receiver will step back through the authentication headers, skipping 
maybe one or two trusted forwarders, then to the Identity which will be rated.

>And by the time one has a message in a place where it can be examined, it
>might not even be in the Internet Message Format per se.  I am told (but
>have no independent confirmation) that systems such as Lotus Notes and
>Microsoft Exchange do not indicate (to applications accessing content
>for filtering) field order.

Do these strange systems occur as forwarders on the Public Internet?  A 
receiver can do whatever it wants with the headers on its own incoming 
mail.  It can even pay its own forwarder to re-arrange headers on incoming 
mail.  If that forwarder re-arranges headers going to other customers, 
however, it will lose its status as a Trusted Forwarder.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Fri, 27 May 2005 18:28:30 -0400
Cc: "Paul Smith" <[email-masked]>
Sender: [email-masked]

On Fri May 27 2005 14:41, Paul Smith wrote:

> So, why not have some explicit ordering of any new trace fields, rather  
> than relying in their order in the header
> 
> For instance, put a sequence number in the header data
[...]

As with any proposed new functionality, good luck getting all of
the deployed infrastructure to implement it (which necessarily
involves getting users to update).

Add to that the likely case (considering the statements about
ordering made here, where one might expect people to know better)
of one or more developers assuming that he only need to examine
the first field to find the current maximum value...

There's also the philosophic/architectural objection that the
scheme requires poking about in the content, which is not supposed
to happen in SMTP (with the notable exception of gateways).

If you were to ignore that objection, you'd still have to specify
what's supposed to happen when a missing (as Ned noted, fields
sometimes get dropped) or duplicate sequence number is found.

To: Paul Smith <[email-masked]>
Cc: Lyndon Nerenberg <[email-masked]>, [email-masked]
Subject: Re: "Header Reordering", yet again 
From: [email-masked]
Date: Fri, 27 May 2005 17:44:02 -0400
Sender: [email-masked]

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

On Fri, 27 May 2005 21:22:06 BST, Paul Smith said:

> If you're worried about overflows (eg the spammer adding an index of 65535  
> hoping the next one will wrap around to 0) then you could say that index  
> values can't go over 100, if they do messages must be rejected (as most  
> messages with large numbers of Received: headers are, for loop detection  
> (at much smaller counts than 100). Then, what will the spammer fake? They  
> can't fake anything that will actually do any good!

It *does* however present an interesting new way to DDoS somebody - have a bunch
of zombies send joe-jobbed mail addressed from the victim, to sites that haven't
learned about the dangers of accept-then-bounce. ;)

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

--==_Exmh_1117230242_4133P--

To: "Lyndon Nerenberg" <[email-masked]>
Cc: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Fri, 27 May 2005 21:22:06 +0100
From: "Paul Smith" <[email-masked]>
Sender: [email-masked]

On Fri, 27 May 2005 12:38:54 -0700, Lyndon Nerenberg <[email-masked]>  
wrote:

>
> On May 27, 2005, at 11:41 AM, Paul Smith wrote:
>
>> It's only if something rewrites the headers, or puts the wrong sequence  
>> number on when adding a trace header that you'd have a problem
>
> Such as a spammer injecting messages with a bogus trace header index  
> already set to the maximum possible value?

And what's that then?

The only time the spammer gets chance to do anything is when the message  
is originally sent.

So, lets say they add:

Trace-Header: 10000, faked trace info

All that happens is either the next server says '10000? that's obviously  
fake - this must be spam' or adds

Trace-Header: 10001, true trace info

so, the spammer's trace info is overridden anyway

(Just like the spammer adding fake trace info in implicitly ordered header  
fields)

If you're worried about overflows (eg the spammer adding an index of 65535  
hoping the next one will wrap around to 0) then you could say that index  
values can't go over 100, if they do messages must be rejected (as most  
messages with large numbers of Received: headers are, for loop detection  
(at much smaller counts than 100). Then, what will the spammer fake? They  
can't fake anything that will actually do any good!

Cc: [email-masked]
From: Lyndon Nerenberg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Fri, 27 May 2005 12:38:54 -0700
To: Paul Smith <[email-masked]>
X-DCC-sgs_public_dcc_server-Metrics: orthanc.ca 1199; Body=2 Fuz1=2 Fuz2=2
Sender: [email-masked]

On May 27, 2005, at 11:41 AM, Paul Smith wrote:

> It's only if something rewrites the headers, or puts the wrong  
> sequence number on when adding a trace header that you'd have a  
> problem

Such as a spammer injecting messages with a bogus trace header index  
already set to the maximum possible value?

--lyndon

To: Ned Freed <[email-masked]>
Cc: Tony Finch <[email-masked]>, [email-masked]
Subject: Re: "CSV" [not comma-separated values] 
From: [email-masked]
Date: Fri, 27 May 2005 14:56:45 -0400
Sender: [email-masked]

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

On Fri, 27 May 2005 10:06:19 PDT, Ned Freed said:
> Doesn't this in turn assume that your ISP is the only one who can provide you
> mail service? I suppose it is possible that there are providers out there that
> block everything but port 80 and do stateful inspection of port 80 traffic to
> insure it it is really HTTP. But even then there are web-based alternatives...

There *are* an increasing number of providers who think that "walled garden"
is a feasible business model - not all of whom are open about that fact with
customers.

The recent trend towards "Deep Inspection firewalls" is really a code word
for "so much stuff is now tunneled over port 80/443 to get through firewalls
that we may as well just treat them as IP tunneling/encapsulation schemes..."

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

--==_Exmh_1117220205_5814P--

To: [email-masked], "Bruce Lilly" <[email-masked]>
Cc: [email-masked], "David MacQuigg" <[email-masked]>
Subject: Re: "Header Reordering", yet again
Date: Fri, 27 May 2005 19:41:13 +0100
From: "Paul Smith" <[email-masked]>
Sender: [email-masked]

On Fri, 27 May 2005 09:31:37 -0700 (PDT), <[email-masked]>  
wrote:

> This could even result in reordering of trace fields in some cases,  
> especially
> if clocks are out of sync (which they often are). The mapping of trace  
> fields
> to X.400 in particular is pretty complicated.

So, why not have some explicit ordering of any new trace fields, rather  
than relying in their order in the header

For instance, put a sequence number in the header data, and whenever you  
add a trace header, add one onto the sequence number. (Yes, I appreciate  
this may make it harder to add them, but if the ordering doesn't then  
matter, you could add the new trace headers at the end of the header after  
you've seen all the other header lines so you know what sequence number  
you should use)

eg

Trace-Header: 3, trace data 10:30 +0000
From: [email-masked]
Trace-Header: 1, trace data 10:00 +0000
Subject: my subject
Trace-Header: 2, trace data 10:15 +0000

You could still put the trace headers in the right order whatever  
re-ordering of headers is done by anything. It's only if something  
rewrites the headers, or puts the wrong sequence number on when adding a  
trace header that you'd have a problem - but if you rely on header  
ordering, then you're at the mercy of any program which sees the message  
at all, even ones which don't understand your new trace headers. Having  
explicit ordering, you're only at the mercy of programs which claim to  
understand and support your new headers.

Just a thought...

Paul

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: "CSV" [not comma-separated values]
Date:  Fri, 27 May 2005 13:11:58 -0500
Lines: 16
Cancel-Lock: sha1:6hE2OxP5AjWaAJ8gNNH4oQGEKQg=
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

> This at least I have some sympathy for - we've all had these phone calls - but
> it doesn't rise to the level of making me think CSV is a bad idea that should
> not be deployed.

Agreed.

> Shutting down open relays forced a lot of people to change their email
> practices. But does anyone still think keeping them open was viable?

toad?

-wayne

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "CSV" [not comma-separated values]
Date: Fri, 27 May 2005 13:27:49 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Thu May 26 2005 13:52, Tony Finch wrote:
> 
> On Thu, 26 May 2005, Bruce Lilly wrote:

> > When a piece of software -- categorize it as you will -- connects to
> > an SMTP server and presents a domain name derived from a receiving
> > mailbox domain in EHLO/HELO, there is such conflation.  We might
> > tentatively agree that such software isn't operating according to
> > assumptions behind the rules of a twenty-year-old protocol, but the
> > present-day facts of life are such that in many cases there simply is
> > no other option available to such software.
> 
> That's a problem with the sender's configuration, not with CSV.

It's a characteristic of modern Internet deployment, and as CSV doesn't
take that characteristic into account, there is a problem with CSV.  The
simple fact is that a piece of software is often unable to determine
things such as a host name (see the current discussion of DHCP on the
ietf-822 list (don't ask me why it's there and not here)).

> I do know 
> of software that makes it impossible to fix this kind of configuration
> problem, but these email programs are designed to talk to an MSA, in which
> case the problem is moot.

You're presuming that:
1. the MSA is always external (there exist laptops with MSAs and/or MTAs
   installed)
2. that some appropriate information can be determined (see above, including
   the reference DHCP discussion).

> You claim that nevertheless it is still a 
> problem because in general SMTP software doesn't know what role its peer
> is acting in, but again this is a fallacy because in a specific case the
> site's policy can disambiguate,

o there is still the problem with attempting a one-size-fits-all approach
  to "site" vs. a mail sender
o that ignores the issue of how sending software or users are supposed to
  be able to determine that there is some policy, much less what that
  policy is (see Valdis' comments)

> The LMAP
> protocols are all intended for use with SMTP over TCP across the public
> Internet routed according to RFC 974.

As far as I can see, the proposals do not make such things clear.  Some
in fact claim "all SMTP" or something similar.

> They aren't for use within an
> organization because in that case other authentication and authorization
> mechanisms are more appropriate and more effective.

Nice theory.  In practice, defining "an organization" and determining
organizational boundaries are necessary and non-trivial.

From: [email-masked]
Cc: Tony Finch <[email-masked]>, [email-masked]
Date: Fri, 27 May 2005 10:06:19 -0700 (PDT)
Subject: Re: "CSV" [not comma-separated values]
To: [email-masked]
Sender: [email-masked]

> On Thu, 26 May 2005 18:52:54 BST, Tony Finch said:

> > If a sender doesn't like their site's policies, they can get another ISP
> > or have a chat with their sysadmins or whatever.

> This makes 3 assumptions:

> 1) That the sender is even able to recognize that the breakage is due to the
> site policy.

There's no substitute for knowledge, including knowing when you need to find
someone who knows more about this than you do to help out.

> 2) That there exists a *realistic* alternative ISP (you're always free to switch
> to the *other* cable company for your broadband, right? ;)

Doesn't this in turn assume that your ISP is the only one who can provide you
mail service? I suppose it is possible that there are providers out there that
block everything but port 80 and do stateful inspection of port 80 traffic to
insure it it is really HTTP. But even then there are web-based alternatives...

I'm sorry, but I have a lot more sympathy for the many folks who have no access
to the Internet in any form (or to food, clean water, or satefy for that
matter) than I do for someone with a dainbramaged ISP. Workarounds are almost
always possible for the latter, even for unsophisticated users.

> 3) That the sysadmins have both sufficient clue and motivation to care
> about your problems.  Remember that you have to get past the Level 1 tech
> support people, who probably don't have your problem on their script....

This at least I have some sympathy for - we've all had these phone calls - but
it doesn't rise to the level of making me think CSV is a bad idea that should
not be deployed.

Shutting down open relays forced a lot of people to change their email
practices. But does anyone still think keeping them open was viable?

				Ned

From: [email-masked]
Cc: [email-masked], [email-masked], David MacQuigg <[email-masked]>, John Leslie <[email-masked]>, [email-masked]
Date: Fri, 27 May 2005 09:43:39 -0700 (PDT)
Subject: Re: "Header Reordering", yet again
To: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

> [email-masked] writes:
> > Reordering fields of different types relative to each other is another
> > matter. Our MTA does this routinely - the facility we provide for
> > this is heavily used. The reason is that there are lots of things out
> > there which are order-sensitive in one way or another.

> Could you give a few examples?

Some versions of multiple products from a certain vendor in Redmond come to
mind...

> Why do your customers use this heavily?

Frankly, I have no idea why it is so popular. But customer desires and
requirements are often mysterious. Only yesterday we were dealing with someone
who insisted on all vCard attachments being stripped from messages unless we
could prove that there have never been any significant security holes
associated with them. Proving a negative is such fun...

> > Of course these things are broken, but when we're talking about
> > breakage in very popular systems saying they should behave this way
> > is a waste of time.

> Well, yes and no... I suppose expecting it to stop is futile, but
> talking about breakage may have other beneficial results. For a start,
> Bruce Lilly will post the URL to your elaboration next time we have the
> same thread ;)

With all due respect, when an important customer doesn't care whose fault it
really is, demands a workaround for a problem and is ready and willing to
switch to another product if the workaround isn't forthcoming, an engineer who
says "no" will find themselves needing to spend time updating their resume
rather than writing code.

				Ned

From: [email-masked]
Cc: [email-masked], David MacQuigg <[email-masked]>
Date: Fri, 27 May 2005 09:31:37 -0700 (PDT)
Subject: Re: "Header Reordering", yet again
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Fri May 27 2005 10:09, David MacQuigg wrote:

> > At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:

> > >Except for a few inconvenient facts:
> > >a) "It is important to note that the header fields are not guaranteed to
> > >    be in a particular order.  They may appear in any order, and they
> > >    have been known to be reordered occasionally when transported over
> > >    the Internet." RFC 2822, section 3.6
> >
> > Here is the complete quote:

> That doesn't change the fact that there is no guarantee, and that any
> assumption of a particular order is flawed.

> > Furthermore:
> >     """When an SMTP server

> Not all transport is via SMTP (while a given entity may use SMTP, there
> is no guarantee that *ALL* preceding "hops" in the store-and-forward
> transport chain used SMTP (nor, that *ALL* SMTP hops were conformant to
> RFC 2821, a Proposed Standard)).

Bingo. I hadn't considered it, but of course it is obvious that messages
passing through to, say, X.400 aren't going to preserve header order. (This in
spite of the fact that some of these system do have the ability to preserve
nonstandard fields - in the case of X.400 through the use of  a heading
extension.)

And the concept of being able to accomodate such systems goes way back -
there's discussion of some of the issues in RFC 821 and probably in earlier
specifications as well.

This could even result in reordering of trace fields in some cases, especially
if clocks are out of sync (which they often are). The mapping of trace fields
to X.400 in particular is pretty complicated.

> Moreover, specific exceptions are granted
> to gateways and MSAs, and there is no reliable way to determine if an SMTP
> receiver operating on port 25 is a gateway or MSA; there are no gateway- or
> MSA-sepcific response codes nor are there any ESMTP keywords that indicate
> to a client "this is a gateway" or "this is an MSA".

Nor is it clear what such codes would actually mean, let alone what a
client would do to accomodate something it didn't like.

> There is certainly
> no way that a subsequent analysis of the message can make any kind of
> reliable assessment of whether or not any receiver that putatively handled
> the message in transit was a gateway or MSA.

More precisely, there are times when you can tell a gateway was involved,
but there's no way to be sure one _wasn't_ involved.

> And by the time one has a message in a place where it can be examined, it
> might not even be in the Internet Message Format per se.  I am told (but
> have no independent confirmation) that systems such as Lotus Notes and
> Microsoft Exchange do not indicate (to applications accessing content
> for filtering) field order.

Any time some fields are mapped to a native format and others aren't
coordinating between the two is going to be impossible. Any X.400 system will
have this issue.

				Ned

Date: Fri, 27 May 2005 17:32:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Cc: [email-masked], David MacQuigg <[email-masked]>, John Leslie <[email-masked]>, [email-masked]
Sender: [email-masked]

[email-masked] writes:
> Reordering fields of different types relative to each other is another 
> matter. Our MTA does this routinely - the facility we provide for 
> this is heavily used. The reason is that there are lots of things out 
> there which are order-sensitive in one way or another.

Could you give a few examples? Why do your customers use this heavily?

> Of course these things are broken, but when we're talking about 
> breakage in very popular systems saying they should behave this way 
> is a waste of time.

Well, yes and no... I suppose expecting it to stop is futile, but 
talking about breakage may have other beneficial results. For a start, 
Bruce Lilly will post the URL to your elaboration next time we have the 
same thread ;)

Arnt

To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: "CSV" [not comma-separated values] 
From: [email-masked]
Date: Fri, 27 May 2005 11:26:19 -0400
Sender: [email-masked]

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

On Thu, 26 May 2005 18:52:54 BST, Tony Finch said:

> If a sender doesn't like their site's policies, they can get another ISP
> or have a chat with their sysadmins or whatever.

This makes 3 assumptions:

1) That the sender is even able to recognize that the breakage is due to the
site policy.

2) That there exists a *realistic* alternative ISP (you're always free to switch
to the *other* cable company for your broadband, right? ;)

3) That the sysadmins have both sufficient clue and motivation to care
about your problems.  Remember that you have to get past the Level 1 tech
support people, who probably don't have your problem on their script....

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

--==_Exmh_1117207579_6303P--

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Header Reordering", yet again
Date: Fri, 27 May 2005 11:15:14 -0400
Cc: David MacQuigg <[email-masked]>
Sender: [email-masked]

On Fri May 27 2005 10:09, David MacQuigg wrote:

> At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:

> >Except for a few inconvenient facts:
> >a) "It is important to note that the header fields are not guaranteed to
> >    be in a particular order.  They may appear in any order, and they
> >    have been known to be reordered occasionally when transported over
> >    the Internet." RFC 2822, section 3.6
> 
> Here is the complete quote:

That doesn't change the fact that there is no guarantee, and that any
assumption of a particular order is flawed.

> Furthermore:
>     """When an SMTP server

Not all transport is via SMTP (while a given entity may use SMTP, there
is no guarantee that *ALL* preceding "hops" in the store-and-forward
transport chain used SMTP (nor, that *ALL* SMTP hops were conformant to
RFC 2821, a Proposed Standard)).  Moreover, specific exceptions are granted
to gateways and MSAs, and there is no reliable way to determine if an SMTP
receiver operating on port 25 is a gateway or MSA; there are no gateway- or
MSA-sepcific response codes nor are there any ESMTP keywords that indicate
to a client "this is a gateway" or "this is an MSA".  There is certainly
no way that a subsequent analysis of the message can make any kind of
reliable assessment of whether or not any receiver that putatively handled
the message in transit was a gateway or MSA.

And by the time one has a message in a place where it can be examined, it
might not even be in the Internet Message Format per se.  I am told (but
have no independent confirmation) that systems such as Lotus Notes and
Microsoft Exchange do not indicate (to applications accessing content
for filtering) field order.

From: [email-masked]
Cc: [email-masked], John Leslie <[email-masked]>, wayne <[email-masked]>
Date: Fri, 27 May 2005 07:52:06 -0700 (PDT)
Subject: Re: "Header Reordering", yet again
To: David MacQuigg <[email-masked]>
Sender: [email-masked]

> Furthermore:
>     """When an SMTP server receives a message for delivery or further
>     processing, it MUST insert trace ("time stamp" or "Received")
>     information at the beginning of the message content, as discussed in
>     section 4.1.1.4.

>        <snip definition of line structure>

>     An Internet mail program MUST NOT change a Received: line that was
>     previously added to the message header.  SMTP servers MUST prepend
>     Received lines to messages; they MUST NOT change the order of
>     existing lines or insert Received lines in any other location.
>     """  RFC-2821, section 4.4 Trace Information.

> Seems to me any MTA that re-orders trace headers ought to be in category D
> - one notch below open relays.  They certainly won't be in my trust zone,
> and I don't see any way they can re-order headers above their last one.

> Can you give us an example of any forwarder that re-orders headers?  Other
> than hiding spammers, what would be the motive?

It depends on what you mean by "reorder". If you mean change the relative order
of fields of the same type, I don't believe I've ever seen that. I have,
however, seen lots of cases where headers, including trace headers, are
stripped of information or outright removed, usually due to fairly bogus
concerns about hiding details of network configurations, standards statements
to the contrary notwithstanding.

Reordering fields of different types relative to each other is another matter.
Our MTA does this routinely - the facility we provide for this is heavily used.
The reason is that there are lots of things out there which are order-sensitive
in one way or another. Of course these things are broken, but when we're
talking about breakage in very popular systems saying they should behave this
way is a waste of time.

> >b) it's easy to write "is a trace field", but that won't cause existing
> >    deployed MTAs to treat it any differently from any random extension
> >    field.

> Legitimate MTAs should leave existing headers alone.  Only the final MTA
> will be looking at the trace headers to determine the border MTA (the MTA
> on first entry to our trust zone).  The border MTA will attempt to
> authenticate the prior hop, and before that, we don't care.

The real world isn't this simple, and pretending otherwise isn't going to
change it.

				Ned

Date: Fri, 27 May 2005 07:09:46 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: "Header Reordering", yet again
Cc: John Leslie <[email-masked]>, wayne <[email-masked]>
Sender: [email-masked]

At 01:05 PM 5/23/2005 -0400, Bruce Lilly wrote:
>On Mon May 23 2005 10:30, John Leslie wrote:
> > wayne <[email-masked]> wrote:
> > >
> > > http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
> >
> > which includes:
>[...]
> > ]  The Received-SPF header is a trace field (see [RFC2822] section
> > ]  3.6.7) and SHOULD be prepended to existing headers, above the
> > ]  Received: header that is generated by the SMTP receiver.  It MUST
> > ]  appear above any other Received-SPF headers in the message.
> >
> > This is a very interesting idea, with some promise of enabling a
> > chain of trust.
>
>Except for a few inconvenient facts:
>a) "It is important to note that the header fields are not guaranteed to
>    be in a particular order.  They may appear in any order, and they
>    have been known to be reordered occasionally when transported over
>    the Internet." RFC 2822, section 3.6

Here is the complete quote:
    """It is important to note that the header fields are not guaranteed to
    be in a particular order.  They may appear in any order, and they
    have been known to be reordered occasionally when transported over
    the Internet.  However, for the purposes of this standard, header
    fields SHOULD NOT be reordered when a message is transported or
    transformed.  More importantly, the trace header fields and resent
    header fields MUST NOT be reordered, and SHOULD be kept in blocks
    prepended to the message.  See sections 3.6.6 and 3.6.7 for more
    information."""  RFC-2822, section 3.6.

Furthermore:
    """When an SMTP server receives a message for delivery or further
    processing, it MUST insert trace ("time stamp" or "Received")
    information at the beginning of the message content, as discussed in
    section 4.1.1.4.

       <snip definition of line structure>

    An Internet mail program MUST NOT change a Received: line that was
    previously added to the message header.  SMTP servers MUST prepend
    Received lines to messages; they MUST NOT change the order of
    existing lines or insert Received lines in any other location.
    """  RFC-2821, section 4.4 Trace Information.

Seems to me any MTA that re-orders trace headers ought to be in category D 
- one notch below open relays.  They certainly won't be in my trust zone, 
and I don't see any way they can re-order headers above their last one.

Can you give us an example of any forwarder that re-orders headers?  Other 
than hiding spammers, what would be the motive?

>b) it's easy to write "is a trace field", but that won't cause existing
>    deployed MTAs to treat it any differently from any random extension
>    field.

Legitimate MTAs should leave existing headers alone.  Only the final MTA 
will be looking at the trace headers to determine the border MTA (the MTA 
on first entry to our trust zone).  The border MTA will attempt to 
authenticate the prior hop, and before that, we don't care.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: [email-masked]
Cc: [email-masked]
Date: Thu, 26 May 2005 11:53:54 -0700 (PDT)
Subject: Re: "CSV" [not comma-separated values]
To: Tony Finch <[email-masked]>
Sender: [email-masked]

> On Thu, 26 May 2005, Bruce Lilly wrote:
> >
> > > your explanation has nothing to do with conflating sending and receiving.
> >
> > When a piece of software -- categorize it as you will -- connects to
> > an SMTP server and presents a domain name derived from a receiving
> > mailbox domain in EHLO/HELO, there is such conflation.  We might
> > tentatively agree that such software isn't operating according to
> > assumptions behind the rules of a twenty-year-old protocol, but the
> > present-day facts of life are such that in many cases there simply is
> > no other option available to such software.

> That's a problem with the sender's configuration, not with CSV. I do know
> of software that makes it impossible to fix this kind of configuration
> problem, but these email programs are designed to talk to an MSA, in which
> case the problem is moot. You claim that nevertheless it is still a
> problem because in general SMTP software doesn't know what role its peer
> is acting in, but again this is a fallacy because in a specific case the
> site's policy can disambiguate, and in fact this kind of disambiguation
> is routine in Internet email as a result of the open relay closure.

Exactly so. It seems some folks are confusing the absence of explicit
authorization information in SMTP-the-protocol with the inability to perform
authorization functions in SMTP-the-server. It has long been the case that a
viable SMTP server has to support authorization configuration, the more
flexible the better.

> In fact the issue of MTA vs. MSA vs. MUA etc. is at the wrong level and
> leads to irrelevant arguments about Internet email architecture. The LMAP
> protocols are all intended for use with SMTP over TCP across the public
> Internet routed according to RFC 974. They aren't for use within an
> organization because in that case other authentication and authorization
> mechanisms are more appropriate and more effective. They don't need to
> care about braindead MUA software because those SMTP implementations
> aren't designed for sending direct to MX.

RIght again, and continued attempts to stretch these things to apply to
MSA or delivery hops, be it in a misguided attempt to overgeneralize
the end to end principle or from a misunderstanding of real-world
architecture, need to stop.

> > > If such a sender wants to use CSV
> >
> > The problem is where the *sender* *doesn't* want to do so, but some
> > other party has decided to do so.

> If a sender doesn't like their site's policies, they can get another ISP
> or have a chat with their sysadmins or whatever.

Yup.

				Ned

Date: Thu, 26 May 2005 18:52:54 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: "CSV" [not comma-separated values]
Sender: [email-masked]

On Thu, 26 May 2005, Bruce Lilly wrote:
>
> > your explanation has nothing to do with conflating sending and receiving.
>
> When a piece of software -- categorize it as you will -- connects to
> an SMTP server and presents a domain name derived from a receiving
> mailbox domain in EHLO/HELO, there is such conflation.  We might
> tentatively agree that such software isn't operating according to
> assumptions behind the rules of a twenty-year-old protocol, but the
> present-day facts of life are such that in many cases there simply is
> no other option available to such software.

That's a problem with the sender's configuration, not with CSV. I do know
of software that makes it impossible to fix this kind of configuration
problem, but these email programs are designed to talk to an MSA, in which
case the problem is moot. You claim that nevertheless it is still a
problem because in general SMTP software doesn't know what role its peer
is acting in, but again this is a fallacy because in a specific case the
site's policy can disambiguate, and in fact this kind of disambiguation
is routine in Internet email as a result of the open relay closure.

In fact the issue of MTA vs. MSA vs. MUA etc. is at the wrong level and
leads to irrelevant arguments about Internet email architecture. The LMAP
protocols are all intended for use with SMTP over TCP across the public
Internet routed according to RFC 974. They aren't for use within an
organization because in that case other authentication and authorization
mechanisms are more appropriate and more effective. They don't need to
care about braindead MUA software because those SMTP implementations
aren't designed for sending direct to MX.

> > If such a sender wants to use CSV
>
> The problem is where the *sender* *doesn't* want to do so, but some
> other party has decided to do so.

If a sender doesn't like their site's policies, they can get another ISP
or have a chat with their sysadmins or whatever.

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: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "CSV" [not comma-separated values]
Date: Thu, 26 May 2005 13:16:19 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Thu May 26 2005 06:55, Tony Finch wrote:

> None of the LMAP proposals are applicable for MUA-MSA communication.

I didn't claim otherwise.  However some of those proposals refer to
indiscriminate use by all SMTP receivers (which obviously includes
MUA-MSA SMTP) and/or attempt to limit the scope to a subset, such as
MTA-MTA, where in fact neither client nor server has any reliable
means of determining whether its peer is an MUA, MSA, MTA, MDA,
telnet session, etc.

> As I 
> said before, you can't expect direct MUA-MX communication to work very
> well because of MUAs' simplistic SMTP implementations and because of MX's
> anti-spam strictness, and no common MUAs support direct-to-MX
> communication.

I'm not going to debate whether a particular piece of software is a
pure MUA, or incorporates elements of MSA or MTA.  Such distinctions
have a place, but they can also get in the way.  Clearly, in SMTP,
some SMTP client needs to connect to an MX server to deliver SMTP mail.
And as noted in a real-world example in another message today, that
sometimes needs to happen from an end-user's host.  Should be no
problem; SMTP requires no prior arrangement, and as noted above, there
is no reliable way for either party to a session's transaction to
determine the other's status as MSA, MTA, etc.

> So your objections are mistargeted, and what is more your 
> explanation has nothing to do with conflating sending and receiving.

When a piece of software -- categorize it as you will -- connects to
an SMTP server and presents a domain name derived from a receiving
mailbox domain in EHLO/HELO, there is such conflation.  We might
tentatively agree that such software isn't operating according to
assumptions behind the rules of a twenty-year-old protocol, but the
present-day facts of life are such that in many cases there simply is
no other option available to such software.
 
> If such a sender wants to use CSV

The problem is where the *sender* *doesn't* want to do so, but some
other party has decided to do so.

> > * I would add that the CSV draft fails to state *which* SRV record(s)
> > (service, protocol, etc.) to consult,
> 
> Incorrect. Section 5 of the CSA spec includes the SRV record specification
> template.

I was referring to draft-ietf-marid-csv-intro-02, which says "Query DNS
for a SRV record" with insufficient detail. [and don't bother pointing
to the references -- that provides only a vague reference to an unspecified
draft dated June 2004, which would have expired months ago]

> > Maybe. But contrary to RFC 2821 it says "A sending SMTP client MUST
> > supply a published domain name as the parameter to an SMTP HELO or EHLO.
> > [sic]".  2821 (and 821 before it) explicitly permits an address literal.
> > There is an (incorrect) assumption throughout the draft that EHLO/HELO
> > always entails a domain name.
> 
> You are making the fallacy of arguing from the general to the specific.

No, I'm commenting on the proposal as described by the draft as written.
That draft does not say "A sending SMTP client using TCP and supporting CSA"
or anything similar, nor is there an explicit scope-limiting section in
the draft.  Now it may very well be the case that that and other issues
mentioned above can be addressed -- but that would be some future version
of a draft, not the one under discussion.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Thu, 26 May 2005 12:27:14 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Thu May 26 2005 11:00, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > SPF and SPF-like schemes impose an additional necessary
> > condition:
> 
> > the ISP's MTA must work 100.00000% of the time
> 
> Not necesarily.  If you have your own domain (or a small
> domain shared by 15 users as in your example), then you
> can permit the IPs of several mail providers.

I think you may misunderstand the example and the problem. The
messages were sent to ~15 recipients, each with separate mailboxes
(think of it as list expansion) at different domains.  In order
to work around a problem *at the provider* (or at least *affecting
the provider*), it was necessary to go directly to a recipient's MX
host.  Your "solution", costs aside, supposes that at least one of
the providers is unaffected by the problem (the problem was something
like DNS poisoning, so that likely wouldn't help).
 
> In the most simple case you have providers A, B. C with
> policies and "v=spf1 include:A include:B include:C -all".

In your specific pet case of "misdirected bounces" (sorry, Markus),
if A, B, and/or C are large ISPs (think Comcast or RoadRunner),
such a scheme as you are proposing may in fact exacerbate the
problem.

> And I have mailboxes at both A and B.  So when I now have a
> problem with A I simply send the mail via B, just using the
> corresponding MAIL FROM:<[email-masked]>

That's OK for you, assuming that's where you *want* to receive
delivery notifications.  That might not work for others.  And
it won't work at all if you specifically want to delegate handling
of delivery notifications.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Thu, 26 May 2005 17:00:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 46
Sender: [email-masked]

Bruce Lilly wrote:

> SPF and SPF-like schemes impose an additional necessary
> condition:

> the ISP's MTA must work 100.00000% of the time

Not necesarily.  If you have your own domain (or a small
domain shared by 15 users as in your example), then you
can permit the IPs of several mail providers.

In the most simple case you have providers A, B. C with
policies and "v=spf1 include:A include:B include:C -all".

If C doesn't offer a SPF policy for inclusion you could
still try to guess the CIDR(s) used by its mailouts, or
again in the most simple case you just know what C does:

"v=spf1 include:A include:B mx:C a:mailout.C -all"

> In the presence of schemes which thwart such work-arounds
> by forcing traffic through a choke point, that choke point
> needs to work perfectly, no matter what

Admittedly I'm a user with a single choke point.  OTOH it's
what I wanted and proposed ;-)  Catch-all vanity domains are
a really nice idea, but less so if they are forged.

SPF also allows to create per-user policies, but that's a
premium service not available at my ISP.

The reality is, even before SPF I needed more than one mail
provider to bypass problems like dubious black listings.

And I have mailboxes at both A and B.  So when I now have a
problem with A I simply send the mail via B, just using the
corresponding MAIL FROM:<[email-masked]>

Anything else (2822-From [email-masked]) unmodified.
No big deal.

JFTR, it won't work this way with SenderID PRA, but that's a
very different scheme, only the spf2.0/pra syntax is similar.

                       Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Envelope", yet again
Date: Thu, 26 May 2005 11:05:52 -0400
Cc: John C Klensin <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 22:49, John C Klensin wrote:
> 
> --On Tuesday, 24 May, 2005 12:25 -0400 Bruce Lilly
> <[email-masked]> wrote:
> 
> >>    Were we starting from scratch [...]
> > 
> > Well, John's draft expired in July 2004, so we might as well,
> > as it appears that the idea lacked traction.
> 
> Bruce, my impression of John Leslie's note was that, when he
> made the comment above, he was talking about "starting from
> scratch" as a redesign/replacement of the SMTP, and
> SMTP-compatible, mail environment.

John, that wasn't my impression (maybe we have a failure to
communicate), nor was my alternate suggestion in any way "a
redesign/replacement ...".  Indeed, it's independent of SMTP.

> The draft to which you refer 
> was an attempt to explore whether or not we could separate,
> _within_ the SMTP environment, all of the information supplied
> or used by the MTA from that used in MUA-MUA or user-user
> communication.

As was my thumbnail sketch.

> It was motivated by some internationalization 
> considerations, not spam.

I hope we're talking about the same draft. draft-klensin-email-envelope-00
talks about signing, anti-spam, and internationalization.  My
brief sketch of a scheme that does not involve an SMTP extension
was based on the concept already documented for S/MIME "triple-
wrapping" (RFCs 2633,3851), which explicitly provides for signing and
encrypting message content, including the originator header fields,
which are protected from transport by a MIME wrapper.  Transport
can put its markings in the header of that wrapper, rearrange field
order, slice, dice, bend, fold, spindle, and otherwise mutilate that
wrapper's header without invalidating the (encrypted and/or signed)
originator's content. 

> And, as you may have noticed, the 
> whole email address internationalization effort lost traction.

That wasn't a consideration in my discussion.  It's really
orthogonal to the discussion, I think.

> I don't think you should draw the inference from the fact that I
> haven't pursued that draft any further that it is time to start
> redesigning Internet mail from scratch.

I didn't.

> It may well be that 
> time, and there may be far better reasons, but, as always, good
> luck getting it deployed.

Wholehearted agreement.
 
> > Believe it or not, there is a reason that components are
> > separated into "envelope", "header", and "body", and why the
> > application is called "electronic mail" and not "electronic
> > foo".  The header and body are part of user-to-user
> > communication (as with non-electronic mail) and the envelope
> > is where various markings pertaining to transport, filing, etc.
> > of unopened messages are placed.
> 
> And, as always, the model is fuzzy at the edges.  Design
> decisions made even before 822 create a difference between
> MUA-MUA information and user-user information, a distinction
> that does not exist in traditional paper mail.

Perhaps -- a secretary or some mechanical aid make take the place
of an MUA in the paper world.

> We have also 
> always had an ambiguity about what end-to-end means with
> Internet mail, an ambiguity that got worse when "delivery to
> user's mailbox" was replaced in many environments with "delivery
> to mail store" or "delivery to storage agent".

I'm not sure I see the distinction.  Whether delivery is to a
flat file (/bin/mail model) or to a more complicated structure
(e.g. an IMAP message store), it seems that delivery can be said to
occur at some point, and access by a UA may occur at any subsequent
time (or maybe never).  I do see a difference from simpler, direct-
connect days to the present case, where "final" delivery to a POP,
IMAP, etc. message store at an ISP's site may be followed by retrieval
and reprocessing for "local" storage, rerouting, etc.

Indeed, it is in large part due to the changes that have occurred that
many of the anti-spam schemes are unreliable and may cause damage (in
particular, the assumptions that HELO/EHLO parameters are always
domain names and/or are always meaningful).

> To take just 
> one handy example, do you think Message-ID and In-Reply-To are
> part of user-to-user communication or information about
> "transport, filing, etc."?  I think the answer is "maybe", and
> that it gets even worse if the MSA  or post-MSA processors
> attempt to do message threading in the mail store.

I would lean toward user-to-user (analogous to "in response to
your letter of 28 February...") with the understanding that
rather than being *directly* generated or used by the end-users,
in either case the annotation may be generated and/or used by an
assistant (MUA or secretary).  It's information related to the
message per se rather than transport/routing markings.

A more nebulous case would be the proposed "Archived-At" field. I
suspect that what is desirable is separate "bundles" of information
within a generic "message": here's the body content, here's the
originator header information, here's a package of transport markings,
here's some list-related stuff, etc..  And I think that can be achieved
within the MIME framework without making changes to SMTP or other
pure transport mechanisms (mailing lists which do add annotations
might need to place those in a MIME container of some sort added
to original content -- indeed, some lists might wish to separately
sign and/or encrypt what they add, with some assurance that the
signatures would survive subsequent transport).
  
> And, in the real world of
> email operations, believing that message IDs are really
> invariant borders on the inexperienced if not delusional.

It's unclear what you're getting at; can you give more specifics
or an example?

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Thu, 26 May 2005 10:13:07 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Thu May 26 2005 00:00, Robert A. Rosenberg wrote:

> must be a way to supply the relaying MTA with the message.

should be obvious -- if a relay is used.  In general, there
has to be a reliable path to recipients' MX hosts, either directly
or via relays.

> there must be a way to establish the connection to 
> a MSA at the Domain Owning ISP.

that presumes that a particular MSA (or MTA) is always used,
which isn't a universal condition.

>   3) Since some Connectivity Provider ISPs prevent this connection 
> occurring via Port25, some other port must be used when getting 
> connectivity from such a provider.

That's a direct consequence of port 25 blocking, largely independent
of other considerations.
 
No question that if SPF is used it presents obstacles that need to
be worked around.  Your conditions therefore are necessary, given
the stated auxiliary conditions, but are not always sufficient.  For
example, a few years ago I was managing a small (~15 recipients)
mailing list.  The typical case was to send one instance of each
distinct message to an ISP's MTA with the recipient list (primarily
because the connection was a dialup link).  However, at various times,
there were problems with a couple of recipients -- in one case the ISP
was getting (or asserting) bogus NXDOMAIN and was bouncing messages,
and to work around that, it was necessary to send a separate copy to
the designated MX host for the recipient domain, which worked fine.
In theory, that sort of problem shouldn't happen -- in practice it
does, and SPF and SPF-like schemes impose an additional necessary
condition:

the ISP's MTA must work 100.00000% of the time, even when there are
foul-ups in DNS records (I seem to recall a rather large domain name
which was "hijacked" about six months ago, Robert, you might recall
something about that).  Without SPF-like schemes, it's possible to
work around problems such as the case noted in the previous paragraph.
In the presence of schemes which thwart such work-arounds by forcing
traffic through a choke point, that choke point needs to work
perfectly, no matter what, with no more end-user effort or time than
work-arounds would take (~1 minute -- in particular it can't depend
on a several-hour wait to talk to an ISP "tech support" person who is
clueless about mail routing, and that's the unfortunate reality).
While we'd all like to "kill" spam, collateral damage to legitimate
mail traffic -- for mobile users, for working around problems, etc. --
is simply unacceptable.

Date: Thu, 26 May 2005 14:49:44 +0100
From: Tony Finch <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Sender: [email-masked]

On Thu, 26 May 2005, Frank Ellermann wrote:
>
> If a "reader understands the master zone file format", as
> Tony said, then he will manage to publish something like
> a simple "v=spf1 a -all" for host names used in a HELO.

Specifications are not user guides :-)

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: Frank Ellermann <[email-masked]>
Subject:  Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Date:  Thu, 26 May 2005 15:13:57 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 36
Sender: [email-masked]

Dave Crocker wrote:

Quote <[email-masked]>:
>> Draft section 2.1.3 refers to a "new message" several times
[...]

Unquote <[email-masked]>
>> It seems to me the fundamental advantage of CSV over SPF
>> is that CSV doesn't try to associate domain names with IP
>> addresses outside of that domain.

Maybe use "|" instead of ">", it took me some time to find
that that's nothing what Bruce said.

> SPF is strictly focussed on per-message behavior

It has also HELO checking.  Not as elaborated as the CSV
strategy to find a parent domain, and it allows policies
which are *_much_* too complex for this simple purpose.

If a "reader understands the master zone file format", as
Tony said, then he will manage to publish something like
a simple "v=spf1 a -all" for host names used in a HELO.

Trying to test CSV before SPF for this purpose (HELO) is
better assuming roughly the same deployment.

> does not provide a means of assessing aggregate MTA
> operations.

Creating white or black lists for PASS results is also
possible for HELO PASS results.  The main advantage of
SPF is that it allows to reject forgeries at the MX.

                         Bye, Frank

Date: Thu, 26 May 2005 11:55:51 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: "CSV" [not comma-separated values]
Sender: [email-masked]

On Wed, 25 May 2005, Bruce Lilly wrote:
> On Wed May 25 2005 13:46, Tony Finch wrote:
>
> > You'll have to explain how CSV conflates sending and receiving,
>
> As noted in the SPF discussion, MUA EHLO/HELO names are often extracted
> from return path information and are frequently not configurable.

None of the LMAP proposals are applicable for MUA-MSA communication. As I
said before, you can't expect direct MUA-MX communication to work very
well because of MUAs' simplistic SMTP implementations and because of MX's
anti-spam strictness, and no common MUAs support direct-to-MX
communication. So your objections are mistargeted, and what is more your
explanation has nothing to do with conflating sending and receiving.

Some of your following comments also seem to assume that the sender is an
MUA. I'll address them anyway, even though this is somewhat redundant.

> > and why tying an IP address to a hostname is a problem.
>
> [unstable sender IP addresses]

If such a sender wants to use CSV then they can use dynamic DNS updates
and low TTLs. But in practice outgoing MTAs have stable IP addresses so
this isn't a problem for the vast majority of sites.

> > Transports other than
> > TCP are not a problem because CSV isn't applicable to them.
>
> The csv draft doesn't say so.  It *does* say "each SMTP session" and
> "Obtain the remote IP address of the TCP connection".

Therefore it's obvious that if there's no TCP connection then CSV isn't
applicable. But I suppose it could be made explicit for readers who can't
draw implications.

> > CSV isn't mandatory and it falls back gracefully if the sending site
> > hasn't deployed it.
>
> You'll have to explain what you mean by "deployed" w.r.t. "sending site".

I use the term "site" somewhat informally to mean some computing
infrastructure and its users, all operating according to some
computing policies which may be stricter than is required by Internet
Standards. So if a site has deployed some technology one would expect them
to have informed their users how to use the technology effectively (e.g.
how to configure clients for use at that site) and what site policies
apply to that technology.

For example, if a site deploys CSV then its mobile end-users will probably
be subject to policies saying that their software should use an
appropriate host name in HELO for sending email, or that they should use
TLS+AUTH+RFC2476 for remote message submission.

> * I would add that the CSV draft fails to state *which* SRV record(s)
> (service, protocol, etc.) to consult,

Incorrect. Section 5 of the CSA spec includes the SRV record specification
template.

> and the SRV RFC (2782) is rather opaque (e.g. the syntax specified
> begins with _Service._Proto.Name TTL Class but the example seems to
> be missing Name, TTL, and Class

It assumes that the reader understands the master zone file format, which
is reasonable for a DNS RFC.

> > It doesn't try to force people to fix their MTAs that state
> > invalid hostnames in their HELO commands.
>
> Maybe. But contrary to RFC 2821 it says "A sending SMTP client MUST
> supply a published domain name as the parameter to an SMTP HELO or EHLO.
> [sic]".  2821 (and 821 before it) explicitly permits an address literal.
> There is an (incorrect) assumption throughout the draft that EHLO/HELO
> always entails a domain name.

You are making the fallacy of arguing from the general to the specific.
Something that is not true in general may certainly be true in specific
circumstances: in this case the specific circumstance is an SMTP client
that supports CSA.

However I have proposed an extension to CSA which specifies how to put CSA
SRV records in the reverse DNS, so that they can be used with clients that
state an address literal after HELO or which do not say HELO at all.

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: Dave Crocker <[email-masked]>
To: <[email-masked]>
CC: ietf-smtp <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Wed, 25 May 2005 18:18:31 +0200
Delivery-Date: Wed, 25 May 2005 18:18:31 -0000
Subject: Re: message-identifiers vs. "new message" in draft-crocker-email-arch-04.txt
Sender: [email-masked]

>  Draft section 2.1.3 refers to a "new message" several times, and states
>  that list expanders provide an example.  But list expanders do not
>  generally elide/replace message-ids, and therefore -- using standard
>  terminology from the core email RFCs -- there is in fact no "new message";
>  a list expander redistributes the *same* message (with unchanged message-
>  id).

In trying to create a description of the current architecture, there is a 
balancing act between making the document strictly reflect "

>  It seems to me the fundamental advantage of CSV over SPF is that CSV
>  doesn't try to associate domain names with IP addresses outside of that
>  domain.

The fundamental advantage(S) are that: 

a) CSV uses an identity related to direct, local MTA operations, rather than 
referring back some unknown number of hops to a content author who has no 
involvement in the operation of the MTA, and

b) CSV is simple.  Extremely simple.  It took an enormous amount of effort to 
make it this simple...

The focus on MTA operations ID is not a minor matter.  One small example of 
the benefit is that operations folk can focus on aggregate behavior, across 
many messages, many message authors, and many (possibly compromised) machines. 
 SPF is strictly focussed on per-message behavior and does not provide a means 
of assessing aggregate MTA operations.

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

Date: Thu, 26 May 2005 00:00:58 -0400
To: <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

At 16:17 -0400 on 05/25/2005, Hector Santos wrote about Re: SPF I-D 
for review: draft-schlitt-spf-classic-01.txt:

>Robert,
>
>The whole purpose of the LMAP protocols is to help close the SMTP loophole -
>AKA the massive exploitation of Anonymous Final Destination Transactions.
>
>[snip]
>
>----- Original Message -----
>From: "Robert A. Rosenberg" <[email-masked]>
>To: <[email-masked]>
>Sent: Wednesday, May 25, 2005 3:13 PM
>Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
>
>  >
>>  One other GOTCHA about deploying SPF - If you publish SPF records
>>  authorizing ONLY SMTP Servers under your Control (ie: Email with a
>>   From of *@ISP1 must come from an ISP1 SMTP Server), those SMTP
>>  Servers MUST run their MSA (Mail Submission Agent) functions not only
>>  on Port 25 but on at least one Non-Port25 Port (preferably the
>>  OFFICIAL MSA Port587 [with SMTP AUTH] and hopefully also as an
>>  SMTP-over-SSL Connection on Port465).
>>
>>  Failure to accept submitted email from Mail Clients on a port other
>>  than Port25 raises a Catch-22 Situation when trying to connect
>>  remotely from a Port25-Blocking (or Hijacking [ie: One who ignores
>>  the Requested Server Address and forces the Port25 Session to a
>>  dedicated SMTP Server]) Connectivity Provider. If you use the
>>  Connectivity Provider's Server SPF breaks but the SPF Publishing ISP
>>  provides no way to access their Server (and thus observe the SPF
>  > Origin Restrictions) on a Non-Port25 Port.

Maybe I am being dense but I fail to see what relevance your comments 
(which I snipped) had/have to do with my observation as quoted above.

To restate the observation logically:

  1) Given an suggestion (via the publication of SPF Records) that SPF 
be used to allow a receiving MTA to verify that a message being 
relayed to it is being relayed by a MTA that is authorized by the 
Owner of the Domain whose message it is to do such relaying, there 
must be a way to supply the relaying MTA with the message.

  2) Since the attempt to supply/submit such messages may be being 
done via a connection from a ISP other than the one responsible for 
the Relaying MTA, there must be a way to establish the connection to 
a MSA at the Domain Owning ISP.

  3) Since some Connectivity Provider ISPs prevent this connection 
occurring via Port25, some other port must be used when getting 
connectivity from such a provider.

Conclusion: To insure that the SPF Rules can be observed, the MSA 
which is to be contacted so it can accept the message submission and 
thus relay the message (either by the MSA SMTP Server acting as the 
relaying MTA or by an MTA that the MSA has handed to message off to) 
must be monitoring a Non-Port25 port. This is to handle connections 
that occur from ISPs who refuse to allow the connection to occur over 
Port25.

What disagreement (if any) do you have with this scenario? Note that 
I am NOT addressing if SPF is a good idea (or will work). I am taking 
its deployment and operation as a given and stating requirements that 
should be in place for it to function as it is designed to operate.

Date: Wed, 25 May 2005 22:49:36 -0400
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: Re: "Envelope", yet again
Sender: [email-masked]

--On Tuesday, 24 May, 2005 12:25 -0400 Bruce Lilly
<[email-masked]> wrote:

>>    Were we starting from scratch [...]
> 
> Well, John's draft expired in July 2004, so we might as well,
> as it appears that the idea lacked traction.

Bruce, my impression of John Leslie's note was that, when he
made the comment above, he was talking about "starting from
scratch" as a redesign/replacement of the SMTP, and
SMTP-compatible, mail environment.  The draft to which you refer
was an attempt to explore whether or not we could separate,
_within_ the SMTP environment, all of the information supplied
or used by the MTA from that used in MUA-MUA or user-user
communication.   It was motivated by some internationalization
considerations, not spam.  And, as you may have noticed, the
whole email address internationalization effort lost traction.
IMO, that occurred both because it was hard and because the
folks who seems to dominate these discussions, posting tens of
messages a day or more, appear to be more interested in spam and
nit-picking than in such broader and, IMO, ultimately more
important, issues as address internationalization.

I don't think you should draw the inference from the fact that I
haven't pursued that draft any further that it is time to start
redesigning Internet mail from scratch.  It may well be that
time, and there may be far better reasons, but, as always, good
luck getting it deployed.

>> >> So, my first question to the group is, "Is there anything
>> >> beyond SMTP commands and trace headers (however defined)
>> >> that we want to be included when we talk of "envelope
>> >> information"?
>> > 
>> > Everything that isn't end-to-end, user-to-user
>> > communication.
>> 
>>    That definition is facile, but I don't find it useful.
>>    (You prove my point about vagueness, BTW.)
> 
> Believe it or not, there is a reason that components are
> separated into "envelope", "header", and "body", and why the
> application is called "electronic mail" and not "electronic
> foo".  The header and body are part of user-to-user
> communication (as with non-electronic mail) and the envelope
> is where various markings pertaining to transport, filing, etc.
> of unopened messages are placed.

And, as always, the model is fuzzy at the edges.  Design
decisions made even before 822 create a difference between
MUA-MUA information and user-user information, a distinction
that does not exist in traditional paper mail.  We have also
always had an ambiguity about what end-to-end means with
Internet mail, an ambiguity that got worse when "delivery to
user's mailbox" was replaced in many environments with "delivery
to mail store" or "delivery to storage agent".   To take just
one handy example, do you think Message-ID and In-Reply-To are
part of user-to-user communication or information about
"transport, filing, etc."?  I think the answer is "maybe", and
that it gets even worse if the MSA  or post-MSA processors
attempt to do message threading in the mail store.

>>    I believe there's rough consensus that a MailingList
>>    "re-inserts" messages,
> 
> To the extent that any other part of the store-and-forward
> transport process also does so.  The message (as indicated by
> invariant message identifier) is the same message (RFC 2822
> section 3.6.4).
> 
>> and that List-* fields are meaningful for list management -- 
>> at both the sending and receiving end.
> 
> Yes, in the same way that routing or filing instructions,
> postmarks, etc. are meaningful on physical mail envelopes.

Similar comments to those above apply to List-* fields, etc.,
especially with List managers/ exploders which try to be as
low-impact as possible with regard to the message body headers,
as we generally try to recommend.  And, in the real world of
email operations, believing that message IDs are really
invariant borders on the inexperienced if not delusional.

      john

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 16:17:53 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Robert,

The whole purpose of the LMAP protocols is to help close the SMTP loophole -
AKA the massive exploitation of Anonymous Final Destination Transactions.

We don't need email auth proposals for routed transactions and/or
transactions which are authenticated/authorized or validated via traditional
means, namely,  Allow IP Relay tables, ESMTP AUTH, POP B4 SMTP or SUBMIT
which is basically just an ESMTP AUTH enforcement protocol.

This is for one reason - maximizing backward compatibility.

In short, SPF or LMAP systems are not a "replacement" for  BCP methods
traditionally in place for the past score of years.

With that said, I understand there is a "consideration" (opinions injected
into the discussion stream) to use the new proposals for MUA/MSA
authenticated sessions as well.

In my technical view, this goes against the backward compatibility aspect of
SMTP BCP and thus will have more problems being adopted if only from one
standpoint - the current SOFTWARE in place is designed around the black and
white SMTP BCP methods for authentication.  It is not designed around "fuzzy
or grey" concepts.   This is very important.   You better have something
solid if we are going to be adding or replacing current MTA relay
authorization protocols.

PS:  For over 1.5 years now, we have SPF implemented as part of a suite of
other anonymous sender verification methods lumped together as WCSAP
(Wildcat! Sender Authentication Protocols).  WCSAP is only triggered for
anonymous transactions and only after the RCPT is determined per RFC 2821
recommendation:

RFC 2821 - 3.3 Mail Transactions

    .....

   .............  Despite the apparent
   scope of this requirement, there are circumstances in which the
   acceptability of the reverse-path may not be determined until one or
   more forward-paths (in RCPT commands) can be examined.  In those
   cases, the server MAY reasonably accept the reverse-path (with a 250
   reply) and then report problems after the forward-paths are received
   and examined.  Normally, failures produce 550 or 553 replies.

This delay verification saves an average of 65% in WCSAP DNS-based
verification overhead.

----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats  (WcSAP Anti-Spam Stats)

----- Original Message -----
From: "Robert A. Rosenberg" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 25, 2005 3:13 PM
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt

>
> One other GOTCHA about deploying SPF - If you publish SPF records
> authorizing ONLY SMTP Servers under your Control (ie: Email with a
>  From of *@ISP1 must come from an ISP1 SMTP Server), those SMTP
> Servers MUST run their MSA (Mail Submission Agent) functions not only
> on Port 25 but on at least one Non-Port25 Port (preferably the
> OFFICIAL MSA Port587 [with SMTP AUTH] and hopefully also as an
> SMTP-over-SSL Connection on Port465).
>
> Failure to accept submitted email from Mail Clients on a port other
> than Port25 raises a Catch-22 Situation when trying to connect
> remotely from a Port25-Blocking (or Hijacking [ie: One who ignores
> the Requested Server Address and forces the Port25 Session to a
> dedicated SMTP Server]) Connectivity Provider. If you use the
> Connectivity Provider's Server SPF breaks but the SPF Publishing ISP
> provides no way to access their Server (and thus observe the SPF
> Origin Restrictions) on a Non-Port25 Port.
>
>

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 14:58:03 -0500
Lines: 40
Cancel-Lock: sha1:FYgJhePtnkiCgJCyGMl2SSvGIb4=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Wed May 25 2005 09:11, wayne wrote:
>> 
>> 
>> There are plenty of places will do the mail hosting for you.  For
>> example, Godaddy lets you register a domain name for $9/yr, and lets
>> you do email for $10/yr.  They also have a free email option, which
>> will likely be good enough for many people.
>
> No.  First, there is no "free email option".

Yeah, you are right.  The "free email option" that I noticed is for
people who have webhosting with GoDaddy also.  I confess that I didn't
investigate it closely, I just noticed it when I was doing some domain
registration stuff.

>                                               Second, the "$10/yr"
> option provides 1 mailbox per domain, which isn't going to be terribly
> useful unless the local-part is specified as "postmaster" as required
> by the Hosts Requirements Standard (and the implementation had better
> treat that local-part as case-insensitive), or is a "catch-all" (in
> which case it will catch a great deal of dictionary-attack spam).

There are many other email service providers out there.  I suggest you
go look at all the options.

> More important, you are still conflating *receipt* of email with the
> independent action of *sending* email.

Uh, no I'm not.

Yeah, I can hear it now "yes you are!"  "no I'm not!"

bah.  I have more productive things to do.

-wayne

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 21:52:54 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Sender: [email-masked]

Robert A. Rosenberg wrote:

> Failure to accept submitted email from Mail Clients on a port
> other than Port25 raises a Catch-22 Situation when trying to
> connect remotely from a Port25-Blocking (or Hijacking
[...]
> Connectivity Provider.

Yes, that's addressed in draft-hutzler-spamops-04.txt and IIRC
also in 2476bis.  The SPF I-D has 2476bis in its references.

Adding draft-hutzler-spamops-04 to the references is an option,
but I prefer the existing explanation in 10.4 of the SPF I-D.

Personally I consider block-port-25 schemes as a folly and a
feeble attempt to cure the symptoms of gross negligence on the
side of say "spamcast".  It's unrelated to SMTP and SPF, it's
of course possible to send SPF-protected mails from a dyn. IP.

                      Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: "CSV" [not comma-separated values]
Date: Wed, 25 May 2005 15:41:47 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 13:46, Tony Finch wrote:

> You'll have to explain how CSV conflates sending and receiving,

As noted in the SPF discussion, MUA EHLO/HELO names are often extracted
from return path information and are frequently not configurable.  I'm
not talking about obscure products, I'm referring to several of the most
widely used MUAs.

> and why 
> tying an IP address to a hostname is a problem.

It's a matter of context; it's fine for MX, because a sender needs to be
able to determine where to send, and the receiver needs to be prepared
to receive mail.  That does not apply to sending, because a sender requires
no such preparation, and as the sender initiates a connection (N.B. with
no prior arrangement required), the receiver doesn't need to be able to
"find" the sender.  A receiver needs to have a reasonably stable IP address
(at least w.r.t. to DNS TTLs), whereas a sender needs not.  A given sender
might have one IP address now and (e.g. via DHCP or a different physical
connection) have a different IP address a minute, an hour, etc. from now.
It's not unlike a face-to-face meeting at home; somebody wishing to contact
me at home needs an address to be able to do so -- upon knocking on the door,
I answer and the communications begins.  I don't need to be able to know
where to find the initiator; he comes knocking.  He may approach from one
direction today and another tomorrow -- that's irrelevant.

> Transports other than
> TCP are not a problem because CSV isn't applicable to them.

The csv draft doesn't say so.  It *does* say "each SMTP session" and
"Obtain the remote IP address of the TCP connection".

> CSV isn't 
> mandatory and it falls back gracefully if the sending site hasn't
> deployed it.

You'll have to explain what you mean by "deployed" w.r.t. "sending site".
I see things like "independent accreditation services", and "domain",
and "SRV record" [*] etc. none of which are likely to be under the control
of a typical mobile end-user email sender.

> It doesn't try to force people to fix their MTAs that state 
> invalid hostnames in their HELO commands.

Maybe. But contrary to RFC 2821 it says "A sending SMTP client MUST
supply a published domain name as the parameter to an SMTP HELO or EHLO.
[sic]".  2821 (and 821 before it) explicitly permits an address literal.
There is an (incorrect) assumption throughout the draft that EHLO/HELO
always entails a domain name.

* I would add that the CSV draft fails to state *which* SRV record(s)
(service, protocol, etc.) to consult, how to handle timeouts, etc.,
and the SRV RFC (2782) is rather opaque (e.g. the syntax specified
begins with _Service._Proto.Name TTL Class but the example seems to
be missing Name, TTL, and Class -- in spite of the curious remark that
"the example near the end shows this clearly" (perhaps the example should
use fewer defaults or clearly indicate field delimiters)).

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 21:13:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 23
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> I suspect that every few weeks, they just pick a new victim. 

Yes, I've read reports about this pattern on danam (the German
counterpart of nanae minus trolls) in 2004.  But in my case
the "few weeks" were almost exactly six months.  And I didn't
get any further backscatter since it stopped.

About 100 Sober-Q last week, the author of this beast didn't
bother to avoid SPF-protected addresses.  But that's nothing
against the 250,000 backsatter mails I did _not_ get after it
stopped.  Or the 150,000 before.  With my modem account I care
about these "peanuts".

Maybe some Sober-Q FAIL results for my forged addresses helped
to block / report the infected systems faster, the worm author
reads danam, he will be delighted by my "technical tips for a
successful worm author".
                        Sigh, bye, Frank

<http://www1.ietf.org/mail-archive/web/asrg/current/msg11172.html>

Date: Wed, 25 May 2005 14:48:16 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

At 07:05 -0400 on 05/25/2005, Bruce Lilly wrote about Re: SPF I-D for 
review: draft-schlitt-spf-classic-01.txt:

>On Wed May 25 2005 00:57, Robert A. Rosenberg wrote:
>>
>>  and you are using an SPF Approved/Authorized
>  > Submission/Relaying Server. If you are not allowed to use that
>  > Server (due to SMTP Connection Hijacking on the part of the
>>  Connectivity Provider then you are out of luck - You should send from
>>  your Laptop via an Ethernet/WiFi connection).
>
>If port blocking is in effect, that won't help.   That problem exacerbated
>by SPF is one of the reasons SPF is harmful to Internet mail.

Deploying SPF (especially when requiring all email to be relayed by 
your Servers) should go hand-in-hand with having Non-Port25 Ports on 
the Servers (such as both MSA Port587 [SMTP AUTH Protected] and 
SMTP-over-SSL Port465). Requiring that your Server only be contacted 
on Port25 is (as you note) asking for problems (and a Catch-22 
Situation) given the Existence of Connectivity Providers who 
Block(ie: Refuse to make the connection) and/or Hijack (ie: Force 
connect to their Servers) Port25 Requests to Remote Hosts.

Date: Wed, 25 May 2005 15:13:06 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

At 00:38 -0500 on 05/25/2005, wayne wrote about Re: SPF I-D for 
review: draft-schlitt-spf-classic-01.txt:

>In <[email-masked]> Bruce Lilly 
><[email-masked]> writes:
>
>>  On Tue May 24 2005 13:05, Frank Ellermann wrote:
>>>  > That's at the heart of the problem -- it attempts to define
>>>  > a set which makes no sense; worse than that, it is harmful.
>>>
>>>  It does not _attempt_ to define this set, it only _allows_
>>>  to define this set.
>>
>>  But as the sender of mail, and the person affected, it doesn't
>>  allow *ME* to do so.  If -- in a fit of stupidity -- somebody at
>>  the ISP where I *receive* mail were to do so, I would either be
>>  forced to use a null return path (breaking the intended function
>>  of delivery notifications, as noted by Markus), or I would drop
>>  that ISP like a hot potato and find one with more sense.
>
>I'm a strong believer in "their server, their rules", and also "the
>domain owner's domain, their rules".  If your ISP does anything you
>really don't like, I complete agree that you should switch.  For only
>a few bucks a year, you can also buy your own domain name and then you
>can set the rules for the domain you use.
>
>
>-wayne

One other GOTCHA about deploying SPF - If you publish SPF records 
authorizing ONLY SMTP Servers under your Control (ie: Email with a 
 From of *@ISP1 must come from an ISP1 SMTP Server), those SMTP 
Servers MUST run their MSA (Mail Submission Agent) functions not only 
on Port 25 but on at least one Non-Port25 Port (preferably the 
OFFICIAL MSA Port587 [with SMTP AUTH] and hopefully also as an 
SMTP-over-SSL Connection on Port465).

Failure to accept submitted email from Mail Clients on a port other 
than Port25 raises a Catch-22 Situation when trying to connect 
remotely from a Port25-Blocking (or Hijacking [ie: One who ignores 
the Requested Server Address and forces the Port25 Session to a 
dedicated SMTP Server]) Connectivity Provider. If you use the 
Connectivity Provider's Server SPF breaks but the SPF Publishing ISP 
provides no way to access their Server (and thus observe the SPF 
Origin Restrictions) on a Non-Port25 Port.

To: [email-masked]
From: wayne <[email-masked]>
Subject:  LMAP systems
Date:  Wed, 25 May 2005 13:41:43 -0500
Lines: 31
Cancel-Lock: sha1:OLsI9BOd8ig0/sDZ4ogAsgyevOk=
Sender: [email-masked]

In <[email-masked]> Tony Finch <[email-masked]> writes:

> On Wed, 25 May 2005, Bruce Lilly wrote:
>
>> All apply (conflating sending/receiving, failure to account for SMTP
>> with mechanisms other than TCP, attempts to assign IP/domain relationship
>> for sending), and there was also "etc." which you conveniently failed to
>> quote, and that covers a slew of practical problems with EHLO/HELO.
>
> You'll have to explain how CSV conflates sending and receiving, and why
> tying an IP address to a hostname is a problem. Perhaps you think CSV has
> something to do with mail domains? (It does not.)

I don't think Bruce really understands CSV.  For that matter, he
doesn't appear to really understand SPF, MTAMark, or SenderID either.

Frank was right.  SPF, CSV, and MTAMark all do different things.  The
closest two are the SPF HELO checking and CSV, but even those two have
different semantics for certain key issues.

What they all have in common is that they all allow people to have a
voice on some email-related issue, and they all allow email receivers
to listen.  All are option for publishing, and optional for checking.
None of them are final and ultimate solutions to the spam problem.

Personally, I don't think these proposals, along with IIM and DK,
compete as much as complement each other.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 13:34:06 -0500
Lines: 16
Cancel-Lock: sha1:bAWBoW1KheWNDuQFRuQ9frkh03o=
Sender: [email-masked]

In <[email-masked]> "Paul Smith" <[email-masked]> writes:

> Maybe SPF (or something like it) should allow signed messages to
> 'override' SPF - so mobile users from domains can fall back to message
> signing, without requiring that overhead for the majority of users who
> either aren't mobile, or who relay through their home mail server (as
> we  do when we're mobile), so for whom the basic SPF will work
> effectively.

The SES project is one such system that allows cryptographic
signatures to be used during SPF checks to make sure roaming users
aren't hurt.  This is outline in section 9.3.1.2 of the spf-classic
draft.

-wayne

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: MTAMARK etc.
Date:  Wed, 25 May 2005 19:32:55 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Bruce Lilly wrote:

>> Authorization in SMTP is determined administratively, either
>> based on SMTP AUTH

> SMTP AUTH is authentication, not authorization.

Tony wrote "based on", e.g. as precondition for 2476bis 6.1
"enforced submission rights".  Maybe unrelated to what you
talk about, but SMTP AUTH was often a source for confusion
on the spf-discuss list.

MTAMARK is IMHO much better than dial-up lists of uncertain
quality (it could be used to construct better lists), and
also better than obscure "block port 25" schemes instead of
a proper abuse desk.
                          Bye, Frank

<http://pages.infinit.net/filmore/educateYourISP.htm>

Date: Wed, 25 May 2005 18:46:51 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Sender: [email-masked]

On Wed, 25 May 2005, Bruce Lilly wrote:

> All apply (conflating sending/receiving, failure to account for SMTP
> with mechanisms other than TCP, attempts to assign IP/domain relationship
> for sending), and there was also "etc." which you conveniently failed to
> quote, and that covers a slew of practical problems with EHLO/HELO.

You'll have to explain how CSV conflates sending and receiving, and why
tying an IP address to a hostname is a problem. Perhaps you think CSV has
something to do with mail domains? (It does not.) Transports other than
TCP are not a problem because CSV isn't applicable to them. CSV isn't
mandatory and it falls back gracefully if the sending site hasn't
deployed it. It doesn't try to force people to fix their MTAs that state
invalid hostnames in their HELO commands.

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: Wed, 25 May 2005 18:30:08 +0100
From: "Paul Smith" <[email-masked]>
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

On Wed, 25 May 2005 11:26:32 -0400, Bruce Lilly <[email-masked]> wrote:

> Also, the specific
> recommendation of -all is at the heart of the fundamental problem that
> the mechanism is hostile to mobile users.

I think the whole problem of forging senders' email addresses means that  
the only effective ways to combat it ARE going to be 'hostile' to mobile  
users who can't relay through their home mail server - or are going to  
require message signing using certificates from approved authorities.

Maybe SPF (or something like it) should allow signed messages to  
'override' SPF - so mobile users from domains can fall back to message  
signing, without requiring that overhead for the majority of users who  
either aren't mobile, or who relay through their home mail server (as we  
do when we're mobile), so for whom the basic SPF will work effectively.

Paul

Date: Wed, 25 May 2005 19:31:02 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

Frank Ellermann writes:
> ... this spammer failed to inform me why he started to abuse 
> xyzzy.claranet.de resulting in 1000 backscatter mails per day for 
> about six moths, and s/h/it also failed to inform me why s/h/it 
> stopped.
>
> Two other plausible reasons except from "got the SPF idea":
...

I've been the victim of major backscatter several times. Five or ten, 
perhaps more, I don't know any more. Once I got 30,000 bounces in just 
a few days. It usually went on for a while, then stopped suddenly.

I suspect that every few weeks, they just pick a new victim. Nothing to 
do with the victim's actions or inaction.

Arnt

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Date: Wed, 25 May 2005 13:28:18 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 10:35, Tony Finch wrote:
> 
> On Wed, 25 May 2005, Bruce Lilly wrote:
> >
> > No.  Being based in a comparison of IP addresses derived from a DNS RR
> > related to a domain name from EHLO/HELO, it suffers from the same
> > problems with that approach as SPF.
> 
> You said:
> 
> > 1. conflating sending and receiving
> > 2. failure to understand fundamental properties of SMTP, e.g.
> >    MAIL FROM remains unchanged during transport
> > 3. attempts to assign a relationship between domain names
> >    and IP addresses for sending email; there is no such
> >    relationship

All apply (conflating sending/receiving, failure to account for SMTP
with mechanisms other than TCP, attempts to assign IP/domain relationship
for sending), and there was also "etc." which you conveniently failed to
quote, and that covers a slew of practical problems with EHLO/HELO.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 19:18:24 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 20
Sender: [email-masked]

Bruce Lilly wrote:

 [STD 10] 
> If a rogue sender at foo.edu sent mail with a reverse
> path of [email-masked] which bounced, when the
> bounce got back to foo.edu, the @foo.edu part of the route
> would be stripped, leaving [email-masked], and
> that's where the bounce would go.

Exactly.  So foo.edu would have to send it to the (forged)
address.  The crap takes up place in their mail queue.  And
I'd ask them why they accepted it from an unknown stranger.

I'd post every "misdirected bounce" in nanas, pointing out
that foo.edu is rogue.  I'd submit foo.edu to an open relay
test (adjust details to fit in this "alternate past" fiction).

Of course I'd block them, no more mails (incl. "misdirected
bounces") from foo.edu.  Until they stop this abuse.  Bye

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 18:59:18 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 35
Sender: [email-masked]

Bruce Lilly wrote:

>> before "my" spammer got the SPF FAIL idea,
 
> Do you have definitive proof that SPF played any role

No, this spammer failed to inform me why he started to abuse
xyzzy.claranet.de resulting in 1000 backscatter mails per day
for about six moths, and s/h/it also failed to inform me why
s/h/it stopped.

Two other plausible reasons except from "got the SPF idea":

- it was the time when two hurricanes hit Florida

- after deleting most of the backscatter for weeks, and only 
  occasionally informing admins about patterns of a dictionary
  attack etc. (always with a hint about using SPF), I started
  to report yahoogroup backscatter again about 10 days before
  it stopped.  Including dubious "subscription confirmations".

Abuse reports and Yahoo! were as always a PITA, but if you are
very persistent you might find somebody doing something about
unresolved / miscategorized issues (e.g. they don't know MIME,
that won't fly with my style of abuse reports).

So maybe that was the reason, the spammer did "something" with
my (forged) addresses and yahoogroups, and my fresh complaints
to Yahoo! disturbed this "something".

But I think s/h/it simply tested the spam setup with a new SA
supporting SPF, and s/h/it found that forging my addresses was
a stupid idea.
                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 18:30:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 32
Sender: [email-masked]

wayne wrote:
 
>| If domain owners choose to publish SPF records, it is
>| RECOMMENDED that they end in "-all", or redirect to other
>| records that do
[...]
 
> would you then say that "domain owners can't end in -all"?
> *sigh*.

How about adding "participating" to the statement in -01 ?  Or
just use the same "SPF-compliant" as in the first paragraph of
2.3:

- An SPF-compliant domain MUST publish a valid SPF record as
[...]
- It is RECOMMENDED that domains publish SPF records that end
[...]

+ An SPF-compliant domain publishes a valid SPF record as
[...]
+ It is RECOMMENDED that SPF-compliant domains publish SPF
+ records that end
[...]

Maybe add "owner" somehow, "the owner of an SPF-compliant" etc.

If Bruce has a problem with the term "domain owner", how about a
short definition in 1.3 termiology ?  You already have RfC 1983,
and 1983 has "Administrative Domain".  There should be better
sources for this term, RfC 1591 says "designated manager".  Bye

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 11:26:32 -0400
Cc: wayne <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 09:48, wayne wrote:

> Ok, would this be clearer to you?
> 
>     If domain owners choose to publish SPF records, it is RECOMMENDED
>     that they end in "-all", or redirect to other records that do, so
>     that a definitive determination of authorization can be made.

It repeats an error ("domain owners") already discussed, and still doesn't
address the basic issue that such text undermines what little partial
acknowledgment of issues exists in the draft.  Also, the specific
recommendation of -all is at the heart of the fundamental problem that
the mechanism is hostile to mobile users.

> > The simple fact of the matter is that the draft does not adequately address
> > the failings of the scheme proposed, and it simply won't pass Last Call or
> > IESG reviews without forthrightly acknowledging those failings.
> 
> The spf-classsic I-D has yet to pass the IESG, but it is only two
> votes away with only one "discuss" remaining.  That discussion point
> has been resolve in the latest revision.

That's for "Experimental", and I suspect that the IESG has yet to consider
issues raised in recent discussion.  For either Informational or
Standards Track, the review starts over, and specifically for Standards
Track there needs to be a minimum 4 weeks public IETF Last Call (assuming
the cognizant AD is willing to shepherd the draft for Standards Track
status).

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 11:15:13 -0400
Cc: wayne <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 09:11, wayne wrote:
> 
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> > On Wed May 25 2005 01:38, wayne wrote:
> >> 
> >> I'm a strong believer in "their server, their rules",
> >
> > You have missed a crucial point; *sending* mail does *NOT* use "their
> > servers".
> 
> That is in reference to receivers, not senders.  Mail admins can check
> SPF records if they want.  Their server, their rules.

You can't wriggle out of the fundamental problem that way. The records
purport to assert something about a sender based on a domain name
associated with receiving delivery notifications.

> >> and then you 
> >> can set the rules for the domain you use.
> >
> > No, because the domain name's appearance in MAIL FROM is only useful
> > if there are MX records pointing to two or more SMTP receivers
> > receiving mail for that domain name, and further only if those
> > pointers resolve to a stable IP address.  The use of DHCP on many
> > networks rules out the latter, and terms of service for many ISPs
> > preclude operation of servers.
> 
> There are plenty of places will do the mail hosting for you.  For
> example, Godaddy lets you register a domain name for $9/yr, and lets
> you do email for $10/yr.  They also have a free email option, which
> will likely be good enough for many people.

No.  First, there is no "free email option".  Second, the "$10/yr"
option provides 1 mailbox per domain, which isn't going to be terribly
useful unless the local-part is specified as "postmaster" as required
by the Hosts Requirements Standard (and the implementation had better
treat that local-part as case-insensitive), or is a "catch-all" (in
which case it will catch a great deal of dictionary-attack spam).
More important, you are still conflating *receipt* of email with the
independent action of *sending* email.

Date: Wed, 25 May 2005 15:35:37 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Tony Finch <[email-masked]>
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Sender: [email-masked]

On Wed, 25 May 2005, Bruce Lilly wrote:
>
> No.  Being based in a comparison of IP addresses derived from a DNS RR
> related to a domain name from EHLO/HELO, it suffers from the same
> problems with that approach as SPF.

You said:

> 1. conflating sending and receiving
> 2. failure to understand fundamental properties of SMTP, e.g.
>    MAIL FROM remains unchanged during transport
> 3. attempts to assign a relationship between domain names
>    and IP addresses for sending email; there is no such
>    relationship

None of which is true for CSV. Regarding option 3, CSV allows sites to
declare a stronger association between host names and IP addresses, which
SMTP servers can check. Since this is an extension to existing practice,
prior limitations do not apply.

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: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 08:48:03 -0500
Lines: 53
Cancel-Lock: sha1:4R4/mM0Qe9U9HFU+Rs5zbSRCAeE=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Wed May 25 2005 08:39, wayne wrote:
>> 
>> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
>> 
>> > On Wed May 25 2005 01:21, wayne wrote:
>> >> 
>> >> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
>> >
>> >> > undermined by language such as "It is RECOMMENDED that domains publish
>> >> > SPF records".
>> >> 
>> >> No where in the I-D does it say that "It is RECOMMENDED that domains publish
>> >> SPF records".
>> >
>> > That text in fact appears at the start of the second paragraph of draft
>> > section 2.3.
>> 
>> You left off the rest of the sentence, and therefore change its mean.
>> 
>> The complete sentence is:
>> 
>>    It is RECOMMENDED that domains publish SPF records that end in
>>    "-all", or redirect to other records that do, so that a definitive
>>    determination of authorization can be made.
>
> Please explain how one can "publish SPF records that end in '-all'" without
> in fact publishing an SPF record.  And/or explain how redirection to other
> (SPF) records can happen without an SPF record being published.

Ok, would this be clearer to you?

    If domain owners choose to publish SPF records, it is RECOMMENDED
    that they end in "-all", or redirect to other records that do, so
    that a definitive determination of authorization can be made.

Or, would you then say that "domain owners can't end in -all"?

*sigh*.

> The simple fact of the matter is that the draft does not adequately address
> the failings of the scheme proposed, and it simply won't pass Last Call or
> IESG reviews without forthrightly acknowledging those failings.

The spf-classsic I-D has yet to pass the IESG, but it is only two
votes away with only one "discuss" remaining.  That discussion point
has been resolve in the latest revision.

-wayne

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 09:25:00 -0400
Cc: wayne <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 08:39, wayne wrote:
> 
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> > On Wed May 25 2005 01:21, wayne wrote:
> >> 
> >> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> >
> >> > undermined by language such as "It is RECOMMENDED that domains publish
> >> > SPF records".
> >> 
> >> No where in the I-D does it say that "It is RECOMMENDED that domains publish
> >> SPF records".
> >
> > That text in fact appears at the start of the second paragraph of draft
> > section 2.3.
> 
> You left off the rest of the sentence, and therefore change its mean.
> 
> The complete sentence is:
> 
>    It is RECOMMENDED that domains publish SPF records that end in
>    "-all", or redirect to other records that do, so that a definitive
>    determination of authorization can be made.

Please explain how one can "publish SPF records that end in '-all'" without
in fact publishing an SPF record.  And/or explain how redirection to other
(SPF) records can happen without an SPF record being published.

The simple fact of the matter is that the draft does not adequately address
the failings of the scheme proposed, and it simply won't pass Last Call or
IESG reviews without forthrightly acknowledging those failings.  Moreover,
with those failings, acknowledged or not, the scheme is unlikely to be
seriously considered for the Standards Track.  If you really want a Standards
Track proposal, you'll need to address the issues -- most likely a *workable*
scheme would bear little resemblance to SPF or any of the currently proposed
schemes (I have separately outlined what I believe to be the minimum
characteristics needed to provide meaningful authorization for a MAIL FROM
reverse path; and I suspect that involves a chicken-and-egg problem).

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 08:11:00 -0500
Lines: 44
Cancel-Lock: sha1:61HoePpp6b2pGe9w8Djym9eT8gY=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Wed May 25 2005 01:38, wayne wrote:
>> 
>> I'm a strong believer in "their server, their rules",
>
> You have missed a crucial point; *sending* mail does *NOT* use "their
> servers".

That is in reference to receivers, not senders.  Mail admins can check
SPF records if they want.  Their server, their rules.

>> and also "the 
>> domain owner's domain, their rules".  If your ISP does anything you
>> really don't like, I complete agree that you should switch.  For only
>> a few bucks a year, you can also buy your own domain name
>
> No, one can license use of a domain name for a period of time.  Subject
> to possible litigation if your name happens to be something like Mike
> Rowe.

Well, if you license the use of a domain name, then you should make
sure that license is acceptable to you.

>> and then you 
>> can set the rules for the domain you use.
>
> No, because the domain name's appearance in MAIL FROM is only useful
> if there are MX records pointing to two or more SMTP receivers
> receiving mail for that domain name, and further only if those
> pointers resolve to a stable IP address.  The use of DHCP on many
> networks rules out the latter, and terms of service for many ISPs
> preclude operation of servers.

There are plenty of places will do the mail hosting for you.  For
example, Godaddy lets you register a domain name for $9/yr, and lets
you do email for $10/yr.  They also have a free email option, which
will likely be good enough for many people.

-wayne

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 09:07:59 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 13:05, Frank Ellermann wrote:

> And I wouldn't need SPF.  That's the point, if STD 10 would
> (still) work as designed something like RMX or SPF would be
> completely unnecessary:

No. If a rogue sender at foo.edu sent mail with a reverse path
of [email-masked] which bounced, when the bounce got
back to foo.edu, the @foo.edu part of the route would be stripped,
leaving [email-masked], and that's where the bounce
would go.

Now if you were able to roll the clock back farther to use a
flat host table rather than DNS, you *might* (i.e. maybe) be
able to make a weak case. [*]

But DNS isn't going to be abandoned for a flat hosts table, nor
are DNS MX records going to be replaced by explicit routes.

* If you were able to roll the clock back that far, we'd be
talking about FTP MAIL/MLFL commands, not SMTP, and you'd have
FTP login/password mechanisms for authentication.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 08:57:38 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 14:39, Frank Ellermann wrote:

> Of course.  We're talking about TeraBytes and Billions of USD,
> not peanuts.  My personal damage was 150,000 bounces and other
> backscatter before "my" spammer got the SPF FAIL idea,

Do you have definitive proof that SPF played any role, or is
this more "post hoc, ergo propter hoc" at work?

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 07:39:43 -0500
Lines: 34
Cancel-Lock: sha1:itqC5ilZ4LQNByJqkav8R4l1Eek=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Wed May 25 2005 01:21, wayne wrote:
>> 
>> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
>
>> > undermined by language such as "It is RECOMMENDED that domains publish
>> > SPF records".
>> 
>> No where in the I-D does it say that "It is RECOMMENDED that domains publish
>> SPF records".
>
> That text in fact appears at the start of the second paragraph of draft
> section 2.3.

You left off the rest of the sentence, and therefore change its mean.

The complete sentence is:

   It is RECOMMENDED that domains publish SPF records that end in
   "-all", or redirect to other records that do, so that a definitive
   determination of authorization can be made.

Now, if your point is that this sentence should be reworded to make it
clearer that this recommendation is about the SPF record domain owners
choose to publish, rather than a recommendation that domain owners
publish SPF records, I could agree with that.

I think there are plenty of other references in the SPF I-D that make
it clear that publishing SPF records, starting in the abstract.

-wayne

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: MTAMARK etc.
Date: Wed, 25 May 2005 08:06:19 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 05:43, Tony Finch wrote:
> 
> On Tue, 24 May 2005, Bruce Lilly wrote:

> > As I understand it from a quick skim, there are however some issues:
> > 1. it speaks of MTAs and mail severs, however an MUA or MSA may also
> >    send mail, and there is at present no way for an SMTP receiver to
> >    determine whether the connected sending client is an MUA, an MSA,
> >    or an MTA.
> 
> This is usually done operationally, by providing different service
> addresses for MTAs (your MX hosts) and MUAs (your MSA hosts).

MX refers to receiving servers, not sending clients.  Not all sending
MTAs have MX records, as some are not public MX hosts for a domain.  A
sending MTA with an MX record is either sending inside an administrative
zone, is a host that happens to run multiple types of agents (or appears
to do so via a NAT-like mechanism), or is an open relay.  MUAs (clients)
and MSA (clients side and server side) are separate architectural
entities.

> An MUA 
> connecting to an MX isn't going to have an easy time.

In fact the SMTP model is just that, and schemes that seek to prevent it
are harmful to the Internet mail system.  From the SMTP RFCs:

               +----------+                +----------+
   +------+    |          |                |          |
   | User |<-->|          |      SMTP      |          |
   +------+    |  Client- |Commands/Replies| Server-  |
   +------+    |   SMTP   |<-------------->|    SMTP  |    +------+
   | File |<-->|          |    and Mail    |          |<-->| File |
   |System|    |          |                |          |    |System|
   +------+    +----------+                +----------+    +------+
                SMTP client                SMTP server

                ^ this interacts with the user, and is therefore an MUA

> The MSA concept is rather weak in Internet email. It only really makes
> sense as an SMTP receiver. Its sending side operates as an MTA. It isn't
> necessary to talk explicitly about MSAs when writing about MTA-MTA
> communication.

Nevertheless, it is identifiable as a distinct entity architecturally;
several schemes are based on restricting certain operations to MTA-MTA
connections, and the simple fact is that with the current protocols there
is no reliable way for one party (client or server) to determine whether
the other party is an MUA, MSA, MTA, MDA, a telnet session, a zombie, etc.
 
> > 2. it speaks of "unauthorized message transmission", but SMTP has
> >    no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
> >    used for sending (pushing) mail).
> 
> Authorization in SMTP is determined administratively, either based on SMTP
> AUTH

SMTP AUTH is authentication, not authorization.  See FYI 36.  The only
meaningful type of authorization that could be applied to use of a
MAIL FROM mailbox would be some scheme that includes explicit authorization
records with a public yet secure infrastructure for a database for those
records, incorporates authentication, uses a digital signature, and
(necessarily) involves some sort of PKI. 

> or other out-of-protocol criteria such as DNS blacklists. MTAMARK and 
> CSA are new ways for one site to communicate authorization policies to
> another site. Since it's an out-of-protocol extension,

MTAMARK in particular seems more a way for a receiver to make a
time-dependent assumption in the absence of information.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Date: Wed, 25 May 2005 07:35:08 -0400
Cc: Tony Finch <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 05:43, Tony Finch wrote:
> 
> On Tue, 24 May 2005, Bruce Lilly wrote:
> > On Tue May 24 2005 16:43, Markus Stumpf wrote:
> > > On Tue, May 24, 2005 at 10:09:12AM -0400, Bruce Lilly wrote:
> > > > On Mon May 23 2005 14:39, Frank Ellermann wrote:
> > > > >
> > > > > The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
> > > > > do very different things, SPF covers some older ideas.
> > > >
> > > > They all suffer from similar problems involving the issues
> > >        ***
> > >
> > > *ALL* is wrong as MTAMARK does neither of the 3 points you have
> > > outlined.
> >
> > OK, I stand corrected.
> 
> The same is true for CSV.

No.  Being based in a comparison of IP addresses derived from a DNS RR
related to a domain name from EHLO/HELO, it suffers from the same
problems with that approach as SPF.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 07:17:17 -0400
Cc: wayne <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 01:38, wayne wrote:
> 
> 
> 
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:
> 
> > On Tue May 24 2005 13:05, Frank Ellermann wrote:
> >> > That's at the heart of the problem -- it attempts to define
> >> > a set which makes no sense; worse than that, it is harmful.
> >> 
> >> It does not _attempt_ to define this set, it only _allows_
> >> to define this set.
> >
> > But as the sender of mail, and the person affected, it doesn't
> > allow *ME* to do so.  If -- in a fit of stupidity -- somebody at
> > the ISP where I *receive* mail were to do so, I would either be
> > forced to use a null return path (breaking the intended function
> > of delivery notifications, as noted by Markus), or I would drop
> > that ISP like a hot potato and find one with more sense.
> 
> I'm a strong believer in "their server, their rules",

You have missed a crucial point; *sending* mail does *NOT* use "their
servers".

> and also "the 
> domain owner's domain, their rules".  If your ISP does anything you
> really don't like, I complete agree that you should switch.  For only
> a few bucks a year, you can also buy your own domain name

No, one can license use of a domain name for a period of time.  Subject
to possible litigation if your name happens to be something like Mike
Rowe.

> and then you 
> can set the rules for the domain you use.

No, because the domain name's appearance in MAIL FROM is only useful
if there are MX records pointing to two or more SMTP receivers
receiving mail for that domain name, and further only if those
pointers resolve to a stable IP address.  The use of DHCP on many
networks rules out the latter, and terms of service for many ISPs
preclude operation of servers.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 07:08:40 -0400
Cc: wayne <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 01:21, wayne wrote:
> 
> In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> > undermined by language such as "It is RECOMMENDED that domains publish
> > SPF records".
> 
> No where in the I-D does it say that "It is RECOMMENDED that domains publish
> SPF records".

That text in fact appears at the start of the second paragraph of draft
section 2.3.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Wed, 25 May 2005 07:05:08 -0400
Cc: "Robert A. Rosenberg" <[email-masked]>
Sender: [email-masked]

On Wed May 25 2005 00:57, Robert A. Rosenberg wrote:
> 
> At 15:04 -0400 on 05/24/2005, Bruce Lilly wrote about Re: SPF I-D for 
> review: draft-schlitt-spf-classic-01.txt:
> 
> >I get:
> >gmx.de  text = "v=spf1 ip4:213.165.64.0/23 -all"
> >
> >Is that supposed to be relevant to the point, which is that publication
> >of SPF records affect *all* parties associated with mailboxes using a
> >domain name (not just the registrant), and -- particularly among large
> >groups (tens of thousands, millions) -- one size doesn't fit all?  Can
> >you guarantee that no person who *receives* mail at a domain under
> >gmx.de will ever wish to *send* mail from a convention site kiosk, an
> >airport courtesy lounge, a restaurant or cafe, a public access point,
> >etc.?
> 
> The correct SMTP Server to inject the message via is one provided by 
> gmx.de for the MSA function. IOW: Tell your MUA to connect to that 
> Server

And how precisely does one do that when using a mail kiosk at a convention
site, etc.?

> and you are using an SPF Approved/Authorized  
> Submission/Relaying Server. If you are not allowed to  use that 
> Server (due to SMTP Connection Hijacking on the part of the 
> Connectivity Provider then you are out of luck - You should send from 
> your Laptop via an Ethernet/WiFi connection).

If port blocking is in effect, that won't help.   That problem exacerbated
by SPF is one of the reasons SPF is harmful to Internet mail. 

Date: Wed, 25 May 2005 10:43:08 +0100
From: Tony Finch <[email-masked]>
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Sender: [email-masked]

On Tue, 24 May 2005, Bruce Lilly wrote:
> On Tue May 24 2005 16:43, Markus Stumpf wrote:
> > On Tue, May 24, 2005 at 10:09:12AM -0400, Bruce Lilly wrote:
> > > On Mon May 23 2005 14:39, Frank Ellermann wrote:
> > > >
> > > > The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
> > > > do very different things, SPF covers some older ideas.
> > >
> > > They all suffer from similar problems involving the issues
> >        ***
> >
> > *ALL* is wrong as MTAMARK does neither of the 3 points you have
> > outlined.
>
> OK, I stand corrected.

The same is true for CSV.

I've proposed an extension to CSV which specifies how to place CSA records
in the reverse DNS. With this extension it becomes a superset of the
MTAMARK functionality. The implementation of CSA in Exim includes this
extension.

> As I understand it from a quick skim, there are however some issues:
> 1. it speaks of MTAs and mail severs, however an MUA or MSA may also
>    send mail, and there is at present no way for an SMTP receiver to
>    determine whether the connected sending client is an MUA, an MSA,
>    or an MTA.

This is usually done operationally, by providing different service
addresses for MTAs (your MX hosts) and MUAs (your MSA hosts). An MUA
connecting to an MX isn't going to have an easy time.

The MSA concept is rather weak in Internet email. It only really makes
sense as an SMTP receiver. Its sending side operates as an MTA. It isn't
necessary to talk explicitly about MSAs when writing about MTA-MTA
communication.

> 2. it speaks of "unauthorized message transmission", but SMTP has
>    no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
>    used for sending (pushing) mail).

Authorization in SMTP is determined administratively, either based on SMTP
AUTH or other out-of-protocol criteria such as DNS blacklists. MTAMARK and
CSA are new ways for one site to communicate authorization policies to
another site. Since it's an out-of-protocol extension, the limitations of
basic SMTP are irrelevant: the purpose of an extension is to overcome a
limitation.

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: wayne <[email-masked]>
Subject:  Re: proposed Received-SPF trace header
Date:  Wed, 25 May 2005 00:42:33 -0500
Lines: 25
Cancel-Lock: sha1:addmzcw8Dcf02v6LXtvpdc7r9ro=
Sender: [email-masked]

In <20050523143018.GG89934@verdi> John Leslie <[email-masked]> writes:

> wayne <[email-masked]> wrote:
>> 
>> http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
>
> which includes:
> ] 
> ] 7.  The Received-SPF header field
>
>    We SHOULD discuss on this list whether such a header can be considered
> a "trace field"; and I'd like to suggest that we do so in a context of
> what "envelope information" means.

Thanks for raising this issue John.  Yes, I am very interested in
whether the Received-SPF header can be considered a trace header.  As
an optional part of the SPF spec, it is one of the least tested
aspects of SPF.

Note that in my post to the ietf-822 list, I pointed out that the
Received-SPF header is not correctly defined to always end in a CRLF.
This will be fixed in the next release.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 00:38:58 -0500
Lines: 24
Cancel-Lock: sha1:zbhguv+cmVf/I4J2SXwYxfXEAMs=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Tue May 24 2005 13:05, Frank Ellermann wrote:
>> > That's at the heart of the problem -- it attempts to define
>> > a set which makes no sense; worse than that, it is harmful.
>> 
>> It does not _attempt_ to define this set, it only _allows_
>> to define this set.
>
> But as the sender of mail, and the person affected, it doesn't
> allow *ME* to do so.  If -- in a fit of stupidity -- somebody at
> the ISP where I *receive* mail were to do so, I would either be
> forced to use a null return path (breaking the intended function
> of delivery notifications, as noted by Markus), or I would drop
> that ISP like a hot potato and find one with more sense.

I'm a strong believer in "their server, their rules", and also "the
domain owner's domain, their rules".  If your ISP does anything you
really don't like, I complete agree that you should switch.  For only
a few bucks a year, you can also buy your own domain name and then you
can set the rules for the domain you use.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 00:32:02 -0500
Lines: 20
Cancel-Lock: sha1:E0TmBjtlKSf6TGYBvMTjyhPaX6g=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Mon May 23 2005 14:39, Frank Ellermann wrote:
>
>> > Refers to POSIX, an external standard.  Raises questions
>> > about implementations.
>> 
>> It is in an example, ..."the same value as returned by the"...
>
> Would that be the one that fails to account for leap seconds?

The issue of leap seconds is part of the reason that the time value
return is required to be only approximate.  To be quite honest, I have
never been convinced that the time value macro variable is really that
useful, but since it is part of the existing practices of deployed SPF
systems, it needs to be documented as well as it can.  

-wayne

Date: Wed, 25 May 2005 00:57:09 -0400
To: [email-masked]
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

At 15:04 -0400 on 05/24/2005, Bruce Lilly wrote about Re: SPF I-D for 
review: draft-schlitt-spf-classic-01.txt:

>I get:
>gmx.de  text = "v=spf1 ip4:213.165.64.0/23 -all"
>
>Is that supposed to be relevant to the point, which is that publication
>of SPF records affect *all* parties associated with mailboxes using a
>domain name (not just the registrant), and -- particularly among large
>groups (tens of thousands, millions) -- one size doesn't fit all?  Can
>you guarantee that no person who *receives* mail at a domain under
>gmx.de will ever wish to *send* mail from a convention site kiosk, an
>airport courtesy lounge, a restaurant or cafe, a public access point,
>etc.?

The correct SMTP Server to inject the message via is one provided by 
gmx.de for the MSA function. IOW: Tell your MUA to connect to that 
Server and you are using an SPF Approved/Authorized 
Submission/Relaying Server. If you are not allowed to  use that 
Server (due to SMTP Connection Hijacking on the part of the 
Connectivity Provider then you are out of luck - You should send from 
your Laptop via an Ethernet/WiFi connection).

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Wed, 25 May 2005 00:21:58 -0500
Lines: 83
Cancel-Lock: sha1:Hp8qVPJF/86qIYtAa1It64hYCGo=
Sender: [email-masked]

In <[email-masked]> Bruce Lilly <[email-masked]> writes:

> On Fri May 20 2005 16:15, wayne wrote:
>

Sorry for taking so long to follow up on this thread.  I'm afraid I've
been busy with other things.  As this thread has already discussed
many issues, I'm going to try and keep this short and pick out just a
few points.

>                    If the intent is in fact to change the intended
> status from Experimental (I-D tracker) to Standards Track (as stated
> by the author in the predecessor of this message; see below), then
> the IESG may wish to initiate a New Last Call of at least 4 weeks
> duration in accordance with the procedures for an individual
> submission for Standards Track status as outlined in RFC 2026 (BCP 9).

Yes, my intent is to change the status from Experimental to Standard
Track.  The Expermental designation was decided by the AD in a process
that involved some misunderstandings.

I would welcome the Last Call review, just as I have gone out of my
way to ask for two reviews from several IETF mailing lists already.

>> Debates about better techniques, why 
>> SPF is evil, etc. are probably best discussed on things like the IRTF
>> ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
>> separate thread/subject.
>
> On the contrary, I believe [...]

I'll leave it up to whomever runs this mailing list to decide whether
the current thread is offtopic or excessive.  I am just all too aware
that when the subject of SPF comes up, it often triggers discussions
of spam, DNS, MUA design, phishers, and many other things that may
well not be on-topic for this list.

> At a bare minimum, if the intent of the draft is in fact to document the
> described mechanism, it should clearly delineate and emphasize those
> rather serious defects in said mechanism, defects which are only
> partially and begrudgingly acknowledged in the draft,

I disagree that the trade offs and implications of deploying SPF is
only partially or begrudgingly acknowledge in the draft.  I have
worked very hard to try and keep the draft as short as possible, do
many of these things are not given long rants, but they are there.

> undermined by language such as "It is RECOMMENDED that domains publish
> SPF records".

No where in the I-D does it say that "It is RECOMMENDED that domains publish
SPF records".  I strongly believe that it is up to domain owners to
choose whether to publish SPF records or not, and it is up to mail
admins to decide if they want to check them.

>> As such, there is a lot of stuff in 
>> this I-D that could use a lot of review from SMTP experts.
>
> You say you are reluctant to debate the shortcomings of SPF (many of
> which are shared by similar schemes), yet you ask for review.  About the
> only way that makes sense is to use the review to document the flaws in
> SPF.

I have already received several helpful corrections and suggestions
due to this most recent round of reviews.  My reluctance to debate the
known issues with SPF is based on seeing many other long rants such as
you have given.  I very much doubt that I can change your mind, and
since you have only raised very old and well understood arguments, I
doubt that there is much that I will learn from you on this particular
subject.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Tue, 24 May 2005 23:33:56 -0500
Lines: 26
Cancel-Lock: sha1:+ClkAeKHZd2x2xR3hLy32iKKnLg=
Sender: [email-masked]

In <20050524155001.GE22668@verdi> John Leslie <[email-masked]> writes:

> wayne <[email-masked]> wrote:
>> In <20050523134752.GF89934@verdi> John Leslie <[email-masked]> writes:
>> 
>>> There is an explicit recommendation that domains publish "... -all":
>>> I recommend changing that. Instead, I strongly urge that levels of
>>> disclaiming be defined from the very outset of RFC publication:
>> 
>> Like many subjects related to SPF, this has been hotly debated more
>> than once.  There is a whole section on forwarding, along with other
>> problems faced by people using SPF.  I do not think your suggests are
>> accurate.  In particular, if you use SES, forwarding does not break
>> with -all.  
>
>    I think we may need to explore this last claim: that forwarding does
> not break "if you use SES".

Uh, I think you are right.  It has been a while since I've read the
SES spec, but I think the use of the exists: mechanism in the SPF
record is optional.  Please change that to "if you use SES with the
exists: mechanism in your SPF record".

Sorry for the confusion.

-wayne

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Tue, 24 May 2005 23:47:00 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Sender: [email-masked]

[email-masked] wrote:

> Now, as you were saying?

RfC 2821 chapter 5 explains MX, do you have any specific
questions about it ?

My mailouts send to your MXs, your mailouts send to my MXs,
if the border in one direction is Ohare, and in the other
direction it's Charlotte it's fine.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Date: Tue, 24 May 2005 17:40:49 -0400
Cc: Markus Stumpf <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 16:43, Markus Stumpf wrote:
> 
> On Tue, May 24, 2005 at 10:09:12AM -0400, Bruce Lilly wrote:
> > On Mon May 23 2005 14:39, Frank Ellermann wrote:
> > > The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
> > > do very different things, SPF covers some older ideas.
> > 
> > They all suffer from similar problems involving the issues
>        ***
> 
> *ALL* is wrong as MTAMARK does neither of the 3 points you have
> outlined.

OK, I stand corrected.

> It doesn't fiddle with domains or senders ... it is a simple 
> way for the admin of IP space to tell others whether s/he thinks that
> a certain IP is associated with a mailserver that should send mail
> accross the public Internet.

As I understand it from a quick skim, there are however some issues:
1. it speaks of MTAs and mail severs, however an MUA or MSA may also
   send mail, and there is at present no way for an SMTP receiver to
   determine whether the connected sending client is an MUA, an MSA,
   or an MTA.
2. it speaks of "unauthorized message transmission", but SMTP has
   no authorization mechanism (unlike, say, IMAP, but then IMAP isn't
   used for sending (pushing) mail).
3. like other IP based schemes, it doesn't play well with DHCP and
   NAT.
4. While some parts of IP address space might be managed in a way
   which is amenable to the approach, other parts have many widely
   separated class C ranges under one administrative entity, which
   would seem to mean managing each of those ranges separately.
5. I'm not thrilled about the "unmarked" yes->no flag day concept.
6. authentication is fine where there is a prior arrangement,
   however one of the fundamental principles of email is that it
   permits communications with no prior arrangement.
7. Simply publishing information about which IP addresses might source
   messages may reveal information of potential use to an attacker
   (not mentioned in security considerations).

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 24 May 2005 22:43:43 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, May 24, 2005 at 10:09:12AM -0400, Bruce Lilly wrote:
> On Mon May 23 2005 14:39, Frank Ellermann wrote:
> > The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
> > do very different things, SPF covers some older ideas.
> 
> They all suffer from similar problems involving the issues
       ***

*ALL* is wrong as MTAMARK does neither of the 3 points you have
outlined. It doesn't fiddle with domains or senders ... it is a simple
way for the admin of IP space to tell others whether s/he thinks that
a certain IP is associated with a mailserver that should send mail
accross the public Internet. Not more, not less. Unless port 25 blocking
it leaves the decision up to the receiver.
As spammers hardly have access to the reverse DNS tree they can't add
marks for their zombie armies (usually) and as it is a distributed
scheme it is hard to attack (unlike DNSBLs).

In the .DE zone there are about 140000 unique IP addresses handling (MX)
all mail for all 7.9 millions domains. Assuming the same magnitude of
sending MTAs deployment is easy and fast (compared to >> 7.9 millions
of e.g. SPF records needed) and the more TLDs you add to the picture
the better the relation MTA <> #domains will get.

Some ISPs and Mail Service Providers mostly in Germany/Austria/Switzerland
already have added MTAMARK records for their mailservers and we use it
on the receiving side e.g. for anti-greylisting with big success.

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

To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt 
From: [email-masked]
Date: Tue, 24 May 2005 16:38:46 -0400
Sender: [email-masked]

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

On Tue, 24 May 2005 21:48:34 +0200, Frank Ellermann said:

> As soon as you have both borders defined you can check:
> "always coming from US" - "always going to MX".  So if
> it came from Belize to Mexico it wasn't US.  Bye, Frank

Odd.  I just booked a plane ticket to a workshop - outbound
is ROA-ORD-SFO, return is SFO-CLT-ROA.  I'm just waiting
for the TSA goons to perform an SPF check on me at either OHare
or Charlotte. ;)

(And one participant in last year's workshop made the mistake
of flying Paris-Toronto-SFO and hit an unexpected visa issue...)

Now, as you were saying?

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

--==_Exmh_1116967125_3605P--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Tue, 24 May 2005 21:48:34 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 22
Sender: [email-masked]

[email-masked] wrote:

> So it defines the border of the *sender*, and then the
> *receiver* border box has to do the check?

Yes.   The receiver is not forced to check it, but if he
wants to do it, it must be at the first box on his side,
typically one of his MXs.

> Maybe it should define the receiver border as well?

Sorry, I don't quite get this, the receiver border is
clear, the MXs (or the A without any MX).  That part
of the equation was always clear.

It wasn't clear for the sender side.  One predecessor
of SPF was RMX => same idea as MX, only for senders.

As soon as you have both borders defined you can check:
"always coming from US" - "always going to MX".  So if
it came from Belize to Mexico it wasn't US.  Bye, Frank

From: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: misdirected bounces
Date: Tue, 24 May 2005 15:40:40 -0400
Cc: Ned Freed <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 13:06, Ned Freed wrote:
> 
> > On Mon May 23 2005 22:05, Markus Stumpf wrote:
> > > No MTA that
> > > I know of sends bounces to some random address instead of the envelope
> > > sender addresses (which would of course be misdirected).
> 
> > Not MTAs perhaps, but some "vacation"-like programs do so.  Anybody who
> > has ever received an "I'm out of the office" message after posting to a
> > mailing list is the victim of such a program (or the dingbat it operates
> > on behalf of, or of a list expander that isn't compliant with the Host
> > Requirements Standard).
> 
> I haven't seen a recent example, but there was a time when some MTAs would use
> the value in an Errors-to: header field in preference to what was in the MAIL
> FROM.
> 
> But of course none of this corresponds to sending bounces to a random address.

Not "random" in a mathematical sense, but in the sense of not the sender
envelope address (RFC 3834 as amended by erratum); sometimes a From field
(especially bad when there is a Reply-To field win the original message,
and it's ignored), sometimes (as you note) a non-standard "Errors-To"
field, etc. -- unpredictable from the POV of the original message sender.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Tue, 24 May 2005 15:23:01 -0400
Cc: [email-masked], Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 14:15, [email-masked] wrote:
> On Tue, 24 May 2005 19:05:22 +0200, Frank Ellermann said:
> 
> > No, you don't check SPF whereever you like it.  SPF defines
> > the border of the sender, the only point where that makes any
> > sense at all is your border.  You can't check it behind your
> > border, you check it at mx23.mrf.mail.rcn.net
> 
> So it defines the border of the *sender*, and then the *receiver*
> border box has to do the check?  Somehow that seems mildly busticated.
> Maybe it should define the receiver border as well?

Good trick.  Especially if a receiving MTA sees its IP address as an
RFC 1918 address, necessarily different from the A records that would
be returned by a DNS lookup.

Another known technical omission is a specification for how the
receiver is supposed to determine the sender's borders (N.B. MX
records are of zero use, as they apply to receiving, not sending,
and many sites use separate hosts for sending and receiving (i.e.
a sending host has a different domain name and IP address from
the receiving hosts listed in MX records)).

Moot point, really, since sending can take place from any of as
many clients as there are in use collectively by users who have
mailboxes (for receipt of delivery notifications, since the
discussion is related to MAIL FROM) associated with a given domain.
Basically, reality is emailers (doctors and others) without borders.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Tue, 24 May 2005 15:04:41 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 13:05, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:

>  [POSIX timestamp]
> > Would that be the one that fails to account for leap seconds?
> 
> Yes - better check it if this was no rhethorical question,
> I'm not sure => if and only IIRC 24*60*60 seconds per day.

Not rhetorical; I've seen POSIX values suggested in another context.
The end result of that discussion was to do something more sensible,
viz. to use the same timestamp format already used in message
header fields, the RFC 2822 date-time.  That's not tied to any specific
OS, and code to generate and parse it is readily available.  And it
accomodates leap seconds.

> The I-D tracker is the IESG's POV.  It's not always exactly
> the same as the author's POV, or the RfC editor's POV, and
> they are free to change their opinion.

Recent experience with the IESG indicates that a change in intended
status (reasonably) entails the start of a new review.
 
> I've no idea when they publish submitted errata.

Neither do I.

> The 2069 
> error (PEBKAC or not) is older.  How long do you wait for
> some missing slashes in 2045, a year ?

Something like that since the initial report to the authors. Reported
confirmed to the RFC Editor late last year.

> There was also a 
> discussion about something in 2821 here, not yet published.

Unlikely to be published anytime soon.  In the absence of a current
WG, the document Editor declined to confirm an erratum.  I understand
his POV, but it doesn't bode well for interoperability.

> > the term "source mailbox" is devoid of meaning.
> 
> It means "responsible sender":  Those who send mail, can
> also receive mail, at least for potential error messages,
> or as you said:
> 
> > Of course a non-null return path needs to be resolvable
> > -- for the purpose of *receiving* delivery notifications.

Attempting to tie that to IP addresses or other domain names and/or
attempting to overload semantics of "source" or "sender" are other
matters.  Note also, as previously mentioned, there are legitimate
reasons for directing delivery notification messages to a mailbox
other than a personal mailbox for the sender, and it is primarily
for that reason that "source mailbox", "responsible sender", etc.
are inappropriate terms.

> > That's at the heart of the problem -- it attempts to define
> > a set which makes no sense; worse than that, it is harmful.
> 
> It does not _attempt_ to define this set, it only _allows_
> to define this set.

But as the sender of mail, and the person affected, it doesn't
allow *ME* to do so.  If -- in a fit of stupidity -- somebody at
the ISP where I *receive* mail were to do so, I would either be
forced to use a null return path (breaking the intended function
of delivery notifications, as noted by Markus), or I would drop
that ISP like a hot potato and find one with more sense.

> That's a huge difference.  You are not 
> forced to define anything at all.

I'm forced to deal with the consequences of an action over which
I have no control, and that is worse.

> > extrapolate that to an ISP with "more than 1 million
> > customer connections"
> 
> Try nslookup -q=txt gmx.de

I get:
gmx.de  text = "v=spf1 ip4:213.165.64.0/23 -all"

Is that supposed to be relevant to the point, which is that publication
of SPF records affect *all* parties associated with mailboxes using a
domain name (not just the registrant), and -- particularly among large
groups (tens of thousands, millions) -- one size doesn't fit all?  Can
you guarantee that no person who *receives* mail at a domain under
gmx.de will ever wish to *send* mail from a convention site kiosk, an
airport courtesy lounge, a restaurant or cafe, a public access point,
etc.?

> > I see no problem with STD 3 section 5.3.6 (a)
> 
> 251 without the responsibility to handle later bounces.
> Just forward and forget, it hits somebody else directly.

STD 3 section 5.3.6 doesn't mention 251 or "bounces" (anywhere), and
(a) says:

              (a)  Alias

                   To expand an alias, the recipient mailer simply
                   replaces the pseudo-mailbox address in the envelope
                   with each of the expanded addresses in turn; the rest
                   of the envelope and the message body are left
                   unchanged.  The message is then delivered or
                   forwarded to each expanded address.

[251 response codes are mentioned only in sections 5.2.4 and 5.2.10; 5.2.4
specifically relates to SEND, SOML, and SAML commands, which are irrelevant
to our discussion, and 5.2.10 discusses an exception to the rule of basing
actions solely on response codes rather than text, which seems inapplicable
as well]

> > Return-Path: <[email-masked]>
> > Received: from mr09.mrf.mail.rcn.net (EHLO mr09.mrf.mail.rcn.net) (207.172.4.28)
> >         by ms07.mrf.mail.rcn.net (MOS 3.5.6-GR FastPath queued)
> >         with ESMTP id GKT45663;
> >         Thu, 19 May 2005 14:37:59 -0400 (EDT)
> > Received: from mx23.mrf.mail.rcn.net (mx23.mrf.mail.rcn.net [207.172.4.102])
> >         by mr09.mrf.mail.rcn.net (MOS 3.5.7-GR)
> >         with ESMTP id CCC77732;
> >         Thu, 19 May 2005 14:29:45 -0400 (EDT)
> > Received: from unknown (HELO mx23.mrf.mail.rcn.net) (10.255.5.102)
> >   by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:44 -0400
> > Received: from gundel.de.clara.net (212.82.225.86)
> >   by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:41 -0400
> > Received: from [62.80.58.103] (helo=xyzzy)
> >         by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD)
> >         id 1DYpzH-0005K5-W5
> >         for [email-masked]; Thu, 19 May 2005 20:43:16 +0200
> > Message-ID: <[email-masked]>
> 
> Okay, somebody claiming to be [email-masked] sent
> a mail to [email-masked]
> 
> `nslookup -q=mx erols.com` says mx.mail.rcn.net, the border
> MTA is apparently mx23.mrf.mail.rcn.net.  It talked with IP
> 212.82.225.86 saying HELO gundel.de.clara.net, no SPF policy,
> result "none".  It was MAIL FROM:<[email-masked]>

The draft under discussion states "At least the "MAIL FROM" identity
MUST be checked".  HELO doesn't enter into this discussion which, as
originally noted, deals with one specific problem related to MAIL FROM
misuse by the SPF draft proposal.
 
> > xyzzy.claranet.de       text = "v=spf1 redirect=claranet.de"
> > which appears to point to:
> > claranet.de     text = "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"
> 
> 212.82.225.86 is a perfect match for 212.82.225.0/23, result
> "pass".  Congratulations, it was no mail worm or spammer, it
> was apparently me (modulo screwups at this ISP).
> 
> > At various points in transport
> 
> No, you don't check SPF whereever you like it.  SPF defines
> the border of the sender, the only point where that makes any
> sense at all is your border.

And this is specified (using "only" and "MUST") in which section(s) of
the draft under discussion?  I also seem to be having trouble locating
the supposed definition of "border" in the draft -- I see 5 instances of
the word, all within 1/3 of a page from one another, none of which
provides anything remotely like a definition, much less a reliable
mechanism for determining where it lies.

I do see:
   Typically, such checks are done
   by a receiving MTA, but can be performed elsewhere in the mail
   processing chain so long as the required information is available and
   reliable.  At least the "MAIL FROM" identity MUST be checked,

Any of the places corresponding to Received header field lines correspond
to "a receiving MTA", which is the typical case specified in the draft
(it does not involve the "elsewhere" hatchway).

> You can't check it behind your 
> border, you check it at mx23.mrf.mail.rcn.net

Unless "xyzzy.claranet.de" is now a subsidiary of "rcn.net" or vice-versa,
that is *NOT* "the border of the sender".  Nor is it *MY* border.  And if
one does check at "the border of the sender", the client IP address is (as
noted earlier, but not quoted by you) 62.80.58.103, which doesn't match
the supposed sender SPF IP address ranges.

To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt 
From: [email-masked]
Date: Tue, 24 May 2005 14:15:28 -0400
Sender: [email-masked]

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

On Tue, 24 May 2005 19:05:22 +0200, Frank Ellermann said:

> No, you don't check SPF whereever you like it.  SPF defines
> the border of the sender, the only point where that makes any
> sense at all is your border.  You can't check it behind your
> border, you check it at mx23.mrf.mail.rcn.net

So it defines the border of the *sender*, and then the *receiver*
border box has to do the check?  Somehow that seems mildly busticated.
Maybe it should define the receiver border as well?

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

--==_Exmh_1116958527_3605P--

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Tue, 24 May 2005 19:05:22 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 195
Sender: [email-masked]

Bruce Lilly wrote:

> 154 people. Out of approx. 10 billion.  Unimpressive.

If it's more than USEFOR + LTRU + CLEAR + MASS + ASRG
I'd be mildly impressed.  Completely beside the point,
better check out who wrote this:

http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00329e.html

> MAIL FROM remains unchanged during transport

After so much talking about 1123 5.3.6(a) I'm certain
that you also know (b).  You've reviewed email-arch-04
here on this list less than six weeks ago, it explains
"mediator", probably a better term than "1123 5.3.6".

> attempts to assign a relationship between domain names
> and IP addresses for sending email

s/attempts/allows/

 [POSIX timestamp]
> Would that be the one that fails to account for leap seconds?

Yes - better check it if this was no rhethorical question,
I'm not sure => if and only IIRC 24*60*60 seconds per day.

> It has been asserted that some hosts lack the capability
> to determine time (e.g. see the RFC 2476 successor draft)

My own box does not really know its time zone, for some
hours at the begin and end of DST it's seriously confused.
Until I fix it.  With funny effects like an online idle
timeout deciding to cut the connection.

An RfC 3339 timestamp would have the same problem here.

Rather irrelevant for the draft, it's only an optional
timestamp in an optional explanation sent with an SMTP
reject message for result FAIL.  At the moment it says:

| if there are syntax errors in the explanation string,
| then proceed as if no exp modifier was given.

Adding "or the client cannot determine the timestamp for
a specified %{t} macro (see 8.1)" before "then" would be
no problem.

> When one asks for review of a draft intended for RFC
> publication, it is at least a common courtesy to clearly
> and unambiguously indicate the intended status.

This thread started with Wayne's article:

| My intention is that after a two week review, I will make
| a "final" revised draft and ask the IESG to consider it
| for a Proposed Standard status.

I've forwarded the question about how this can be done with
xml2rfc to the xml2rfc list.  You discussed this issue here
with Ned.  And the IANA mail header registration form said
"Status: standard", let's move on.

> the I-D tracker says one thing

The I-D tracker is the IESG's POV.  It's not always exactly
the same as the author's POV, or the RfC editor's POV, and
they are free to change their opinion.

> If you mean the current BCP 78 (RFC 3978), there are no
> errata published as of this morning

I've no idea when they publish submitted errata.  The 2069
error (PEBKAC or not) is older.  How long do you wait for
some missing slashes in 2045, a year ?  There was also a
discussion about something in 2821 here, not yet published.

>> Like you I simply quoted STD 10.
> I cited specific cases related to reality

You quoted 821, and when I did the same, you said that it's
obsolete metioning 2821.  Then I quoted 2821, and you said
that 2821 has known issues:

[...]
> it has been taken into account in the specification (RFC
> 2821) which obsoletes 821.
[...]
> There are several problems in 2821; as already noted, a
> mailbox receives mail, so the term "source mailbox" is
> devoid of meaning.  RFCs aren't always flawless.
[...]

> if you really think that source routes are in current use,
> you are deluded.

And I wouldn't need SPF.  That's the point, if STD 10 would
(still) work as designed something like RMX or SPF would be
completely unnecessary:

Bounces would take the reverse path, hop by hop.  Therefore
forwarders would make sure not to forward undeliverable
crap from unknown stragers, because they'd later be forced
to deal with the bounces.

Therefore like 551 "user ot local" existed, because a 251
accepted responsibility for later potential bounces.  And
that's the precise reason why STD 10 had it right, at least
in theory, and 1123 broke it - unintentionally but still.

> the term "source mailbox" is devoid of meaning.

It means "responsible sender":  Those who send mail, can
also receive mail, at least for potential error messages,
or as you said:

> Of course a non-null return path needs to be resolvable
> -- for the purpose of *receiving* delivery notifications.

  [set of mailout IPs for mail users @ FQDN]
>> that's the idea of RMX/SPF, it allows to define this set.

> That's at the heart of the problem -- it attempts to define
> a set which makes no sense; worse than that, it is harmful.

It does not _attempt_ to define this set, it only _allows_
to define this set.  That's a huge difference.  You are not
forced to define anything at all.  If you want to define it,
you have great flexibility.  If there's exactly one zombie
forging your address and you get the bouces, you can define
something like "v=spf1 -ip4:<zombie.cidr> ?all".

Just make sure that you're not sending from the same CIDR.
You will immediately get less bounces.  And if the zombie
is controlled by a spammer (not only a mail worm) he might
decide that abusing your address is no fun anymore, because
receivers checking SPF won't accept mails with your address
from <zombie.cidr>.  Even spammers understand this, sooner
or later, "my" spammer(s) needed about four months.

> extrapolate that to an ISP with "more than 1 million
> customer connections"

Try nslookup -q=txt gmx.de

> I see no problem with STD 3 section 5.3.6 (a)

251 without the responsibility to handle later bounces.
Just forward and forget, it hits somebody else directly.

> Return-Path: <[email-masked]>
> Received: from mr09.mrf.mail.rcn.net (EHLO mr09.mrf.mail.rcn.net) (207.172.4.28)
>         by ms07.mrf.mail.rcn.net (MOS 3.5.6-GR FastPath queued)
>         with ESMTP id GKT45663;
>         Thu, 19 May 2005 14:37:59 -0400 (EDT)
> Received: from mx23.mrf.mail.rcn.net (mx23.mrf.mail.rcn.net [207.172.4.102])
>         by mr09.mrf.mail.rcn.net (MOS 3.5.7-GR)
>         with ESMTP id CCC77732;
>         Thu, 19 May 2005 14:29:45 -0400 (EDT)
> Received: from unknown (HELO mx23.mrf.mail.rcn.net) (10.255.5.102)
>   by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:44 -0400
> Received: from gundel.de.clara.net (212.82.225.86)
>   by mx23.mrf.mail.rcn.net with ESMTP; 19 May 2005 14:29:41 -0400
> Received: from [62.80.58.103] (helo=xyzzy)
>         by gundel.de.clara.net with smtp (Exim 4.30; FreeBSD)
>         id 1DYpzH-0005K5-W5
>         for [email-masked]; Thu, 19 May 2005 20:43:16 +0200
> Message-ID: <[email-masked]>

Okay, somebody claiming to be [email-masked] sent
a mail to [email-masked]

`nslookup -q=mx erols.com` says mx.mail.rcn.net, the border
MTA is apparently mx23.mrf.mail.rcn.net.  It talked with IP
212.82.225.86 saying HELO gundel.de.clara.net, no SPF policy,
result "none".  It was MAIL FROM:<[email-masked]>

> xyzzy.claranet.de       text = "v=spf1 redirect=claranet.de"
> which appears to point to:
> claranet.de     text = "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"

212.82.225.86 is a perfect match for 212.82.225.0/23, result
"pass".  Congratulations, it was no mail worm or spammer, it
was apparently me (modulo screwups at this ISP).

> At various points in transport

No, you don't check SPF whereever you like it.  SPF defines
the border of the sender, the only point where that makes any
sense at all is your border.  You can't check it behind your
border, you check it at mx23.mrf.mail.rcn.net

            Working as designed, bye, Frank

From: [email-masked]
Cc: [email-masked], Markus Stumpf <[email-masked]>
Date: Tue, 24 May 2005 10:06:22 -0700 (PDT)
Subject: Re: misdirected bounces (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Mon May 23 2005 22:05, Markus Stumpf wrote:
> > No MTA that
> > I know of sends bounces to some random address instead of the envelope
> > sender addresses (which would of course be misdirected).

> Not MTAs perhaps, but some "vacation"-like programs do so.  Anybody who
> has ever received an "I'm out of the office" message after posting to a
> mailing list is the victim of such a program (or the dingbat it operates
> on behalf of, or of a list expander that isn't compliant with the Host
> Requirements Standard).

I haven't seen a recent example, but there was a time when some MTAs would use
the value in an Errors-to: header field in preference to what was in the MAIL
FROM.

But of course none of this corresponds to sending bounces to a random address.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: misdirected bounces (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Date: Tue, 24 May 2005 12:46:34 -0400
Cc: Markus Stumpf <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 22:05, Markus Stumpf wrote:
> No MTA that
> I know of sends bounces to some random address instead of the envelope
> sender addresses (which would of course be misdirected).

Not MTAs perhaps, but some "vacation"-like programs do so.  Anybody who
has ever received an "I'm out of the office" message after posting to a
mailing list is the victim of such a program (or the dingbat it operates
on behalf of, or of a list expander that isn't compliant with the Host
Requirements Standard).

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Envelope", yet again
Date: Tue, 24 May 2005 12:32:52 -0400
Cc: John Leslie <[email-masked]>
Sender: [email-masked]

On Tue May 24 2005 11:32, John Leslie wrote:

>    Philosophically I quite agree with Tony: I'd much prefer to use the
> term "envelope" the way I used it ten years ago. I appear to be in the
> minority.
> 
>    I can accept the need to change: what is _very_ hard to accept is
> the idea that I should replace a clear an distinct meaning with one
> which is neither clear nor distinct.
[...]
>    It would be a nice thing (TM) if we could agree on a meaning which
> _is_ clear and distinct. Otherwise, IMHO, there's a serious danger of
> miscommunication.

Like it or not -- and it's clear that you don't -- the term is overloaded
when not used with a qualifier (viz. one that distinguishes one meaning
from others).  So an unqualified "envelope" may mean one thing in the
context of a discussion exclusively about SMTP (where "SMTP envelope"
would be the corresponding qualified term) and a very different thing in
the context of a discussion about IMAP (where "IMAP envelope" would be
the corresponding qualified term).  In a general discussion of email, we
need to include not only SMTP and IMAP, but other relevant protocols,
the message format, etc.  Bottom line: if you want a meaning which is
clear and distinct, use an appropriate qualifier.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: "Envelope", yet again
Date: Tue, 24 May 2005 12:25:30 -0400
Cc: John Leslie <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 14:44, John Leslie wrote:
> 
> Bruce Lilly <[email-masked]> wrote:

> > Except for a few inconvenient facts:
> > a) "It is important to note that the header fields are not guaranteed to
> >    be in a particular order.  They may appear in any order, and they
> >    have been known to be reordered occasionally when transported over
> >    the Internet." RFC 2822, section 3.6
> 
>    Trace headers are generally prepended:

N.B. "generally" != "always and unconditionally"

>    thus giving a limited sense 
> of order -- the first "Received" header is essentially known

No. Not "known", "assumed".  And we all know what happens when one assumes.

> to have 
> been added by the last MTA before you.

> >> We SHOULD discuss on this list whether such a header can be considered
> >> a "trace field";
> > 
> > As none of the SMTP documents define "trace field" (it is defined in
> > RFCs 822, 2822), the ietf-822 mailing list might be be more appropriate.
> 
>    I don't agree. We're talking about a SMTP transport function. If we
> can't agree what we mean here, it seems pointles to take it to ietf-822.

No, the functionality is not limited to SMTP, as acknowledged in section 3.8.2
of RFC 2821: "As another consequence of trace fields arising in non-SMTP
environments, [...]".

> > Except (unlike 2821 re. Return-Path) it doesn't say what is supposed to
> > happen to the stuff at "final" delivery (which often isn't final at all),
> 
>    Except for semantic quibbles, I believe the draft does.

I find "Unless it has negotiated other arrangements" vague and open-ended.
 
>    Were we starting from scratch [...]

Well, John's draft expired in July 2004, so we might as well, as it
appears that the idea lacked traction.

> >> So, my first question to the group is, "Is there anything beyond
> >> SMTP commands and trace headers (however defined) that we want to be
> >> included when we talk of "envelope information"?
> > 
> > Everything that isn't end-to-end, user-to-user communication.
> 
>    That definition is facile, but I don't find it useful. (You prove
> my point about vagueness, BTW.)

Believe it or not, there is a reason that components are separated into
"envelope", "header", and "body", and why the application is called
"electronic mail" and not "electronic foo".  The header and body are
part of user-to-user communication (as with non-electronic mail) and the
envelope is where various markings pertaining to transport, filing, etc.
of unopened messages are placed.

>    I believe there's rough consensus that a MailingList "re-inserts"
> messages,

To the extent that any other part of the store-and-forward transport
process also does so.  The message (as indicated by invariant message
identifier) is the same message (RFC 2822 section 3.6.4).

> and that List-* fields are meaningful for list management -- 
> at both the sending and receiving end.

Yes, in the same way that routing or filing instructions, postmarks,
etc. are meaningful on physical mail envelopes.
 
>    And I further believe that any such information would be more useful
> if it were prepended than if it were interspersed in the swamp of
> headers.

As you say, "were we starting from scratch".  The existing system provides
no such guarantee.

Date: Tue, 24 May 2005 12:09:58 -0400
From: John Leslie <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: [email-masked]
Subject: Re: misdirected bounces (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Sender: [email-masked]

Markus Stumpf <[email-masked]> wrote:
> On Mon, May 23, 2005 at 09:47:52AM -0400, John Leslie wrote:
>
>> Misdirected bounces are a significant problem:
> 
> Can we please stop using the term "misdirected bounces" - at least here -
> now and forever?

   Please feel free to suggest a different term.

> There is no such thing as a "misdirected bounce".

   I thought the term appropriate: we are talking about "bounce" messages,
and they are "directed" to inappropriate mailboxes. "Misdirected" seemed
to fit...

> There are only bounces to abused and forged sender addresses.
> MTAs sending bounces to those addresses are in full compliance to each
> and every RFC.

   I quite agree that the MTAs sending these bounces are directing them
exactly as the RFCs specify. (I'm not sure, though, that such activity
can any longer be justified -- I've been on the receiving end of rather
too many recently.)

> No MTA that I know of sends bounces to some random address instead of
> the envelope sender addresses (which would of course be misdirected).

   I'd have to question whether "bounces" to random addresses would
qualify as "directed" at all. Regardless, I don't think they'd still
fit the definition of "bounce".

   (YMMV, of course...)

> ... you can NEVER EVER determine at the SMTP level FOR SURE if the
> delivery will work.

   Agreed. At best, the receiving SMTP server _might_ be able to verify
that a MailFrom mailbox is appropriate for a message it accepts.

> ... But those try to force other people to stop sending bounces at all
> and thus weaken the reliability of the Internet mail infrastructure.

   There might be a middle ground -- where a MailFrom could be marked
as "dubious" and any "bounce" generated to it could be marked with a
"possibly forged MailFrom" warning included in the headers.

   (BTW, I've recently been receiving clearly-forged emails designed
to look like bounces but obviously not related to _any_ email sent --
not just unrelated to anything a JLC customer sent.)

--
John Leslie <[email-masked]>

Date: Tue, 24 May 2005 11:50:02 -0400
From: John Leslie <[email-masked]>
To: wayne <[email-masked]>
Cc: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

wayne <[email-masked]> wrote:
> In <20050523134752.GF89934@verdi> John Leslie <[email-masked]> writes:
> 
>> There is an explicit recommendation that domains publish "... -all":
>> I recommend changing that. Instead, I strongly urge that levels of
>> disclaiming be defined from the very outset of RFC publication:
> 
> Like many subjects related to SPF, this has been hotly debated more
> than once.  There is a whole section on forwarding, along with other
> problems faced by people using SPF.  I do not think your suggests are
> accurate.  In particular, if you use SES, forwarding does not break
> with -all.  

   I think we may need to explore this last claim: that forwarding does
not break "if you use SES".

   SPF proposes to be a cooperation between SPF publishers and receiving
SMTP servers. Alas, if _both_ of these used SES -- indeed even if all
sending SMTP servers operated by the domain of the SPF publisher used
SES -- it would have no effect on whether forwarding breaks.

   Thus, any claim that SPF "doesn't break forwarding" rests upon a
presumption that parties _other_than_ the parties described in this
draft will change their behavior. This is a dangerous assumption at
best; worse, it is an assumption never made explicit in the draft.

   IMHO, the recommendation that most domains use "... -all" is an
egregiously bad one, representing a fundamental misunderstanding of
the environment we must operate in. The thought that spf-discuss has
repeatedly endorsed it worries me...

--
John Leslie <[email-masked]>

Date: Tue, 24 May 2005 11:32:15 -0400
From: John Leslie <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: [email-masked]
Subject: Re: "Envelope", yet again
Sender: [email-masked]

Tony Finch <[email-masked]> wrote:
> On Mon, 23 May 2005, John Leslie wrote:
>>
>> I believe we need to talk about SMTP-as-we-know-it, not SMTP-NG.
> 
> This is why I'm very reluctant to expand the term "envelope" to include
> any message data. We should acknowledge the deliberate ambiguity of the
> Internet message header, which contains user-level and transport-level
> information and information that is somewhere in between. By contrast the
> SMTP envelope has always been clearly defined, until recent discussions
> which have tried to fit the X.400 layering model onto Internet email's
> layering model. Unsurprisingly, the two don't match and the resulting
> architectural description doesn't work very well.

   Philosophically I quite agree with Tony: I'd much prefer to use the
term "envelope" the way I used it ten years ago. I appear to be in the
minority.

   I can accept the need to change: what is _very_ hard to accept is
the idea that I should replace a clear an distinct meaning with one
which is neither clear nor distinct. Thus, I could accept almost any
change in meaning (no flames, please: it's a change to _me_ at least)
which results in something both clear and distinct; otherwise I'd much
prefer to keep the old term for the old meaning and choose a new term
for the new meaning.

   I well understand that the natural evolution of language is towards
less clarity and distinctness. I am probably in no position to stop
that tendency. However, when _I_ use a word, it means exactly what I
want it to mean, no more and no less. ;^)

   It would be a nice thing (TM) if we could agree on a meaning which
_is_ clear and distinct. Otherwise, IMHO, there's a serious danger of
miscommunication.

--
John Leslie <[email-masked]>

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Tue, 24 May 2005 10:09:12 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 14:39, Frank Ellermann wrote:

> <http://www.OpenSPF.org/cgi-bin/openspf_pledge.cgi>

154 people. Out of approx. 10 billion.  Unimpressive.

> > the IETF and IAB generally don't like specifying
> > multiple incompatible ways to do the same thing
> 
> The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
> do very different things, SPF covers some older ideas.

They all suffer from similar problems involving the issues
described in previous messages:
1. conflating sending and receiving
2. failure to understand fundamental properties of SMTP, e.g.
   MAIL FROM remains unchanged during transport
3. attempts to assign a relationship between domain names
   and IP addresses for sending email; there is no such
   relationship
etc.

> If "the IETF" has a problem with stating the common
> practice in SPF, then "the IETF" would not have closed
> MARID only three days after a potential successor was
> proposed, don't you think ?

Post hoc, ergo propter hoc fallacy.

> > Refers to POSIX, an external standard.  Raises questions
> > about implementations.
> 
> It is in an example, ..."the same value as returned by the"...

Would that be the one that fails to account for leap seconds?
 
> Probably off by one day and it needs fixing to get UTC, but
> let's say that it's not impossible to solve this problem on
> any host with date and time.

It has been asserted that some hosts lack the capability to
determine time (e.g. see the RFC 2476 successor draft).  Note,
however, that I'm not the one making the assertion.

> > Not OK for an Experimental or Informational RFC
> 
> Now if the I-D would intend to be one of these, then it would
> of course use the corresponding status.  But the form doesn't
> have any "Status: TBD".  This stuff could be updated in the
> 48 hours if necessary.

When one asks for review of a draft intended for RFC publication,
it is at least a common courtesy to clearly and unambiguously
indicate the intended status.  Because, as noted earlier in this
discussion, the issues that a reviewer considers vary according to
the intended status.  In this case, the draft itself provides no
clue, the I-D tracker says one thing, the description of the intent
(document as-is == Informational; see also draft-iesg-info-exp-00.txt
announced yesterday) indicates another, and some text at the very
end of the request for review says yet a third thing.

The status asserted in the field registration cannot wait for final
tweaking by a vested interest (viz. the author(s)) -- it needs to
be consistent with the document status as determined by the IESG
(based at least in part on review comments).

> > something which is obsolete or harmful.
> 
> Which isn't the case after we have found that the conspiracy to
> exclude non-POSIX hosts from SMTP failed miserably.

You missed the main points -- SPF is doubly harmful to the mail
system, as noted in an earlier message.
 
> Okay, let them have fun.  My BCP 78 erratum is available at the
> RfC editor (or that's what I hope).

If you mean the current BCP 78 (RFC 3978), there are no errata
published as of this morning, and the errata page says the last
update was in October 2004.

> > You're:
> > a) confusing *typical* cases
> 
> Like you I simply quoted STD 10.

I cited specific cases related to reality, not quotes from a two
decades old, multiply amended and ultimately obsoleted document.
 
> > b) ignoring the fact that, as explained in some detail, the
> >    MAIL FROM argument is passed unchanged from one MTA relay
> >    to another during transport
> 
> Not in STD 10.  Are you now starting with RfC 1123 5.3.6 (a),
> or are you still talking about STD 10 ?

The Hosts Requirements Standard (STD 3) long ago amended RFC 821.
You have to take that into account to understand SMTP, and it has
been taken into account in the specification (RFC 2821) which
obsoletes 821.

It is an observable and verifiable fact that MAIL FROM is not
altered in transit as you suggest.  It you were right, one would
see Return-Path fields at "final" delivery with old-fashioned
source routes. A quick check of more than a thousand messages
reveals zero source routes.  I could check a larger corpus, but
that's unnecessary -- if you really think that source routes are
in current use, you are deluded.

> Wasn't it you who said that proposed standards should be moved
> to either "draft" or "historic" after at most two years ?

Not that I can recall; RFC 2026 states that the IESG is supposed
to review documents at Proposed or Draft at 24 months and at 12
month intervals thereafter.  It doesn't say that such documents
must necessarily be moved, though that's the only way for the IESG
to get the continued periodic reviews removed from their workload.
 
> That's not 20 years old, that's RfC 2821, if you like it more.

There are several problems in 2821; as already noted, a mailbox
receives mail, so the term "source mailbox" is devoid of meaning.
RFCs aren't always flawless.

> > Receipt (but not *sending*) of mail is tied to a domain name
> > by DNS MX RRs.
> 
> Check out the parts about "domain", "HELO", and "MAIl FROM" in
> RfC 2821 again, they MUST be resolvable (MX. A, CNAME), and we
> already discussed MAIL FROM:<> (see above).

Of course a non-null return path needs to be resolvable -- for the
purpose of *receiving* delivery notifications.

> > In particular, no fixed set of IP addresses is associated
> > with the sending of such mail;
> 
> Yes, that's the idea of RMX/SPF, it allows to define this set.

That's at the heart of the problem -- it attempts to define a set
which makes no sense; worse than that, it is harmful.

> If that's not what you want for erols.com just don't define it.

I don't have that option.  You might want to try some whois queries
before continuing this discussion.  You might also wish to review
my earlier comment about "an organization with 50,000 personnel",
then extrapolate that to an ISP with "more than 1 million customer
connections" (http://www.rcn.com/company/index.php).
 
> >> Domain owners
> > Bzzt. Fatal flaws. see above.
> 
> If you don't like RfC 2821 chapter 3.6 that's your choice, but
> no fatal flaw.  The only fatal flaw is RfC 1123 5.3.6 (a), and
> SPF allows to fix it for those who wish to fix it.

You'll have to be more clear; I see no problem with STD 3 section
5.3.6 (a) (and I observe that STD 3 has not been obsoleted).  Nor do
I see any relationship between alias expansion and SPF.

Let's look at a specific example of one problem with SPF; the attempt
to associate a set of IP addresses with the domain in a MAIL FROM
return path.  Consider the following message header excerpt:

Note that the return path is <[email-masked]>.  Using SPF
specification rules, the corresponding text record is:

xyzzy.claranet.de       text = "v=spf1 redirect=claranet.de"

which appears to point to:

claranet.de     text = "v=spf1 ip4:212.82.225.0/24 ip4:195.170.96.0/24 -all"

At various points in transport, the client IP addresses have included
207.172.4.28, 207.172.4.102, (RFC 1918 unroutable) 10.255.5.102, and
62.80.58.103.   At any of those times, if one were silly enough to take
notice of SPF, the message could have been rejected, as none of those IP
addresses are in the specified ranges.  Is that really what you want?

-------
  "I beseech you in the bowels of Christ, think it possible you may be mistaken"
     -- Oliver Cromwell 

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 24 May 2005 04:05:57 +0200
From: Markus Stumpf <[email-masked]>
To: John Leslie <[email-masked]>
Cc: Frank Ellermann <[email-masked]>, [email-masked]
Subject: Re: misdirected bounces (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Mon, May 23, 2005 at 09:47:52AM -0400, John Leslie wrote:
>    Misdirected bounces are a significant problem:

Can we please stop using the term "misdirected bounces" - at least here -
now and forever?
There is no such thing as a "misdirected bounce". There are only bounces
to abused and forged sender addresses. MTAs sending bounces to those
addresses are in full compliance to each and every RFC. No MTA that
I know of sends bounces to some random address instead of the envelope
sender addresses (which would of course be misdirected).

There are clueless poeple running DNSBLs like SORBS and SPAMCOP that obviously
have no idea of how mail transactions work and that you can NEVER EVER
determine at the SMTP level FOR SURE if the delivery will work.
UUCP, X.400 and a thousand of other gateways are the proof for that, as
are programs that handle user requests per email (like mailing list
managers, CRM systems, ...).
But those try to force other people to stop sending bounces at all and
thus weaken the reliability of the Internet mail infrastructure. Their
arguments are "if AOL and Hotmail managed it, why can't you?". And the
answer is really simple: Because neither AOL nor Hotmail run neither UUCP
gateways nor multihop email-gateways to satellite services like
skyfile.com (Inmarsat, Iridium and Thuraya) or others. But imagining
those kind of services is obviously beyond the limited scope of thinking
of those people.
But besides other Mail-Admins Ironport doesn't trust its own DNSBL and
doesn't use it for their customers.

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

Date: Mon, 23 May 2005 23:22:59 +0100
From: Tony Finch <[email-masked]>
To: John Leslie <[email-masked]>
cc: [email-masked]
Subject: Re: "Envelope", yet again
Sender: [email-masked]

On Mon, 23 May 2005, John Leslie wrote:
>
>    I believe we need to talk about SMTP-as-we-know-it, not SMTP-NG.

This is why I'm very reluctant to expand the term "envelope" to include
any message data. We should acknowledge the deliberate ambiguity of the
Internet message header, which contains user-level and transport-level
information and information that is somewhere in between. By contrast the
SMTP envelope has always been clearly defined, until recent discussions
which have tried to fit the X.400 layering model onto Internet email's
layering model. Unsurprisingly, the two don't match and the resulting
architectural description doesn't work very well.

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.

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Mon, 23 May 2005 22:42:45 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Cc: Hector Santos <[email-masked]>, [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Mon, May 23, 2005 at 02:47:11PM -0400, [email-masked] wrote:
> Given that these points *were* raised right at the start, and the knees
> didn't buckle,

The knees did buckle.

But there was/were
- a tight timeline
- a lot of public interest
- a large software vendor involved
- two similar and twinkling solutions
so it was deliberately ignored.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Mon, 23 May 2005 22:20:14 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 97
Sender: [email-masked]

John Leslie wrote:

> The IESG intent at the closing of MARID was that the various
> drafts be submitted by individuals for "Experimental" status.

I've never found out what the intent was of not discussing CSV
at all, and something like v=spf1 (spf2.0/mfrom) for only three
days.  After some time of being stunned I decided that it was
an experiment to prove that RfC 3710 (4.3) is incompatible with
RfC 2418 (4).  <shrug />

The damage is done, let's forget it and move on.  I also think
that e.g. MTAMARK is an excellent idea.  Couple this with say
SIQ, add draft-hutzler-spamops, 2476bis, okay, I'm dreaming :-)

> Misdirected bounces are a significant problem:

Indeed... :-(  And I have serious doubts about reporting them
as spam if the receiver didn't have a fair chance to reject
this crap (instead of bouncing).  If that somehow "encourages"
admins to delete mail, SMTP is in trouble.  That would be NOW.

> I have the impression that SPF intends to do more than this.

Sure, PASS + RHSBLs (black or white) make sense.  With a PASS
RfC 3834 works as expected (defining "oops, now I'm blocked"
as unexpected outcome).  Even C/R systems might start to work,
or let's say they are less dubious based on a PASS.

 [zone cut]
> I would recommend clarifying whether any such intent remains.

No.  I never understood what's so fatally wrong with q=ns, see
draft-newton-maawg-spf-considerations-00 (6.2) for a part of
the explanation.  The CSV trick (up to 6 queries removing the
labels left to right protecting the root servers) was a bit too
complex to be retrofitted into v=spf1 - we have no bit for an
include_subdomains=yes (old idea in an early SPF draft).

For some time I proposed to allow both ways (q=ns and left to
right, the latter with an op=nosub), but it was easier to just
drop the "zone cut" concept, because nobody had implemented it.

It was also an IESG [Discuss] => get rid of it before it bites.

> "... -all" should mean the sender _wants_ forwarding to break

That's not exactly true.  Forwarding in the sense of MUA to
MSA or smart host to mail out does of course not break (unless
somebody screws up), because SPF isn't checked there.

Forwarding in the sense of MX to scanner to MDA (or similar,
add UUCP if needed ;-) also doesn't break for the same reason.

As long as SPF is checked exactly once at the imaginary border
defined by the MX of the receiver nothing breaks.  This also
includes aliases behind the same border, and the 1123 5.3.6 (b)
style of mailing lists.

Obviously a backup MX forwarding to the primary MX needs to be
white listed, "check exactly once at your border" is a simple
rule.

Otherwise it's a case of forwarding to a third party.  With a
5.3.6 (b) scheme, SRS, etc. it still works, the only case that
"breaks" is 5.3.6 (a) if the next hop checks SPF.  And that's
behind the border of the original RCPT TO.

BTW, so far I've seen this once in a year.  It worked like a
delayed 551 "user not local" (the next hop rejected the mail,
and the 1123 5.3.6 (a) forwarder bounced it to me).

Comparing one good bounce with the 150,000 misdirected bounces
I'd say it's a deal - and I simply sent the mail again to the
forwarded-to address, this bounce was really "551-like".

Saying that the _sender wants forwarding to break_ is therefore
not correct.  Maybe the _receiver wanted forwarding to break_ :
after all he should know that he checks SPF at host B and uses
a 5.3.6 (a) forwarder host A _before_ B, that cannot work.  The
sender cannot know this, but the receiver should know it.

> Experience so far has proven that "... -all" is very
> problematic

That's not my "551-like" experience.

> My overall impression is that SPF probably strikes the wrong
> balance between ease of publishing vs. ease of checking

It's certainly not as simple as I'd like it to be, but when I
found SPF (the AOL experiment last year) it was almost ready,
and I needed "something like RMX yesterday".  SPF was the only
game in town at this moment, and that's still the case.

                             Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Mon, 23 May 2005 20:39:46 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 179
Sender: [email-masked]

Bruce Lilly wrote:

> I said "apparently"

Yes, and I explained why that appearance is wrong.

> I'm giggling.  Was that the intended effect?

<http://purl.net/xyzzy/home/test/spf-council.htm>
<http://www.OpenSPF.org/cgi-bin/openspf_pledge.cgi>

> the IETF and IAB generally don't like specifying
> multiple incompatible ways to do the same thing

The "surviving" LMAP proposals (CSV, MTAMARK, SPF)
do very different things, SPF covers some older ideas.

If "the IETF" has a problem with stating the common
practice in SPF, then "the IETF" would not have closed
MARID only three days after a potential successor was
proposed, don't you think ?  JFTR, I was an RMX friend
back in 2003, but the deployed mechanism is v=spf1 -
don't think that I like all of its baroque details,

>> ok.: | standard dotted-quad format.
> At minimum, needs a normative reference.
(to Wayne: please fix this in -02, e.g. <dotnum> in STD 10)

>> ok.: | time() function in most standards-compliant libraries.

> Refers to POSIX, an external standard.  Raises questions
> about implementations.

It is in an example, ..."the same value as returned by the"...

I quoted only the part of the four lines where I found the
string "standard" in the draft.  Yes, it raises some questions,
of course I wanted RfC 3339 in MARID.  But it was far too late
and not that important.  I'm too lazy to find RfCs using this
kind of POSIX-timestamps, I know that I've seen at least one.

> Is the specification intended to exclude such hosts from
> using the specification?

No.  With my REXX I'd use something like the following:

/**/ say 86400*( date('b') - 719162 ) + time('s')

Probably off by one day and it needs fixing to get UTC, but
let's say that it's not impossible to solve this problem on
any host with date and time.  It's only used in an _optional_
explanation string, not very critical.

(to Wayne: please remove '"exp" counted' in 10.1 - throwing
           a PermError after the result is clear is rubbish)

>> ok.: mail header registration form | Status: standard

> Not OK for an Experimental or Informational RFC

Now if the I-D would intend to be one of these, then it would
of course use the corresponding status.  But the form doesn't
have any "Status: TBD".  This stuff could be updated in the
48 hours if necessary.  Okay, you propose "historic", I doubt
that Wayne will follow your proposal.

> something which is obsolete or harmful.

Which isn't the case after we have found that the conspiracy to
exclude non-POSIX hosts from SMTP failed miserably.

 [boilerplate]
> IESG/IAOC/IPR WG's problem.

Okay, let them have fun.  My BCP 78 erratum is available at the
RfC editor (or that's what I hope).

> You're:
> a) confusing *typical* cases

Like you I simply quoted STD 10.  If that confuses you it's sad,
I think it's crystal clear.

> b) ignoring the fact that, as explained in some detail, the
>    MAIL FROM argument is passed unchanged from one MTA relay
>    to another during transport

Not in STD 10.  Are you now starting with RfC 1123 5.3.6 (a),
or are you still talking about STD 10 ?

| In any case, the SMTP adds its own identifier to the
| reverse-path.

> quoting a twenty-year old document

Yes, that's what you did.  If you don't like it just don't.

> obsoleted by a newer document (RFC 2821) that (presumably
> intentionally) does not include many of the phrases which
> you have quoted.

We can also discuss RfC 2821 if you like.  You quoted STD 10.
BTW, RfC 2821 is a proposed standard published April 2001.

Wasn't it you who said that proposed standards should be moved
to either "draft" or "historic" after at most two years ?

| Such a transaction consists of a series of commands to
| specify the originator and destination of the mail
..............^^^^^^^^^^
..........................vvvvvv
| Commands specifying the sender or recipients may include
| server-permitted SMTP service extension requests
....................vvvvvvvvvvvvvvvvvv
| It consists of an originator address (to which error reports
| should be directed)
.
That's not 20 years old, that's RfC 2821, if you like it more.

> No mention of what happens if EHLO/HELO is a literal or
> unqualified or NXDOMAIN *and* MAIL FROM is null

| This document defines a protocol by which domain owners may
| authorize hosts to use their domain name in the "MAIL FROM"
| or "HELO" identity.

It's about domain names, not domain literals, NXDOMAIN, etc.

| When the reverse-path is null, this document defines the
| "MAIL FROM" identity to be the mailbox composed of the
| localpart "postmaster" and the "HELO" identity (which may
| or may not have been checked separately before).

| Note that requirements for the domain presented in the EHLO
| or HELO command are not always clear to the sending party,
| and SPF clients must be prepared for the "HELO" identity to
| be malformed or an IP address literal.  At the time of this
| writing, many legitimate e-mails are delivered with invalid
| HELO domains.

I could quote more until we finally reach the point where it's
clear that "no sender policy => result none" in all cases, even
some pathological cases.

> Receipt (but not *sending*) of mail is tied to a domain name
> by DNS MX RRs.

Check out the parts about "domain", "HELO", and "MAIl FROM" in
RfC 2821 again, they MUST be resolvable (MX. A, CNAME), and we
already discussed MAIL FROM:<> (see above).

> In particular, no fixed set of IP addresses is associated
> with the sending of such mail;

Yes, that's the idea of RMX/SPF, it allows to define this set.
With great flexibility like say "everything but this CIDR".

If that's not what you want for erols.com just don't define it.

>> Domain owners
> Bzzt. Fatal flaws. see above.

If you don't like RfC 2821 chapter 3.6 that's your choice, but
no fatal flaw.  The only fatal flaw is RfC 1123 5.3.6 (a), and
SPF allows to fix it for those who wish to fix it.  Quite a lot
of users wish this.  Recommended reading:

<http://e-com.ic.gc.ca/epic/internet/inecic-ceac.nsf/en/gv00329e.html>

> There is no "protection"

Of course.  We're talking about TeraBytes and Billions of USD,
not peanuts.  My personal damage was 150,000 bounces and other
backscatter before "my" spammer got the SPF FAIL idea, see also

<http://mid.gmane.org/[email-masked]>

                      Bye, Frank

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt 
From: [email-masked]
Date: Mon, 23 May 2005 14:47:11 -0400
Sender: [email-masked]

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

On Mon, 23 May 2005 13:18:31 EDT, Hector Santos said:
> > There is no "protection", only
> > a) a false air of legitimacy, used by spammers
> > b) damage to legitimate users of the mail system, including but not
> >    limited to mobile users.

> It's knees would had buckled at the starting gate!

Given that these points *were* raised right at the start, and the knees
didn't buckle, I doubt that Bruce re-iterating those points would have sufficed.

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

--==_Exmh_1116874031_3973P--

Date: Mon, 23 May 2005 14:44:55 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Subject: Re: "Envelope", yet again
Sender: [email-masked]

Bruce Lilly <[email-masked]> wrote:
> On Mon May 23 2005 10:30, John Leslie wrote:
>> wayne <[email-masked]> wrote:
>>> 
>>> http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
> [...]
>> ]  The Received-SPF header is a trace field (see [RFC2822] section
>> ]  3.6.7) and SHOULD be prepended to existing headers, above the
>> ]  Received: header that is generated by the SMTP receiver.  It MUST
>> ]  appear above any other Received-SPF headers in the message. 
>> 
>> This is a very interesting idea, with some promise of enabling a
>> chain of trust.
> 
> Except for a few inconvenient facts:
> a) "It is important to note that the header fields are not guaranteed to
>    be in a particular order.  They may appear in any order, and they
>    have been known to be reordered occasionally when transported over
>    the Internet." RFC 2822, section 3.6

   Trace headers are generally prepended: thus giving a limited sense
of order -- the first "Received" header is essentially known to have
been added by the last MTA before you. (I agree, BTW, that a "Received-SPF"
header appearing first in the mish-mash of non-trace headers says nothing
dependable about when it was added.)

> b) it's easy to write "is a trace field", but that won't cause existing
>    deployed MTAs to treat it any differently from any random extension
>    field.

   I agree completely. (Which is what makes John Klensin's idea attractive.)

>> We SHOULD discuss on this list whether such a header can be considered
>> a "trace field";
> 
> As none of the SMTP documents define "trace field" (it is defined in
> RFCs 822, 2822), the ietf-822 mailing list might be be more appropriate.

   I don't agree. We're talking about a SMTP transport function. If we
can't agree what we mean here, it seems pointles to take it to ietf-822.

>> IMHO, it has become clear that we wish "envelope information" to
>> include more than the SMTP commands. (I think John Klensin had the
>> right general idea in his draft-klensin-email-envelope draft.)
> 
> Except (unlike 2821 re. Return-Path) it doesn't say what is supposed to
> happen to the stuff at "final" delivery (which often isn't final at all),

   Except for semantic quibbles, I believe the draft does.

> and while there is a provision for "downgrading", there isn't one for
> "upgrading".

   I agree with John Klensin that "upgrading" would be unwise.

> Nice try, but a simpler approach would be to wrap the originating
> user's content in a MIME message/rfc-822 wrapper and let the
> transport mechanism prepend its cruft to that wrapper.

   Were we starting from scratch, I'd have to agree.

> An MUA (or an MDA at "final" delivery) could simply discard the wrapper
> to get to the "real" content (which could be signed, encrypted, etc.
> w/o interference).

   'Twould be a better design, were we starting from scratch...

>> Unfortunately, we currently have vagueness about envelope.
> 
>> So, my first question to the group is, "Is there anything beyond
>> SMTP commands and trace headers (however defined) that we want to be
>> included when we talk of "envelope information"?
> 
> Everything that isn't end-to-end, user-to-user communication.

   That definition is facile, but I don't find it useful. (You prove
my point about vagueness, BTW.)

> Including List-* fields, the proposed Archived-At, etc.

   I believe there's rough consensus that a MailingList "re-inserts"
messages, and that List-* fields are meaningful for list management --
at both the sending and receiving end.

> In short, anything roughly analogous to markings made on the envelope
> of physical mail.

   ... which are, in fact, much more limited than we're talking about
here -- and also include all the "bounce" information that we've long
since agreed to treat as a completely separate message.

   I believe we need to talk about SMTP-as-we-know-it, not SMTP-NG.

   I further believe that most of us mean one-way-transport information
when we talk about "envelope information".

   And I further believe that any such information would be more useful
if it were prepended than if it were interspersed in the swamp of
headers.

   Anyone else want to comment?

--
John Leslie <[email-masked]>

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Mon, 23 May 2005 13:18:31 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Bruce,

You could of save us a whole *bunch* of time if you only had participated
during MARID.

It's knees would had buckled at the starting gate!

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Bruce Lilly" <[email-masked]>
To: <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>
Sent: Monday, May 23, 2005 12:00 PM
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt

> [snip]
>
> Bzzt. Fatal flaws. see above.
>
> [snip]
>
> There is no "protection", only
> a) a false air of legitimacy, used by spammers
> b) damage to legitimate users of the mail system, including but not
>    limited to mobile users.
>
> ---------
> * Gulliver's Travels, 1726.  Some things never change.  Unfortunately.
>
>

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: "Envelope", yet again
Date: Mon, 23 May 2005 13:05:44 -0400
Cc: John Leslie <[email-masked]>, wayne <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 10:30, John Leslie wrote:
> 
> wayne <[email-masked]> wrote:
> > 
> > http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
> 
> which includes:
[...]
> ]  The Received-SPF header is a trace field (see [RFC2822] section
> ]  3.6.7) and SHOULD be prepended to existing headers, above the
> ]  Received: header that is generated by the SMTP receiver.  It MUST
> ]  appear above any other Received-SPF headers in the message. 
> 
>    This is a very interesting idea, with some promise of enabling a
> chain of trust.

Except for a few inconvenient facts:
a) "It is important to note that the header fields are not guaranteed to
   be in a particular order.  They may appear in any order, and they
   have been known to be reordered occasionally when transported over
   the Internet." RFC 2822, section 3.6
b) it's easy to write "is a trace field", but that won't cause existing
   deployed MTAs to treat it any differently from any random extension
   field.

>    We SHOULD discuss on this list whether such a header can be considered
> a "trace field";

As none of the SMTP documents define "trace field" (it is defined in
RFCs 822, 2822), the ietf-822 mailing list might be be more appropriate.

> and I'd like to suggest that we do so in a context of 
> what "envelope information" means.

Oy.
 
>    IMHO, it has become clear that we wish "envelope information" to
> include more than the SMTP commands. (I think John Klensin had the
> right general idea in his draft-klensin-email-envelope draft.)

Except (unlike 2821 re. Return-Path) it doesn't say what is supposed to
happen to the stuff at "final" delivery (which often isn't final at all),
and while there is a provision for "downgrading", there isn't one for
"upgrading".  Nice try, but a simpler approach would be to wrap the
originating user's content in a MIME message/rfc-822 wrapper and let
the transport mechanism prepend its cruft to that wrapper. An MUA (or
an MDA at "final" delivery) could simply discard the wrapper to get to
the "real" content (which could be signed, encrypted, etc. w/o
interference).  No need to "downgrade", no extension required.  Existing
MIME UAs show a message/rfc-822 content, non-MIME-UA users just keep
reading to get to the content.

>    Unfortunately, we currently have vagueness about envelope.

>    So, my first question to the group is, "Is there anything beyond
> SMTP commands and trace headers (however defined) that we want to be
> included when we talk of "envelope information"?

Everything that isn't end-to-end, user-to-user communication.  Including
List-* fields, the proposed Archived-At, etc.  In short, anything roughly
analogous to markings made on the envelope of physical mail.

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Mon, 23 May 2005 11:35:29 -0500
Lines: 35
Cancel-Lock: sha1:ddyYyRCr+oplz0wmm3e1tDA6LJo=
Sender: [email-masked]

In <[email-masked]> Markus Stumpf <[email-masked]> writes:

> On Mon, May 23, 2005 at 10:19:23AM -0500, wayne wrote:
>> >    The IESG intent at the closing of MARID was that the various drafts
>> > be submitted by individuals for "Experimental" status.
>> 
>> That is fine and dandy, but irrelevant for SPF.  SPF was never adopted
>> by the MARID WG and was never a MARID I-D.  That the authors of the
>> MARID drafts chose not to submit draft-ietf-marid-protocol-* is
>> mostly their problem.
>
> http://blog.gmane.org/gmane.ietf.asrg.smtpverify
> [...]
>     We are planning on submitting the proposals as experimental RFCs and the
>     LMAP discussion document as informational RFC. The following proposals
>     will be submitted:
>[...]
>
> This was confirmed by the IESG (can't find the meeting minutes right now).

Indeed, that is what I remember also.  They were supposed to be
submitted early on, but to the best of my knowledge, this never
happened.  I don't know why.

Anyway, maybe you feel differently about your I-D, but I don't either
your MTAMark proposal nor SPF was ever adopted by MARID.  There never
was a draft-ietf-marid-* draft on them.  They weren't consider for
Proposed Standard status, like the MARID I-Ds were intended for.

draft-schlitt-spf-classic-* is really an update of
draft-mengwong-spf-*.  I would hope that the IETF would not block you
from updating your proposal either.

-wayne

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Mon, 23 May 2005 18:13:24 +0200
From: Markus Stumpf <[email-masked]>
To: wayne <[email-masked]>
Cc: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Mon, May 23, 2005 at 10:19:23AM -0500, wayne wrote:
> >    The IESG intent at the closing of MARID was that the various drafts
> > be submitted by individuals for "Experimental" status.
> 
> That is fine and dandy, but irrelevant for SPF.  SPF was never adopted
> by the MARID WG and was never a MARID I-D.  That the authors of the
> MARID drafts chose not to submit draft-ietf-marid-protocol-* is
> mostly their problem.

http://blog.gmane.org/gmane.ietf.asrg.smtpverify

    As per MARID charter, the IRTF chair and the chairs of the ASRG received
    a request from the IESG to submit the LMAP proposals and the LMAP
    discussion document to the RFC Editor for publication.

    We are planning on submitting the proposals as experimental RFCs and the
    LMAP discussion document as informational RFC. The following proposals
    will be submitted:

    MTAMARK - draft-stumpf-dns-mtamark-01.txt
    DRIP - draft-brand-drip-02.txt
    RMX - draft-danisch-dns-rr-smtp-03.txt
    DMP - draft-fecyk-dmp-01.txt
    SPF - draft-mengwong-spf-00.txt
    FSV - draft-levine-fsv-00.txt

This was confirmed by the IESG (can't find the meeting minutes right now).

	\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: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Mon, 23 May 2005 12:00:46 -0400
Cc: Frank Ellermann <[email-masked]>
Sender: [email-masked]

On Mon May 23 2005 04:23, Frank Ellermann wrote:
> 
> Bruce Lilly wrote:
> 
> > the draft attempts to document a version which has apparently
> > been superseded.
> 
> No, that's not the case.

I said "apparently", and that's based on registered IESG comments:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0

> > If the intent is in fact to change the intended status from
> > Experimental (I-D tracker) to Standards Track (as stated by
> > the author in the predecessor of this message; see below)
> 
> Yes, TTBOMK that's the intent (in fact I'm almost sure, I've
> seen the unanimous resolution of the SPF Council).

Ooh, a "Council".  Not an IETF WG.  Not a recognized SDO.  I'm
not impressed.  I'm giggling.  Was that the intended effect?

Anyway, the intended status is an important issue.  Other than
Experimental documents, when there is no clear consensus on similar
competing methods to do essentially the same thing (and in the case
of this subject matter, all making essentially the same errors), the
IETF and IAB generally don't like specifying multiple incompatible
ways to do the same thing; see RFC 1958, but note that extensible
protocols such as those which provide multiple message digest
algorithms within a single protocol framework are a subtly distinct
case.  The author's statement was that he wished to document
something and he appeared to be adamant that no changes to the
specification would be entertained.  That would be an Informational
document.   Standards Track is another matter, and has been discussed
in a previous message.  It doesn't seem to be a viable option. 

> > Use of the word "standard" is going to cause problems
> 
> ok.: | standard dotted-quad format.

At minimum, needs a normative reference.  Is it supposed to include
or exclude the brackets which are used in email contexts (RFCs 821,
822, 1123, 2821, 2822)?

> ok.: | time() function in most standards-compliant libraries.

Refers to POSIX, an external standard.  Raises questions about
implementations.  N.B. there are many non-POSIX hosts on the Internet.
Is the specification intended to exclude such hosts from using the
specification?

> ok.: mail header registration form | Status: standard

Not OK for an Experimental or Informational RFC, nor for something
which is obsolete or harmful.

> ok.: ipr=full3978 IETF boilerplate | this standard.

IESG/IAOC/IPR WG's problem.  Whether or not it's OK depends on the
usual relevant issues ("whether the said cow were red or
black, her horns long or short, whether the field I graze her in be
round or square, whether she was milked at home or abroad, what
diseases she is subject to, and the like" [*]), and I suppose we
can expect the problem to be resolved in due course ("in ten, twenty,
or thirty years" [ibid.]).  But I digress...
 
> > The MAIL FROM argument specifies a return path for
> > delivery-related notifications.
> 
> Already discussed on the 822 list, I quote the relevant part:
> 
> |> "reverse-path which can be used to report errors" (STD 10)
> |
> | Yes, it "specifies who the mail is from", "a return route (which
> | may be used to return a message to the sender when an error
> | occurs with a relayed message)", "contains the source mailbox",
> | "a reverse source routing list of hosts and source mailbox",
> | "a source route from the current location of the message to the
> | originator of the message)".   Finally "send it to the originator
> | of the undeliverable mail (as indicated by the reverse-path)".
> |
> | Want more ?  I skipped some less CLEAR "should", but when I said
> | *_criminal negligence_* about any "bounces-to" I was NOT joking.
> 
> You pick your STD 10 cherries, I pick mine, shall we count ?

You're:
a) confusing *typical* cases ("who the mail is from") with the
   underlying assumption in the draft scheme that that is *always*
   the case -- it is not, and that erroneous assumption (coupled
   with an unworkable attempt to tie it to a set of IP addresses)
   is a fatal flaw.
b) ignoring the fact that, as explained in some detail, the MAIL FROM
   argument is passed unchanged from one MTA relay to another during
   transport; each relay has a different IP address, and the specific
   path is in general unpredictable in advance.  Another fatal flaw.
c) ignoring the problem that the assumption conflates sending with
   receiving (of delivery notifications). A third fatal flaw.
d) quoting a twenty-year old document which was written in reference
   to a network topology that no longer applies, and which has been
   obsoleted by a newer document (RFC 2821) that (presumably
   intentionally) does not include many of the phrases which you have
   quoted.
e) quoting phrases (e.g. "source mailbox") which are devoid of meaning
   ("A mailbox receives mail"; a mailbox does not "source" mail).

> > Indeed, a null path is required in some cases to prevent
> > damaging mail loops.
> 
> Addressed in the draft.

As noted, begrudgingly and partially addressed.  No mention of
what happens if EHLO/HELO is a literal or unqualified or NXDOMAIN
*and* MAIL FROM is null -- the draft says to consult MAIL FROM
(see flaws above) in the assumption that there is always something
relevant there.

> There's also no problem with say "creative" HELOs like my MUA
> claiming to be "xyzzy", because there's no FQDN "xyzzy", and
> my MUA talks only with its smart hosts, not with arbitrary MXs.

What happens to work for you is
a) not necessarily applicable Internet-wide (and therefore
   unsuitable as an Internet Standard)
b) non-conforming (SMTP *REQUIRES* an FQDN or address literal),
   and therefore unsuitable as a basis for an Internet Standard)
 
> Skipping some cases where domain owners

The concept of "domain owners" as it applies to the assumptions
in the draft is another set of fatal flaws.  All mailboxes (N.B.
"a mailbox receives mail", it does not *send* mail) contain a
domain name.  Domain names may be registered, and a domain name
is assigned to (not "owned" by) a registrant.  Receipt (but not
*sending*) of mail is tied to a domain name by DNS MX RRs.  While
the domain name "erols.com" is assigned to a particular registrant
who operates SMTP receivers and publishes MX records to appropriately
direct mail for the purpose of *receiving*, neither that domain name
nor the registrant necessarily has anything whatsoever to do with the
*sending* of mail which happens to specify a mailbox with that domain
name for *receipt* of delivery notifications.  In particular, no fixed
set of IP addresses is associated with the sending of such mail;
while mail is sent (*if* sent "with" SMTP "via" TCP) by an SMTP client
which has an IP address, it is in no way sent "from" a domain, nor is
any relationship between sending mail and a set of IP addresses in any
way specified by SMTP or any related Internet Standard.

> > As noted in some detail above, the described mechanism is
> > incompatible with SMTP as standardized, widely deployed, and
> > used for mission-critical purposes by an extremely large and
> > diverse community of users on the Internet
> 
> That's not the case.  Domain owners

Bzzt. Fatal flaws. see above.

> > Any mechanism which shares those characteristics
> > (favorable to spammers, harmful to legitimate users) is
> > doubly harmful to the email system.
> 
> Spammers are indeed the only non-volunteers in this mechanism,
> it's just working as designed.  They can't forge protected
> addresses anymore without losing parts of their "audience".

There is no "protection", only
a) a false air of legitimacy, used by spammers
b) damage to legitimate users of the mail system, including but not
   limited to mobile users.

---------
* Gulliver's Travels, 1726.  Some things never change.  Unfortunately.

To: John Leslie <[email-masked]>
Cc: wayne <[email-masked]>, [email-masked]
Subject: Re: proposed Received-SPF trace header 
From: [email-masked]
Date: Mon, 23 May 2005 11:37:53 -0400
Sender: [email-masked]

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

On Mon, 23 May 2005 10:30:18 EDT, John Leslie said:

> ] 7.  The Received-SPF header field
> ]
> ]  It is RECOMMENDED that SMTP receivers record the result of SPF
> ]  processing in the message headers.  If an SMTP receiver chooses to do
> ]  so, it SHOULD use the "Received-SPF" header defined here for each
> ]  identity that was checked.  This information is intended for the
> ]  recipient.  (Information intended for the sender is described in
> ]  Section 6.2, Explanation.)

We may be able to dodge the bullet on this one, by suggesting that the results
of the SPF check be encoded in the Received: header in a manner analogous to
the current logging of STARTTLS. Given the issues listed in sections 9.3 through
9.5 of the draft, this *isn't* something that "most" hops will include - the message
I'm replying to has 8 Received: headers, of which only 2 could possibly have a
sensible result to an SPF check....

>    We SHOULD discuss on this list whether such a header can be considered
> a "trace field"; and I'd like to suggest that we do so in a context of
> what "envelope information" means.

We should probably do this anyhow...

>    Unfortunately, we currently have vagueness about envelope.
> draft-crocker-email-arch discusses:

By fixing this document as required....

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

--==_Exmh_1116862673_3973P--

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Mon, 23 May 2005 10:19:23 -0500
Lines: 96
Cancel-Lock: sha1:Hy2ttjZaJqscbeR0bMzBiAuDOP0=
Sender: [email-masked]

In <20050523134752.GF89934@verdi> John Leslie <[email-masked]> writes:

> Frank Ellermann <[email-masked]> wrote:
>> 
>> After MARID was closed Mark Lentczner and Wayne Schlitt resumed
>> the work on Meng Wong's "classic" (v=spf1) draft, and that's
>> what you see here.
>
>    The IESG intent at the closing of MARID was that the various drafts
> be submitted by individuals for "Experimental" status.

That is fine and dandy, but irrelevant for SPF.  SPF was never adopted
by the MARID WG and was never a MARID I-D.  That the authors of the
MARID drafts chose not to submit draft-ietf-marid-protocol-* is
mostly their problem.

>    IMHO, "Experimental" should mean that details will be diddled during
> the experiment. Nonetheless, the Abstract may be misleading:
> " 
> " This document describes version 1 of the SPF protocol, whereby a
> " domain can explicitly authorize the hosts that are allowed to use
> " its domain name in a reverse-path...
>
>    The draft in fact describes other uses of the v=spf1 record than
> checking the reverse-path. I believe this should be noted in the
> abstract.

Hmm...  Good point.  I'll fix that. Thanks.

>>> The MAIL FROM argument specifies a return path for
>>> delivery-related notifications.
>
>    Misdirected bounces are a significant problem: I do not wish to
> get in the way of any experiments to reduce the problem. But I have
> the impression that SPF intends to do more than this.

Yes, I would say your impression is correct.  Many people support SPF
for many different reasons.  Reducing bogus bounces is one reason, but
certainly not the only reason.  For me, it is far from the most
important reason.

>> There's also no problem with say "creative" HELOs like my MUA
>> claiming to be "xyzzy", because there's no FQDN "xyzzy", and
>> my MUA talks only with its smart hosts, not with arbitrary MXs.
>
>    Indeed, as we get into the text, it becomes clear than SPF intends
> the same v=spf1 record to be used to check HELO strings.
>
>    In fact, the draft _requires_ checking the HELO string if MAIL-FROM
> is null: this strikes me as a bad idea, because bounce messages are a
> very different case.

Yes, the fall back to the HELO domain has been discussed many times.
Some people think it is critical, some people don't like it.  However,
it has been part of the SPF specifications from the very beginning and
thus it seems to be a little late to change it now.

> ====
>
>    I know that earlier discussions of SPF considered the possibility
> of matching subdomains to a single SPF record (other than wildcards):
> I would recommend clarifying whether any such intent remains.

That portion has been removed because the function was not widely
implemented and the folks on namedroppers strongly objected.

>    There is an explicit recommendation that domains publish "... -all":
> I recommend changing that. Instead, I strongly urge that levels of
> disclaiming be defined from the very outset of RFC publication:

Like many subjects related to SPF, this has been hotly debated more
than once.  There is a whole section on forwarding, along with other
problems faced by people using SPF.  I do not think your suggests are
accurate.  In particular, if you use SES, forwarding does not break
with -all.  

>    My overall impression is that SPF probably strikes the wrong balance
> between ease of publishing vs. ease of checking; but that's really not
> an issue for an Experimental protocol. I will also admit to a prejudice
> that ease of establishing reputation will become critical; and this
> draft contains a number of features which will make that difficult.

Yes, I understand that your CSV proposal meets your idea of balance
better than the SPF proposal.  I think reasonable people can disagree
on which balance is better, and under which circumstances.

-wayne

Date: Mon, 23 May 2005 10:30:18 -0400
From: John Leslie <[email-masked]>
To: wayne <[email-masked]>
Cc: [email-masked]
Subject: proposed Received-SPF trace header
Sender: [email-masked]

wayne <[email-masked]> wrote:
> 
> http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt

which includes:
] 
] 7.  The Received-SPF header field
]
]  It is RECOMMENDED that SMTP receivers record the result of SPF
]  processing in the message headers.  If an SMTP receiver chooses to do
]  so, it SHOULD use the "Received-SPF" header defined here for each
]  identity that was checked.  This information is intended for the
]  recipient.  (Information intended for the sender is described in
]  Section 6.2, Explanation.)
] 
]  The Received-SPF header is a trace field (see [RFC2822] section
]  3.6.7) and SHOULD be prepended to existing headers, above the
]  Received: header that is generated by the SMTP receiver.  It MUST
]  appear above any other Received-SPF headers in the message. 

   This is a very interesting idea, with some promise of enabling a
chain of trust.

   (Of course, any chain of trust is only as strong as its weakest link;
but any trust at all could greatly improve the forwarding problem.)

   We SHOULD discuss on this list whether such a header can be considered
a "trace field"; and I'd like to suggest that we do so in a context of
what "envelope information" means.

   IMHO, it has become clear that we wish "envelope information" to
include more than the SMTP commands. (I think John Klensin had the
right general idea in his draft-klensin-email-envelope draft.)

   Unfortunately, we currently have vagueness about envelope.
draft-crocker-email-arch discusses:
" 
" Section 4.1.1 Envelope:
"" Information that is directly used by, or produced by, the MHS is
"" called the "envelope".  It controls and records handling activities
"" by the transfer service.  Internet Mail has a fragmented framework
"" for handling this "handling" information.  The envelope exists partly
"" in the transfer protocol SMTP [RFC2821] and partly in the message
"" object [RFC2822].  The SMTP specification uses the term to refer only
"" to the transfer-protocol information.
"" 
"" NOTE:
""    Due to the frequent use of the term "envelope" to refer only to
""    SMTP constructs, there has been some call for using a different
""    term, to label the larger set of information defined here.  So
""    far, no alternative term has developed any community support.
"" 
"" Direct envelope addressing information, as well as optional transfer
"" directives, are carried within the SMTP control channel.  Other
"" envelope information, such as trace records, is carried within the
"" content header fields.  Upon delivery, some SMTP-level envelope
"" information is typically encoded within additional content header
"" fields, such as Return-Path.

   (Note the "such as trace records", and "encoded within additional
content header fields"...)

   IMHO, we have a potentially-useful "envelope" entity if we limit it
to SMTP commands and trace information.

   Other mentions of "envelope" in Crocker's draft seem to fit as
SMTP:
"
" Recipient address(es) specified in the envelope
" 
" [Aliasing] resubmits the message, replacing the envelope address
" 
" An MDA that is re-posting a message to an alias typically changes
" only envelope information

or trace:
" 
" A Relay may add information to the envelope, such as with trace
" information

   (This is a bit problematic, since a Relay is likely to add information
to headers which clearly are NOT intended as envelope information.)

or both:
" A mail Relay... adds envelope-level handling information
" 
" However it does not modify existing envelope information
" 
" A message comprises a transit handling envelope
" 
" The envelope contains handling information used by the Message Handling
" Service, or generated by it
" 
" Hence an MTA implements both client and server MTA functionality.  
" It does not make changes to addresses in the envelope or
" reformulate the content, except as transfer-encoding requirements
" dictate.  Also it may add trace information.

   So, my first question to the group is, "Is there anything beyond
SMTP commands and trace headers (however defined) that we want to be
included when we talk of "envelope information"?

--
John Leslie <[email-masked]>

Date: Mon, 23 May 2005 09:47:52 -0400
From: John Leslie <[email-masked]>
To: Frank Ellermann <[email-masked]>
Cc: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

Frank Ellermann <[email-masked]> wrote:
> 
> After MARID was closed Mark Lentczner and Wayne Schlitt resumed
> the work on Meng Wong's "classic" (v=spf1) draft, and that's
> what you see here.

   The IESG intent at the closing of MARID was that the various drafts
be submitted by individuals for "Experimental" status.

   IMHO, "Experimental" should mean that details will be diddled during
the experiment. Nonetheless, the Abstract may be misleading:
" 
" This document describes version 1 of the SPF protocol, whereby a
" domain can explicitly authorize the hosts that are allowed to use
" its domain name in a reverse-path...

   The draft in fact describes other uses of the v=spf1 record than
checking the reverse-path. I believe this should be noted in the
abstract.

>> If the intent is in fact to change the intended status from
>> Experimental (I-D tracker) to Standards Track (as stated by
>> the author in the predecessor of this message; see below)
> 
> Yes, TTBOMK that's the intent (in fact I'm almost sure, I've
> seen the unanimous resolution of the SPF Council).

   (If in fact this will be considered for "Proposed Standard", I
would instead strongly urge that the draft be rewritten to match the
abstract: great confusion can be expected if records are published
with one intent and interpreted with another.)

>> The MAIL FROM argument specifies a return path for
>> delivery-related notifications.

   Misdirected bounces are a significant problem: I do not wish to
get in the way of any experiments to reduce the problem. But I have
the impression that SPF intends to do more than this.

> There's also no problem with say "creative" HELOs like my MUA
> claiming to be "xyzzy", because there's no FQDN "xyzzy", and
> my MUA talks only with its smart hosts, not with arbitrary MXs.

   Indeed, as we get into the text, it becomes clear than SPF intends
the same v=spf1 record to be used to check HELO strings.

   In fact, the draft _requires_ checking the HELO string if MAIL-FROM
is null: this strikes me as a bad idea, because bounce messages are a
very different case.

====

   I know that earlier discussions of SPF considered the possibility
of matching subdomains to a single SPF record (other than wildcards):
I would recommend clarifying whether any such intent remains.

   There is an explicit recommendation that domains publish "... -all":
I recommend changing that. Instead, I strongly urge that levels of
disclaiming be defined from the very outset of RFC publication:

- "... -all" should mean the sender _wants_ forwarding to break;

- "... ~all" should mean "please don't break forwarding";

- "... ?all" should indicate doubt whether the IP list is complete;

and the recommendation should be for the publisher to choose one of these.
Experience so far has proven that "... -all" is very problematic, since
forwarding is a receiver-level function, generally outside the control
of the sender or the sending MTA client. Nonetheless, it is clear that
"v=spf1 -all" should be an absolute disclaimer, and IMHO trying to
reduce the strength of the disclaimer for longer records is pointless.

   The "Received-SPF" header is an interesting idea, which I shall
discuss separately.

   My overall impression is that SPF probably strikes the wrong balance
between ease of publishing vs. ease of checking; but that's really not
an issue for an Experimental protocol. I will also admit to a prejudice
that ease of establishing reputation will become critical; and this
draft contains a number of features which will make that difficult.

--
John Leslie <[email-masked]>

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Mon, 23 May 2005 10:23:22 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 138
Sender: [email-masked]

Bruce Lilly wrote:

> the draft attempts to document a version which has apparently
> been superseded.

No, that's not the case.  There was an attempt to superede it
by sp2.0/mfrom published Sep 15 in draft-ietf-marid-mailfrom-00

...but let's say that three days of discussion in MARID before
it was closed were inadequate to address all issues with these
drafts.

E.g. there was never a corresponding spf2.0/helo document to
cover another feature of v=spf1.  The error handling and the
processing limits in draft-ietf-marid-protocol-03 were still
incomplete, to put it mildly.

After MARID was closed Mark Lentczner and Wayne Schlitt resumed
the work on Meng Wong's "classic" (v=spf1) draft, and that's
what you see here.

Losing a proper "protocol" draft the Sender-ID (spf2.0) folks
simply adopted the latest v=spf1 drafts for this purpose, the
syntax (excl. the version string), the error handling, and the
processing limits are identical.

The semantics is of course not identical, spf2.0/pra and v=spf1
are in fact incompatible.  But ignoring some details like HELO
you could say that sp2.0/mfrom is roughly the same as v=spf1.
Similar enough for compatibility.

There's only one syntactical improvement in spf2.0 that can't
be retrofitted into v=spf1, the "positional modifier" idea.  So
far spf2.0 doesn't use it, that's highly theoretical (see also
chapter 3.3 in draft-lyon-senderid-core-01).

> "The SPF project DOES NOT expect the IESG to review this
>  version.

...my personal Bruce-review-emulator also stumbled over this
point, I guess it's getting better. ;-)  Telling busy people
what they might wish to ignore is somewhat besides the point.

> I have copied the IESG mailing list so that the IESG can be
> kept informed of the discussion

So you destroyed the intended effect.  No problem, it's time
to nail the version issue, v=spf1 is not superseded by spf2.0.

> If the intent is in fact to change the intended status from
> Experimental (I-D tracker) to Standards Track (as stated by
> the author in the predecessor of this message; see below)

Yes, TTBOMK that's the intent (in fact I'm almost sure, I've
seen the unanimous resolution of the SPF Council).

It took not only me some time to figure out why there's not
necessarily a "last call" for "experimental" RfCs submitted by
individuals.  Anyway, this draft is long past any "experiment",
IMHO since before MARID.

> Use of the word "standard" is going to cause problems

ok.: | standard dotted-quad format.
ok.: | time() function in most standards-compliant libraries.
ok.: mail header registration form | Status: standard
ok.: ipr=full3978 IETF boilerplate | this standard.

No other string "standard" in the I-D.

> The MAIL FROM argument specifies a return path for
> delivery-related notifications.

Already discussed on the 822 list, I quote the relevant part:

|> "reverse-path which can be used to report errors" (STD 10)
|
| Yes, it "specifies who the mail is from", "a return route (which
| may be used to return a message to the sender when an error
| occurs with a relayed message)", "contains the source mailbox",
| "a reverse source routing list of hosts and source mailbox",
| "a source route from the current location of the message to the
| originator of the message)".   Finally "send it to the originator
| of the undeliverable mail (as indicated by the reverse-path)".
|
| Want more ?  I skipped some less CLEAR "should", but when I said
| *_criminal negligence_* about any "bounces-to" I was NOT joking.

You pick your STD 10 cherries, I pick mine, shall we count ?

> Indeed, a null path is required in some cases to prevent
> damaging mail loops.

Addressed in the draft.  There's also no problem with domain
literals in HELO or MAIL FROM, they don't have a sender policy.

There's also no problem with say "creative" HELOs like my MUA
claiming to be "xyzzy", because there's no FQDN "xyzzy", and
my MUA talks only with its smart hosts, not with arbitrary MXs.

Skipping some cases where domain owners may prefer to publish
no SPF sender policy, because that's of course their decision.

> As noted in some detail above, the described mechanism is
> incompatible with SMTP as standardized, widely deployed, and
> used for mission-critical purposes by an extremely large and
> diverse community of users on the Internet

That's not the case.  Domain owners wishing to use their domain
in a MAIL FROM with any IP are not forced to say "v=spf1 +all",
but of course they could if they want it.  And they could also
use say "v=spf1 -exists:{ir}.comcast.blackholes.us ?all" for a
negative statement about only some IPs.

Replace DNSBLs of your choice to fight backscatter caused by
forgeries as it pleaes you.  Or just ignore it if it doesn't
hit you.

> Any mechanism which shares those characteristics
> (favorable to spammers, harmful to legitimate users) is
> doubly harmful to the email system.

Spammers are indeed the only non-volunteers in this mechanism,
it's just working as designed.  They can't forge protected
addresses anymore without losing parts of their "audience".

A PASS from unknown strangers isn't "favourable", it only means
that it was not say my address abused by somebody else.  If you
want more meaning for a PASS you need white or black lists -
based on addresses / FQDNs, that wasn't possible without SPF.

> a scheme with so many defects

So far you found a potential flaw in the IPR boilerplate.  I've
also sent an erratum about 3978 to the Rfc editor 4 weeks ago,

                           Bye, Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Intended status (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)
Date:  Mon, 23 May 2005 08:43:11 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 25
Cc: [email-masked]
Sender: [email-masked]

Bruce Lilly wrote in <ietf-smtp.imc.org>:
 
  [intended status]
>> It is entirely inappropriate to mention it in the draft.
 
> The current version (dated March 25, 2005) of the "Guidelines
> to Authors of Internet-Drafts",
> http://www.ietf.org/ietf/1id-guidelines.html,
> explicitly provides for indicating intended status:
 
>| Indicating what status the document is aimed for is OK, but
>| should be done with the words "Intended status: <status>".
 
> It is helpful to reviewers to know what the intended status
> is, as considerations apply to Standards Track documents that
> do not apply to Experimental documents, and so on.

Some days ago there was a similar discussion about the 3066bis
I-D in LTRU.  Tests with xml2rfc and category="bcp", plus more
creative experiments, had no visible effect on the text output
for an I-D (the RfC output would be of course okay).

So maybe that's a missing feature in xml2rfc 1.29, I copy it
to the xml2rfc list, bye, Frank

From: [email-masked]
Cc: [email-masked], [email-masked], wayne <[email-masked]>, [email-masked]
Date: Sun, 22 May 2005 21:26:41 -0700 (PDT)
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Sun May 22 2005 18:15, [email-masked] wrote:

> > > The ID-tracker says that the intended status -- which is nowhere mentioned
> > > in the draft itself -- is Experimental.
> >
> > It is entirely inappropriate to mention it in the draft.

> The current version (dated March 25, 2005) of the "Guidelines to
> Authors of Internet-Drafts", http://www.ietf.org/ietf/1id-guidelines.html,
> explicitly provides for indicating intended status:

>   Indicating what status the document is aimed for is OK, but should be done
> with the words "Intended status: <status>".

Well, all I can say is I think doing in the actual document is a bad idea. And
I note that all it says is that it is OK - hardly a ringing endorsement.

> It is helpful to reviewers to know what the intended status is, as
> considerations apply to Standards Track documents that do not apply
> to Experimental documents, and so on.

That's why it is included in the last call announcement. Having it in the
document as well is an invitation to have silly states. We have too
many of those as it is.

				Ned

To: [email-masked]
Cc: Bruce Lilly <[email-masked]>, [email-masked], [email-masked], [email-masked] (SPF Council)
From: wayne <[email-masked]>
Reply-To: [email-masked]
Date: Sun, 22 May 2005 22:56:05 -0500
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

>> On Fri May 20 2005 16:15, wayne wrote:
>
>> > See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt
>
>> The ID-tracker says that the intended status -- which is nowhere mentioned
>> in the draft itself -- is Experimental.
>
> It is entirely inappropriate to mention it in the draft. The final status  of
> the draft is determined by the IESG; the status in the datatracker (and
> eventually in the last call) is the status believed to be appropriate by the
> submitter/WG. (I have seen documents last called as informational moved to
> experimental and vice versa. I've also seen documents last called for standards
> track approved as informational or experimental.)

It is my understanding that it is entirely up to the IESG to determine
the final status of an I-D.

This I-D has apparently been mistakenly swept up with the (now closed)
MARID WG I-Ds, resulting in quite a bit of confusion.  Or, at least,
I've been confused by the whole thing.

I apologize for any incorrect procedures or incorrect use of language
in the I-D.  This is the first I-D that I have attempted to see
through to an RFC.  On that note, I notice that this discussion has
been CC'ed to the IESG list.  I suspect that they get a great deal of
email, and I suspect that carrying on detailed discussions of one I-D
is not appropriate.  As a result, I've set the Reply-To: to the
ietf-smtp list and I'll carry on further conversations there.  Please
correct me if this is not what I should do.

>> Experimental in particular would seem inappropriate for another reason
>> noted in the IESG comments; viz. that the draft attempts to document a
>> version which has apparently been superseded.  Moreover, the message to
>> which this is in response claims a different intended status (see below).
>  
> IMO it is appropriate if the intent is to gain experience with the
> specification and eventually, if experience proves positive, move it onto the
> standards track. If, OTOH, the intent is to document something that's in use
> but nonstandard and there's no intention to ever place it on the standards
> track, informational is the appropriate status.

The intention of the people in the SPF community is to see this
through to an Internet Standard.  (Well, assuming that dependancy RFCs
advance before too many years pass.)

>> > Discussions about this, and previous, drafts have been taking place on
>> > the [email-masked] mailing list.  To subscribe or read
>> > the archives, see http://spf.pobox.com/mailinglist.html
>
>> > While I have been reading this mailing list for many months and will
>> > note any comments posted here, sending email to the spf-discuss list
>> > or to me personally is probably better than flooding this list.
>
>> The draft notes "The SPF project DOES NOT expect the IESG to review
>>    this version.  Instead, a two week pseudo last call will be put out
>>    to collect any final changes.  After that, a new I-D will be
>>    submitted with the expectation of an IESG review.".
>
> This statement is a best superfluous. The IESG generally only reviews drafts it
> has been reqested to review in one way or another. And while some documents can
> go to the IESG without an IETF last call (not standards-track ones, of course),
> IMO it would be entirely inappropriate for this one to. It is also entirely
> possible that multiple revisions will be needed prior to handing it off
> to the IESG.

Well, funny thing is, I have never requested that the IESG review any
of the SPF-classic I-Ds.  As I said, it appears that this I-D has been
swept up with the MARID I-Ds.  So, pardon my confusion on this
subject.

>> I have copied
>> the IESG mailing list so that the IESG can be kept informed of the
>> discussion -- if the intent is as stated not to subject the draft to
>> further public review in view of the IESG, then it would at least seem
>> appropriate to have suggested that copies of comments should be sent
>> to the IESG list.
>
> Regardless of the intention, whether or not there's a last call for further
> public review is up to the IESG. The IESG can, and often does, request last
> calls for informational or experimental documents. I think this is one that
> definitely deserves a four week last call.

As far as a Last Call goes, I completely agree that this I-D, as well
as the MARID WG I-Ds could *really* use a complete review.  This is
why I have taken it upon myself to make mention of the SPF-classic I-D
on the mailing lists that I thought were most appropriate.  I have
done this once before, earlier this year.

Unfortunately, it is my understanding that the IESG intends to omit
the Last Call for the MARID drafts.  Again, please excuse my ignorance
of the IETF process, but there appears to me that the IESG is voting
right now to advance the MARID I-Ds.

-wayne

From: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Sun, 22 May 2005 23:01:03 -0400
Cc: [email-masked], wayne <[email-masked]>, [email-masked]
Sender: [email-masked]

On Sun May 22 2005 18:15, [email-masked] wrote:

> > The ID-tracker says that the intended status -- which is nowhere mentioned
> > in the draft itself -- is Experimental.
> 
> It is entirely inappropriate to mention it in the draft.

The current version (dated March 25, 2005) of the "Guidelines to
Authors of Internet-Drafts", http://www.ietf.org/ietf/1id-guidelines.html,
explicitly provides for indicating intended status:

  Indicating what status the document is aimed for is OK, but should be done with the words "Intended status: <status>".

It is helpful to reviewers to know what the intended status is, as
considerations apply to Standards Track documents that do not apply
to Experimental documents, and so on.

From: [email-masked]
Cc: [email-masked], wayne <[email-masked]>, [email-masked]
Date: Sun, 22 May 2005 15:15:56 -0700 (PDT)
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Fri May 20 2005 16:15, wayne wrote:

> > There is a new I-D for the SPF email anti-forgery system available for
> > review.  This draft tries to document the current practices of the
> > ~1,000,000[1]
> [remainder of marketing blurb elided]

> > See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt

> The ID-tracker says that the intended status -- which is nowhere mentioned
> in the draft itself -- is Experimental.

It is entirely inappropriate to mention it in the draft. The final status  of
the draft is determined by the IESG; the status in the datatracker (and
eventually in the last call) is the status believed to be appropriate by the
submitter/WG. (I have seen documents last called as informational moved to
experimental and vice versa. I've also seen documents last called for standards
track approved as informational or experimental.)

> Experimental RFCs typically
> define a specification which is part of a research or development effort,
> not "document [...] current practices" -- that would be an Informational
> RFC (or for non-protocol issues, a BCP RFC).  In either case, there may
> be problems with the draft's use of BCP 14 imperatives and other keywords.

I've heard this argument before. I do not buy it, and in the past the IESG has
not bought it either. These terms are a specification tool, nothing more and
nothing less. Nothing about their use or non-use has anything to do with the
status of a document. For example, an informational document describing some
non-IETF protocol might be much clearer for having used MUST/SHOULD/MAY. Why
should we deny such a document access to this terms?

It is possible to use the terms inappropriately, of course. But this has
nothing to do with document status.

> Experimental in particular would seem inappropriate for another reason
> noted in the IESG comments; viz. that the draft attempts to document a
> version which has apparently been superseded.  Moreover, the message to
> which this is in response claims a different intended status (see below).
 
IMO it is appropriate if the intent is to gain experience with the
specification and eventually, if experience proves positive, move it onto the
standards track. If, OTOH, the intent is to document something that's in use
but nonstandard and there's no intention to ever place it on the standards
track, informational is the appropriate status.

The real question for this particular document is how the determination of it's
worthiness of an eventual move to the standards track is going to be made,
regardless of the status it receives now.

> > Discussions about this, and previous, drafts have been taking place on
> > the [email-masked] mailing list.  To subscribe or read
> > the archives, see http://spf.pobox.com/mailinglist.html

> > While I have been reading this mailing list for many months and will
> > note any comments posted here, sending email to the spf-discuss list
> > or to me personally is probably better than flooding this list.

> The draft notes "The SPF project DOES NOT expect the IESG to review
>    this version.  Instead, a two week pseudo last call will be put out
>    to collect any final changes.  After that, a new I-D will be
>    submitted with the expectation of an IESG review.".

This statement is a best superfluous. The IESG generally only reviews drafts it
has been reqested to review in one way or another. And while some documents can
go to the IESG without an IETF last call (not standards-track ones, of course),
IMO it would be entirely inappropriate for this one to. It is also entirely
possible that multiple revisions will be needed prior to handing it off
to the IESG.

> I have copied
> the IESG mailing list so that the IESG can be kept informed of the
> discussion -- if the intent is as stated not to subject the draft to
> further public review in view of the IESG, then it would at least seem
> appropriate to have suggested that copies of comments should be sent
> to the IESG list.

Regardless of the intention, whether or not there's a last call for further
public review is up to the IESG. The IESG can, and often does, request last
calls for informational or experimental documents. I think this is one that
definitely deserves a four week last call.

> If the intent is in fact to change the intended
> status from Experimental (I-D tracker) to Standards Track (as stated
> by the author in the predecessor of this message; see below), then
> the IESG may wish to initiate a New Last Call of at least 4 weeks
> duration in accordance with the procedures for an individual
> submission for Standards Track status as outlined in RFC 2026 (BCP 9).
 
> > I realize that the whole subject of SPF (and similar systems) has a
> > certain amount of controversy to it, but for the purposes of this
> > draft, I am very reluctant to try debate these issues.  The goal is to
> > document a de-facto standard.

> Use of the word "standard" is going to cause problems for either
> Informational or Experimental status.

Well, the term was "de-facto standard" not "standard". I don't like the term
much either and IMO it is inappropriate to say this, especially if the intent
is for this to eventually wind up as a standards-track document.

OTOH, an organization where a document labelled "draft standard" has higher
status than one labelled "proposed standard" has little to complain about when
it comes to terminology...

> I note that the document uses
> the term standard in several places, including:

> o the IPR boilerplate, which is probably inappropriate for a draft or
>   RFC intended for Experimental or Informational status, or one that
>   has been moved to Historic status.  I realize that the boilerplate
>   is not the author's handiwork, and that authors currently have zero
>   latitude to correct such errors in boilerplate according to recent
>   IETF Secretariat policy.  I mention it to bring the issue to the
>   attention of the IESG, which may choose to consider the problem.

I agree the term should be "specification" or "document" or something similar
rather than "standard". However, I also think the costs of correcting this FAR
outweight any potential benefit. At most this should be noted for correction
should there be cause to change the boilerplate to correct some more serious
problem at some point in the (hopefully distant) future.

> o in the BCP 90-derived registration template.  "Standard" status would
>   be inappropriate for an Experimental RFC, or for one which provides
>   Informational documentation of an obsoleted or otherwise undesirable
>   mechanism.  In the case of an Experimental RFC, the registration
>   should probably be in the Provisional, rather than Permanent registry,
>   and the status per BCP 90 section 4.2.1 should reflect the actual
>   intended status corresponding to the draft's publication, viz.
>   "experimental" or "informational", both of which are explicitly
>   provided for in BCP 90 section 4.2.1.  That section also provides for
>   "obsoleted" and "deprecated", which may be appropriate in accordance
>   with issues registered in IESG comments and as discussed herein.

Given the liklihood that this proposal, regardless of its final disposition,
will remain deployed for the forseeable future, I'm inclined to think
the registration should be permanent, not provisional.

> > Debates about better techniques, why
> > SPF is evil, etc. are probably best discussed on things like the IRTF
> > ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
> > separate thread/subject.

> On the contrary, I believe the IESG should have the benefit of
> community input on such matters, as that may help to gauge community
> consensus on relevant issues.  In particular, I concur with at least
> parts of the noted issues regarding "abuses" of and/or "concerns with"
> DNS as it pertains to the draft.  Public discussion in plain view of
> the IESG may also raise issues of concern which had not been previously
> brought to the IESG's attention.

Agreed. If this is to become an IETF specification it needs to be discussed
on an IETF list.

> > SPF does not directly change RFC2821 or add any extentions to SMTP.

> Indeed, one of the IESG comments suggests that a more appropriate
> mechanism might have been to use such an extension.

Which would make this much harder to deploy.

> ...

I'm not going to rehash the whole "MAIL FROM is not the sender" argument - I'm
frankly tired of doing so. Suffice it to say that this draft needs to document
the shortcomings fully and completely, as Bruce suggests. I will also add,
however, that Bruce and others who are less tired of this particular discussion
than I am would do well to suggest specific text to add or change rather than
running around this particular track for the Nth time.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date: Sun, 22 May 2005 17:21:24 -0400
Cc: wayne <[email-masked]>, [email-masked]
Sender: [email-masked]

On Fri May 20 2005 16:15, wayne wrote:

> There is a new I-D for the SPF email anti-forgery system available for
> review.  This draft tries to document the current practices of the
> ~1,000,000[1]
[remainder of marketing blurb elided]

> See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt

The ID-tracker says that the intended status -- which is nowhere mentioned
in the draft itself -- is Experimental.  Experimental RFCs typically
define a specification which is part of a research or development effort,
not "document [...] current practices" -- that would be an Informational
RFC (or for non-protocol issues, a BCP RFC).  In either case, there may
be problems with the draft's use of BCP 14 imperatives and other keywords.
Experimental in particular would seem inappropriate for another reason
noted in the IESG comments; viz. that the draft attempts to document a
version which has apparently been superseded.  Moreover, the message to
which this is in response claims a different intended status (see below).
 
> Discussions about this, and previous, drafts have been taking place on
> the [email-masked] mailing list.  To subscribe or read
> the archives, see http://spf.pobox.com/mailinglist.html
> 
> While I have been reading this mailing list for many months and will
> note any comments posted here, sending email to the spf-discuss list
> or to me personally is probably better than flooding this list.

The draft notes "The SPF project DOES NOT expect the IESG to review
   this version.  Instead, a two week pseudo last call will be put out
   to collect any final changes.  After that, a new I-D will be
   submitted with the expectation of an IESG review.".  I have copied
the IESG mailing list so that the IESG can be kept informed of the
discussion -- if the intent is as stated not to subject the draft to
further public review in view of the IESG, then it would at least seem
appropriate to have suggested that copies of comments should be sent
to the IESG list.  If the intent is in fact to change the intended
status from Experimental (I-D tracker) to Standards Track (as stated
by the author in the predecessor of this message; see below), then
the IESG may wish to initiate a New Last Call of at least 4 weeks
duration in accordance with the procedures for an individual
submission for Standards Track status as outlined in RFC 2026 (BCP 9).
 
> I realize that the whole subject of SPF (and similar systems) has a
> certain amount of controversy to it, but for the purposes of this
> draft, I am very reluctant to try debate these issues.  The goal is to
> document a de-facto standard.

Use of the word "standard" is going to cause problems for either
Informational or Experimental status.  I note that the document uses
the term standard in several places, including:

o the IPR boilerplate, which is probably inappropriate for a draft or
  RFC intended for Experimental or Informational status, or one that
  has been moved to Historic status.  I realize that the boilerplate
  is not the author's handiwork, and that authors currently have zero
  latitude to correct such errors in boilerplate according to recent
  IETF Secretariat policy.  I mention it to bring the issue to the
  attention of the IESG, which may choose to consider the problem.

o in the BCP 90-derived registration template.  "Standard" status would
  be inappropriate for an Experimental RFC, or for one which provides
  Informational documentation of an obsoleted or otherwise undesirable
  mechanism.  In the case of an Experimental RFC, the registration
  should probably be in the Provisional, rather than Permanent registry,
  and the status per BCP 90 section 4.2.1 should reflect the actual
  intended status corresponding to the draft's publication, viz.
  "experimental" or "informational", both of which are explicitly
  provided for in BCP 90 section 4.2.1.  That section also provides for
  "obsoleted" and "deprecated", which may be appropriate in accordance
  with issues registered in IESG comments and as discussed herein.

> Debates about better techniques, why 
> SPF is evil, etc. are probably best discussed on things like the IRTF
> ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
> separate thread/subject.

On the contrary, I believe the IESG should have the benefit of
community input on such matters, as that may help to gauge community
consensus on relevant issues.  In particular, I concur with at least
parts of the noted issues regarding "abuses" of and/or "concerns with"
DNS as it pertains to the draft.  Public discussion in plain view of
the IESG may also raise issues of concern which had not been previously
brought to the IESG's attention.

> SPF does not directly change RFC2821 or add any extentions to SMTP.

Indeed, one of the IESG comments suggests that a more appropriate
mechanism might have been to use such an extension.

> It does, however, allow for domain owners to say which IP addresses
> are allowed to use their domains in either the MAIL FROM or HELO/EHLO
> commands.

The MAIL FROM argument specifies a return path for delivery-related
notifications.  As such, it does not carry the semantics of the sender
(as in "Sender P[...]").  [it may coincidentally happen that the sender
wishes delivery-related notifications to be sent to a personal mailbox,
however it may also happen that such notifications are intentionally and
legitimately directed to a shared mailbox of some sort or delegated to
another person (e.g. a mail system administrator) for handling] Moreover,
except where some redirection of delivery takes place (e.g. at a mailing
list exploder), the MAIL FROM return path remains unchanged (in the
current state where source routing has been deprecated for a couple of
decades) as the message is sequentially forwarded through multiple MTAs,
each of which will necessarily have a distinct IP address.  That makes
the MAIL FROM argument unsuitable for the mechanism described above, both
because of the semantics which differ from what is claimed and the fact
that the argument remains unchanged during the store-and-forward process
which entails (possibly) multiple "hops", each with distinct and largely
unpredictable IP addresses of the sending MTAs.  Moreover, the MAIL FROM
return path is explicitly permitted to be a null path, in which case
there is no domain.  Indeed, a null path is required in some cases to
prevent damaging mail loops.

At a bare minimum, if the intent of the draft is in fact to document the
described mechanism, it should clearly delineate and emphasize those
rather serious defects in said mechanism, defects which are only
partially and begrudgingly acknowledged in the draft, and which are
undermined by language such as "It is RECOMMENDED that domains publish
SPF records".  In particular, note that no authentication "failure" can
meaningfully be attributed to any tests based on MAIL FROM argument
domain vs. IP address, for three separate reasons explained above, viz:
1. MAIL FROM path may legitimately be (required to be) null.
2. MAIL FROM path does not correspond to a well-defined set of IP
   addresses as a message traverses the mail transport store-and-forward
   process, as IP addresses vary at each "hop", whereas the MAIL FROM
   path is usually invariant.  I.e. the MAIL FROM path which is
   associated with a message does not correspond to a set of IP
   addresses of predetermined (set) size or content.
3. The MAIL FROM path is intended to specify the mailbox for *receipt* of
   delivery notifications, which may be (and often is) legitimately
   unrelated to the notion of a *Sender's* IP address (e.g. mobile users
   of the mail system, who may wish to receive delivery-related
   notification messages at one (of possibly several unrelated)
   mailbox(es) but who may send mail from essentially any IP address).

[I would add that lookup of MX records corresponding to the MAIL FROM
path, regardless of whether that would be in conjunction with an SMTP
extension, would not resolve the inappropriateness; MX records and the
return path are both intended for *delivery* (specifically of
notifications in the case of the return path) rather than the *sending*
of mail.]

The HELO or EHLO argument suffers from similar problems:
o it may specify an address literal, in which case it can trivially be
  made to correspond to a suitable record which lists that literal IP
  address.  The message to which this is in response describes the
  draft's specified mechanism as an "anti-forgery system".  The simple
  fact that an address literal may be specified in EHLO/HELO (RFC 2821)
  belies that claim; anybody can trivially specify any address literal,
  and the address need not be under the control of the true message
  originator.
o widely-deployed MUAs use a HELO/EHLO argument taken from one of
  several sources, with corresponding problems for the assumptions
  behind the described mechanism:
  1. the local host name, which is often not fully-qualified and/or is
     misconfigured.  In the former case (unqualified), the MUA may be
     unable to determine an appropriate domain qualifier, and/or the
     domain may be misconfigured.
  2. the domain from a message header originator address field (From,
     Sender, or Reply-To) may be used.  Each one carries different
     semantics, may legitimately be different from one another in a
     particular message, and may vary among messages composed by the
     same author(s) and which are entered into the transport system by
     the same entity.  The semantics of the From field are those of the
     message author(s), which may be different from the entity
     initiating transport (the sender).  The semantics of the Reply-To
     field are of a suggestion for responses and the syntax provides for
     an address-list rather than a single mailbox.  The domain of any
     mailbox within the specified address-list may legitimately be
     unrelated to those of the author(s) or the sender (e.g. for
     purposes of delegation of followup issues).  The Sender field, if
     present, may initially correspond to the person initiating
     transport, but in practice the field is sometimes altered (and
     sometimes not) during mailing list explosion and similar
     operations -- the lack of uniformity of handling makes a HELO/EHLO
     argument derived from the Sender field of dubious value at best.
  3. some fixed string which cannot easily be changed by the user; it may
     bear no resemblance to a domain, and it if does happen to do so, it
     might not correspond to any *relevant* domain name, if such a thing
     exists.
  4. some string which can be configured by a user.  A typical user will
     not even look at such configuration; many who do will have no clue
     what to use.
  Many of these issues are not under control of the users, administrators,
  software developers, and/or network operators.  The reality is that
  determining an appropriate domain name or address literal for use in an
  SMTP session is not as simple as a cursory read of the SMTP
  specification might lead a naive reader to presume (it is also true
  that commercial operation of the Internet with widespread deployment
  of mobile connectivity is a different situation from the research
  network connected via fixed hard-wired nodes that led to the
  development of the SMTP specification).
o Mobile users in particular may send mail from many IP addresses, from
  facilities including convention kiosks, transportation hub (airport,
  railway, etc.) courtesy lounges, cafes, restaurants, coffee shops,
  public libraries, public access points, hotel rooms, facilities
  provided by an unaffiliated or only loosely-affiliated entity (e.g. a
  salesman visiting a client), and so on.  Several points:
  1. It would be impractical, even where possible, to reconfigure an MUA
     or host/domain name for the temporary and often spontaneous use
     typical in such cases.  Even if a suitable host/domain name were
     known to the user, configuration mechanisms understood, etc.
  2. IP addresses may be assigned by DHCP or similar mechanisms, and may
     be unavailable to the MUA or user (e.g. hidden behind NAT, where the
     DHCP-assigned IP address may be unroutable).
  3. It is easy for scheme proponents to wave their hands and say things
     like "use your ISP's MTA as a relay", "set up a VPN", etc., but such
     comments simply ignore the realities of port 25 blocking and similar
     issues as well as further conflating the *sending* of email with an
     ISP who provides MX records and other resources for the *receipt* of
     email.
  ...

> SMTP servers (SPF clients) that choose to listen to domain 
> owners

   ...
   4. Any "domain owners" whose users (ISPs' customers, organizations'
      staff, etc.) might travel, ever, cannot meaningfully specify IP
      addresses associated with sending of mail, as that might happen
      from unpredictable IP addresses as noted above w.r.t. mobile users.
      Likewise for organizations which provide courtesy Internet access
      for users, customers, etc. (hotels, transportation providers,
      convention sites, public access points, restaurants & cafes, etc.).
      Note for example that an organization with 50,000 personnel,
      49,999 of whom stay put cannot publish a fixed set of IP addresses,
      as that would screw things up for the one person who travels.
      Likewise for an ISP who wishes to do business with customers who
      travel.
   5. Some domain names exist for the sole purpose of specifically
      having a registered domain name which can be placed in SMTP
      HELO/EHLO (because, as noted above, an address literal which
      corresponds to a routable IP address and/or a suitable domain name
      corresponding to a routable IP address cannot always be determined,
      and SMTP compliance requires either a literal or a fully-qualified
      domain name.  Such domain names may have no associated MX records,
      and any IP addresses associated with those domain names in the DNS
      may be artifacts of domain name registration procedures (and/or
      registrar marketing methods).  Indeed, the hosts at those IP
      addresses may be incapable of sending mail, and might not be under
      the control of the registered domain name holder.

> can use this information to accept or reject email or use as 
> input into a spam scoring system.

At a minimum, the draft should also clearly document and emphasize those
problems associated with the described mechanism of associating IP
addresses with an EHLO/HELO argument.  As with the MAIL FROM issues, the
draft currently only begrudgingly acknowledges a small part of the
problem, and undermines even that with BCP 14 language that runs counter
to common sense in light of the problems with the mechanisms. 

As noted in some detail above, the described mechanism is incompatible
with SMTP as standardized, widely deployed, and used for mission-critical
purposes by an extremely large and diverse community of users on the
Internet which has evolved from the research network on which SMTP was
first developed and implemented.  [As an aside, it may very well be the
case that no similar mechanism may be suitable for use with SMTP, as SMTP
as deployed lacks some of the semantics incorrectly attributed to parts
of the protocol by this and other mechanisms, and has as a fundamental
premise that it explicitly provides for communication with no prior
arrangements.]

It is widely known that SPF is much more widely used by spammers to lend
the false air of legitimacy which is claimed for SPF to their missives
than it is used by legitimate email users.  SPF as described and
specified is in fact favorable to spammers for that reason, while
simultaneously causing trouble for legitimate email users as detailed
above.  Any mechanism which shares those characteristics (favorable to
spammers, harmful to legitimate users) is doubly harmful to the email
system.

> As such, there is a lot of stuff in 
> this I-D that could use a lot of review from SMTP experts.

You say you are reluctant to debate the shortcomings of SPF (many of
which are shared by similar schemes), yet you ask for review.  About the
only way that makes sense is to use the review to document the flaws in
SPF.

Which brings this discourse full circle -- a scheme with so many defects
is probably not something the IETF should encourage for experimental use.
It may, however, be suitable to document the failed experiment as an
Informational document pointing out the issues.  As such, a custom IESG
Note stating that the specification is not a candidate for any level of
Internet Standard, pointing out that the mechanism described interacts
badly with established Internet Standards (DNS and SMTP), and disclaiming
fitness or noting unsuitability of the described mechanism may be
appropriate.  The only factor making Historic status unsuitable is the
fact that RFCs get to Historic status from the Standards Track (RFC 2026),
whereas the mechanism described in the draft has not been suitable for
Standards Track status...

> My intention is that after a two week review, I will make a "final"
> revised draft and ask the IESG to consider it for a Proposed Standard
> status. 

That makes no sense at all.  The I-D tracker says Experimental, and you
have characterized the intent as documentation.  Proposed Standard would
be appropriate for Standards Track entry for a specification that has no
known technical omissions, is believed to be well-understood, has resolved
known design choices, is considered valuable, and is suitable for
deployment with a goal of development and eventual full Standard status.
I believe that SPF as described above and in the draft fails on all of
those points.

---------
  A strong conviction that something must be done is the parent of many
  bad measures. -- Daniel Webster

Date: Fri, 20 May 2005 17:39:08 -0700
To: Markus Stumpf <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Cc: [email-masked]
Sender: [email-masked]

SMTP server that disconnects after seeing an unrecognized command.

At 09:43 PM 5/20/2005 +0200, Markus Stumpf wrote:
>David MacQuigg wrote:
>
> > Can you give me some example domains, so I can do an experiment?
>
>moebius.space.net does it.

Wierd.  It says:
502 unimplemented. No further commands will be accepted.  Good bye. (#5.5.1)

Anyway, we will follow the proper procedure in getting a service extension, 
and not send the command if the receiver doesn't support it.  Thanks for 
the example.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: [email-masked]
From: wayne <[email-masked]>
Subject:  SPF I-D for review: draft-schlitt-spf-classic-01.txt
Date:  Fri, 20 May 2005 15:15:05 -0500
Lines: 52
Cancel-Lock: sha1:6y8SqMlCWVIDLKQRou5z2FsEdw8=
Sender: [email-masked]

fyi;

There is a new I-D for the SPF email anti-forgery system available for
review.  This draft tries to document the current practices of the
~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
systems that are checking 20-100million emails per day.

See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-01.txt

Discussions about this, and previous, drafts have been taking place on
the [email-masked] mailing list.  To subscribe or read
the archives, see http://spf.pobox.com/mailinglist.html

While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.

I realize that the whole subject of SPF (and similar systems) has a
certain amount of controversy to it, but for the purposes of this
draft, I am very reluctant to try debate these issues.  The goal is to
document a de-facto standard.  Debates about better techniques, why
SPF is evil, etc. are probably best discussed on things like the IRTF
ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
separate thread/subject.

SPF does not directly change RFC2821 or add any extentions to SMTP.
It does, however, allow for domain owners to say which IP addresses
are allowed to use their domains in either the MAIL FROM or HELO/EHLO
commands.  SMTP servers (SPF clients) that choose to listen to domain
owners can use this information to accept or reject email or use as
input into a spam scoring system.  As such, there is a lot of stuff in
this I-D that could use a lot of review from SMTP experts.  Quite a
few of you have already made many reviews of it over the last year or
so, and I would like to thank you for doing so.

My intention is that after a two week review, I will make a "final"
revised draft and ask the IESG to consider it for a Proposed Standard
status. 

-wayne

[1] These numbers are estimates as of earlier this year.  They were
pretty solid back then, and have probably grown since.  I have data
to back them up and they are almost certainly underestimating the real
numbers.

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Fri, 20 May 2005 21:57:58 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: Re: Who will lead the fight for email authentication
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, May 17, 2005 at 05:23:36PM -0700, David MacQuigg wrote:
> My first choice is a solution that is entirely voluntary.  If that doesn't 
> happen, then some large organization is going to have to give it a 
> push.

I will never support a registry and depend on it for blocking or
accepting emails that is based on only one organization/company. And the
same holds for a registry that is based on companies from only one country.

If the chief of government of this country declares that all messages from
another country or comapny are a "seed of the evil" he will force the
company to delist their mailservers.
However there are things about which I like/trust my opinions more than
those of others. And I don't think I am the only one.

	\Maex

P.S. There is no USA bashing intended with this post. I do think there
     are at least some dozen other countries where this could happen
     in total analogy and I fear Germany would be one of them: a local
     government forces ISPs to deny access to webpages that deny
     what happend during WWII (which is forbidden by law in Germany).
-- 
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"

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Fri, 20 May 2005 21:43:29 +0200
From: Markus Stumpf <[email-masked]>
To: David MacQuigg <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Sender's Declaration of Identity
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

> >think it is wise for people to set such limits to 1, but I've seen several
> >people do it.

It catches the problem where spammer abuse gateways/proxies and
the first command that comes in is something like POST followed
by a perfectly valid SMTP conversation. This happens (in out case happend ;)
frequently with open HTTP proxies.

> Can you give me some example domains, so I can do an experiment?

moebius.space.net does it.
You better not send a XXXX or POST command as it will immediately cause
the sending IP to be blacklisted.

[ no, this is not an easy way for anyone to cause a server to be
  blacklisted, as I know of no way a message can influence the
  SMTP server to send commands like "POST" or "XXXX". And if the
  MTA can be tricked to send it, it is probably worth being listed. ;)
  If the IP the MTA runs on can be tricked to open a SMTP connection
  and send the commands I don't want to talk to it either.  ]

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

Date: Wed, 18 May 2005 16:23:08 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Declaration of Identity - Ready for Submission
Sender: [email-masked]

I've made some changes, hopefully addressing all the issues that were 
raised in the other threads, and I think this is ready to submit as 
draft-macquigg-authent-declare-00.  I have posted at 
purl.net/macquigg/email versions in txt, rtf, and htm formats.  The rtf and 
htm formats show the changes with a yellow highlight.  There is a brief 
summary of these changes right after the table of contents.

Changes
   5/16 SMTP Service Extension - Added statement in section 4 and example 
in IANA Considerations section.
   5/18 Clarifying the relationship between the declared ID and the IDs 
assumed by various methods - section 4.
   5/18 Added example to clarify how a standard ID declaration avoids DNS 
"hunting" - New section 5.

Let's keep this thread short and on-topic.  If you feel we didn't finish an 
earlier discussion, please append to that discussion, or email me.

I appreciate the help everyone has given me in giving this draft a thorough 
review.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Wed, 18 May 2005 07:47:10 -0700
To: [email-masked], Hector Santos <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Options for the ID Command 
Cc: [email-masked]
Sender: [email-masked]

Gentlemen,

Can we please take this discussion offline.  The original topic was a 
proposed ID command to be added to SMTP.  Now we are discussing a very old 
topic that was thoroughly discussed in the general IT press many months ago 
- Will authentication checks alone stop spam?

--
Dave

At 08:51 AM 5/18/2005 -0400, [email-masked] wrote:

>On Wed, 18 May 2005 07:54:59 EDT, Hector Santos said:
>
> > What gets me is how is the almighty paranoid, skeptic can believe the words
> > of just one news rag?
>
>Did you stop to consider the possibility that I cited *one* URL as an example,
>and didn't bother adding in another 5 paragraphs of "and in addition, my own
>measurements showed this, and Joe AOL's data showed that, and somebody
>else's data had these contradictory results yadda yadda yadda" when the
>*important* thing was "Spammers will take advantage of things that will make
>their mail more likely to be accepted".
>
>Or are you seriously expecting us to believe the contrary? The same people who
>send out large spoofed-source-address packets and use a zombied host elsewhere
>to catch the ACK and other response packets, and sharing info between spamhaus
>and zombie to get the TCP seq numbers right, just to make it *look* like the
>mail is coming from the zombie but with the effective bandwidth of the 
>big-pipe
>spamhaus. It hasn't occurred to them to stick an SPF entry on their domain, in
>the hopes it it will get some site to let their mail in? ;)
>
>But since you asked:  I checked the logs on our Listserv machine for 
>yesterday.
>Of 207 domains that actually posted something, 35 (or 16.9%) had SPF records.
>Of the 938 domains that tried to spam us, 278 (or 29.6%) had SPF records.
>
>Now please continue on what you were saying? :)
>

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: Hector Santos <[email-masked]>
Cc: David MacQuigg <[email-masked]>, [email-masked]
Subject: Re: Options for the ID Command 
From: [email-masked]
Date: Wed, 18 May 2005 08:51:57 -0400
Sender: [email-masked]

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

On Wed, 18 May 2005 07:54:59 EDT, Hector Santos said:

> What gets me is how is the almighty paranoid, skeptic can believe the words
> of just one news rag?

Did you stop to consider the possibility that I cited *one* URL as an example,
and didn't bother adding in another 5 paragraphs of "and in addition, my own
measurements showed this, and Joe AOL's data showed that, and somebody
else's data had these contradictory results yadda yadda yadda" when the
*important* thing was "Spammers will take advantage of things that will make
their mail more likely to be accepted".

Or are you seriously expecting us to believe the contrary? The same people who
send out large spoofed-source-address packets and use a zombied host elsewhere
to catch the ACK and other response packets, and sharing info between spamhaus
and zombie to get the TCP seq numbers right, just to make it *look* like the
mail is coming from the zombie but with the effective bandwidth of the big-pipe
spamhaus. It hasn't occurred to them to stick an SPF entry on their domain, in
the hopes it it will get some site to let their mail in? ;)

But since you asked:  I checked the logs on our Listserv machine for yesterday.
Of 207 domains that actually posted something, 35 (or 16.9%) had SPF records.
Of the 938 domains that tried to spam us, 278 (or 29.6%) had SPF records.

Now please continue on what you were saying? :)

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

--==_Exmh_1116420715_3369P--

From: "Hector Santos" <[email-masked]>
To: "David MacQuigg" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Options for the ID Command 
Date: Wed, 18 May 2005 07:54:59 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "David MacQuigg" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 18, 2005 1:08 AM
Subject: Re: Options for the ID Command

> Ever wonder why obvious spam mail has a *higher* rate of valid SPF records
than
> non-spam? Because spammers are even more anxious to convince you that
they're
> for real than legitimate sites are
>
> http://www.techworld.com/security/news/index.cfm?NewsID=2154
>
> SPF comes out May 2004.  Inside 6 months, spammers are using it more than
> non-spammers. Even the paranoid in me was surprised - I was expecting it
to be
> at least a year.

{Scratching head at tick-infested rate}

What gets me is how is the almighty paranoid, skeptic can believe the words
of just one news rag?

The article was a prime example of what "Harry Frankfurt" writes about in
this top selling book.  Google "Harry Frankfurt" or just click here:

            http://www.pupress.princeton.edu/video/frankfurt/

Absolutely amazing!

Your original premise is just.  Developers always need to assume the worst
case in design.  But the rest is just plain old... well, Harry explains it
pretty well.  <g>

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Wed, 18 May 2005 01:24:08 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Options for the ID Command 
Sender: [email-masked]

At 01:08 AM 5/18/2005 -0400, [email-masked] wrote:
>On Tue, 17 May 2005 19:25:12 PDT, David MacQuigg said:

We're taking this discussion off line, and we will summarize our result.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Options for the ID Command 
From: [email-masked]
Date: Wed, 18 May 2005 01:08:12 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 19:25:12 PDT, David MacQuigg said:

> We seem to be at an impasse.  There is some difference between your 
> understanding of the situation and mine, and I have no idea what that 
> difference is.  Maybe someone else can jump in at this point.

The difference is that you're designing a protocol that works when everybody
behaves, while I'm a professional paranoid who makes a good living by assuming
that *everybody* is lying through their teeth and giving the most advantageous
answer, and seeing what breaks. 

OK? You got that straight?  You're assuming that anybody who sends an ID will
be morally upright and honest.  I'm looking at it from the perspective of
"OOoooh. ID command. Nice. Shiny. I wonder what *new* ways I can use this to feed
David MacQuigg's mail server totally bogus/invented data to make him accept my
spam".

Ever wonder why obvious spam mail has a *higher* rate of valid SPF records than
non-spam? Because spammers are even more anxious to convince you that they're
for real than legitimate sites are

http://www.techworld.com/security/news/index.cfm?NewsID=2154

SPF comes out May 2004.  Inside 6 months, spammers are using it more than
non-spammers. Even the paranoid in me was surprised - I was expecting it to be
at least a year.

> Only if all your SPF parameters don't fit in the _AUTH record.  Normally, 
> that record would provide everything you need to authenticate a transfer.

(If you're a security geek, and that one sentence just make klaxons go off and
the DEFCON[1] sign went from 5 straight to 2 without stopping at 4 and 3, you can
hit <delete> now. The rest of the mail is just me spelling it out for David and
hopefully getting him up to speed)

That's exactly *WHY* your proposal is even *more* broken than I originally
thought.  It isn't *just* that you're piling all the different "identities"
into one value - you then compound it by leaving that identity under
the attacker's control.

(Hint if you want to work it out on your own before reading further - if an
'ID attacker.com' will fetch the data "X1, Y2, Z3" from _AUTH.attacker.com, then
*semantically* it's equivalent to just saying 'ID attacker.com X1, Y2, Z3' and
putting all that authenticator stuff right there on the ID and saving a DNS
lookup....  See the problem yet?)

> You will waste a bunch of DNS queries and possibly conclude this message 
> offers no authentication.  For each possible Identity 
> (mailserver7.bigforwarder.com, bigforwarder.com, sales.some-company.com, 
> some-company.com) you need to search every possible location for DNS 
> records (<Identity>, _client._smtp.<Identity>, ...), and we still haven't 
> searched all the header identities.

If you don't understand *why* all these different queries are being done,
you totally fail to understand why One Great Answer To It All won't work.

> The only records we trust are the ones in the Registry.  The Registry gets 
> its information on ratings from the rating services, and its information on 
> authentication methods from the domain owner.  It is not normally necessary 
> to make a separate query to the domain.

OK.  Let's work out an actual example...

Here's the *real* SPF entry for vt.edu:
vt.edu.                 14400   IN      TXT     "v=spf1 ip4:128.173.0.0/16 ip4:198.82.0.0/16 mx ptr a:lennier.cc.vt.edu a:lyta.cc.vt.edu a:dagger.cc.vt.edu a:vivi.cc.vt.edu a:steiner.cc.vt.edu a:zidane.cc.vt.edu ~all"
Ask any of the 5 registered NS entries for vt.edu, that's what you'll get.

We've not published a DomainKey for vt.edu, so let's pretend we have one that
starts off dk:AA34CF..

Let's say I'm an evil spammer, and I have a zombied machines on a cablemodem at
24.19.4.269.  So I send this from my hijacked cablemodem:

EHLO
ID evil-spammer.com
MAIL FROM:<[email-masked]>
... (including rfc822 signed with a DomainKey I generated that starts dk:FF973C, and
a 'From: [email-masked]'

Now you go to _AUTH.evil-spammer.com, and pull back:

	spf1:ipv4:24.19.4.269/32
        dk:FF973C....

Well.. how about *THAT*?  You fetched "all the data needed to authenticate"
from right where the ID command told you to fetch it.  Now, of *course*, if
that SPF record[2] covers exactly one IP address, and the mail's coming from
that *exact* address (out of the 4 billion possible addresses). It *must* be OK.
And look at that - I gave you a DK-signed mail, and gave you the key that goes
with it.  And the signature is valid.  Wow, this mail must *really* be OK.
I bet if you checked a 3rd authentication method, *that* one would check out
too....

What's wrong with this?  Basically, I've called you on the phone, and said
"This is George W Bush.. I want you to do something for me... If you don't
believe I'm really me, don't bother calling the White House listed number, you
should call (203) 555-1919 instead".  You call 555-1919 and not surprisingly,
the guy at the other end says "Yeah, that was really me, George W Bush..."

Kind of makes you wish you'd called the White House's listed number, doesn't
it? ;)

*now* do you see why you have to make a trip to the DNS servers listed in
the NS for vt.edu to get those records?

Write this on the chalkboard 100 times:

"I will not trust attacker-supplied pointers to attacker-supplied authentication data".

(And don't say "but you should have looked at the vt.edu _AUTH entry instead" -
you do and I'll have to hunt you down and smack some sense into you. ;)
        
> The record for rr.com includes 6 blocks of 170 IP's and 5 blocks of 4 
> each.  Read the proposal.

QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
      +4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)

Gaak.  I never would have guessed. And here I thought it was 5 servers in the
170.24/16 address space and 6 hiding in 4/8 :)

Good thing it was 170 in each block, starting from .1.  150 servers starting at
24.30.23.109[3] and 173 servers at 24.93.47.10 would have complicated this entry
immensely.

----
[1] http://www.fas.org/nuke/guide/usa/c3i/defcon.htm - Cuban Missle Crisis
we went to Defcon 2.  Seems about right.

[2] Don't even *try* to quibble over "it's an SPF for vt.edu" or "it's an SPF
for evil-spammer.com".  Either way, *I* am feeding *you* a crafted SPF that's
(a) not the one you *should* be checking and (b) I've set up to pass my hijacked
machine as OK.

[3]  and remember to DTRT at the 147th server. :)

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

--==_Exmh_1116392891_3936P--

Date: Tue, 17 May 2005 19:25:12 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Options for the ID Command 
Cc: [email-masked]
Sender: [email-masked]

At 09:47 PM 5/17/2005 -0400, [email-masked] wrote:

>On Tue, 17 May 2005 18:25:03 PDT, David MacQuigg said:
>
> > Before we get too far off track, let's recall the question - How can we
> > have a neutral ID Declaration, when the different authentication methods
> > expect different fields in an email to be the ID?
>
>Exactly the problem you're failing to solve.
>
> > Have I answered that question?
>
>No, you haven't.

We seem to be at an impasse.  There is some difference between your 
understanding of the situation and mine, and I have no idea what that 
difference is.  Maybe someone else can jump in at this point.

> > Do you understand how having an ID declaration avoids multiple
> > queries, "hunting" for DNS records?
>
>Nope. In fact, you just made me make *another* lookup to find out that you
>support SPF.  I'll still have to do the SPF queries.

Only if all your SPF parameters don't fit in the _AUTH record.  Normally, 
that record would provide everything you need to authenticate a transfer.

Do you understand what I mean by "hunting"?  Back to our previous exchange:

>On Tue, 17 May 2005 02:08:44 PDT, David MacQuigg said:
>
> >        EHLO  mailserver7.bigforwarder.com
> >        MAIL FROM:<[email-masked]>
> >
> > What do you do next?
>
>*I* get to decide that.  If I wish to do SPF checks, I perform the 
>required SPF
>checks.  If I wish to check a Yahoo-style signature, I do that. And so on.

You will waste a bunch of DNS queries and possibly conclude this message 
offers no authentication.  For each possible Identity 
(mailserver7.bigforwarder.com, bigforwarder.com, sales.some-company.com, 
some-company.com) you need to search every possible location for DNS 
records (<Identity>, _client._smtp.<Identity>, ...), and we still haven't 
searched all the header identities.

Do you understand what I am saying here?

< end of discussing on ID command >
< start of separate discussion on proposed DNS records >

>Listing the DK2 under the _AUTH is *broken* - that's something you *really*
>need to go back to the DNS *of the domain* to fetch. "Here - verify this
>purported domain using the key that's stashed someplace under my control, not
>someplace under the control of the purported domain".

The only records we trust are the ones in the Registry.  The Registry gets 
its information on ratings from the rating services, and its information on 
authentication methods from the domain owner.  It is not normally necessary 
to make a separate query to the domain.

>"Here's some PGP-signed stuff from President Bush. To prove it, I've appended
>his public key. Honest! It's really his!" :)

Read the proposal.

> > The record above was for a really huge domain, rr.com.  I'll be happy to
> > discuss with you the proposal for DNS authentication records, but first,
> > let me know that you have read the proposal.
>
>I'm glad it works for your tiny, non-complicated domain that only sources
>RR.COM and only from 11 addresses.  Let me know what the DK2 would look 
>like if
>those 11 outbound servers *also* hosted e-mail for 10K domains each 
>(remember -
>they probably need separate DK entries for each hosted domain...)

The record for rr.com includes 6 blocks of 170 IP's and 5 blocks of 4 
each.  Read the proposal.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Options for the ID Command 
From: [email-masked]
Date: Tue, 17 May 2005 21:47:12 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 18:25:03 PDT, David MacQuigg said:

> Before we get too far off track, let's recall the question - How can we 
> have a neutral ID Declaration, when the different authentication methods 
> expect different fields in an email to be the ID?

Exactly the problem you're failing to solve.

>                                                    Have I answered that 
> question?

No, you haven't.

>           Do you understand how having an ID declaration avoids multiple 
> queries, "hunting" for DNS records?

Nope. In fact, you just made me make *another* lookup to find out that you
support SPF.  I'll still have to do the SPF queries.

Listing the DK2 under the _AUTH is *broken* - that's something you *really*
need to go back to the DNS *of the domain* to fetch. "Here - verify this
purported domain using the key that's stashed someplace under my control, not
someplace under the control of the purported domain".

"Here's some PGP-signed stuff from President Bush. To prove it, I've appended
his public key. Honest! It's really his!" :)

> The record above was for a really huge domain, rr.com.  I'll be happy to 
> discuss with you the proposal for DNS authentication records, but first, 
> let me know that you have read the proposal.

I'm glad it works for your tiny, non-complicated domain that only sources
RR.COM and only from 11 addresses.  Let me know what the DK2 would look like if
those 11 outbound servers *also* hosted e-mail for 10K domains each (remember -
they probably need separate DK entries for each hosted domain...)

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

--==_Exmh_1116380832_5349P--

Date: Tue, 17 May 2005 18:47:26 -0700
To: wayne <[email-masked]>, [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Options for the ID command
Sender: [email-masked]

At 08:04 PM 5/17/2005 -0500, wayne wrote:
>In <02fa01c55b0e$3e15c110$6401a8c0@hdev1> "Hector Santos" 
><[email-masked]> writes:
>
> > ----- Original Message -----
> > From: "David MacQuigg" <[email-masked]>
> >
> >> Here is an incoming email with no ID declaration.
> >>
> >>       EHLO  mailserver7.bigforwarder.com
> >>       MAIL FROM:<[email-masked]>
> >>
> >> What do you do next if you want to authenticate this message?
> >
> > Dave,
> >
> > That should depend on the server, not the client.  However, if I think 
> where
> > you going with this (and this is not the say I agree with it),  what 
> you are
> > looking for the server expose to the client how the client can be
> > authenticated:
> >
> > The more propery way to do this today with ESMTP would be for the server to
> > expose what methods it support:
> >
> >     C: EHLO  mailserver7.bigforwarder.com
> >     S: 250-hostdomain.com,  Plesase to meet you.
> >     S: 250-SIZE 5120000
> >     S: 250-ETRN
> >     S: 250-ID SPF1 SPF2 CSV
> >     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
> >     S: 250-AUTH=LOGIN
> >     S: 250 HELP
> >
> > So for this server, it supports SPF1, SPF2 and CSV.
>
>Ok, so at this point, the phisher knows what will be required of the
>email and can choose the appropriate 2821.MAILFROM or 2822.Resent-*
>headers to make it past the authentication methods and yet minimize
>the red lights that an MUA might display.  This is good?
>
>The only thing I can see that does anything that isn't damaging is
>having the SMTP client say which methods *WILL* work, and leave it
>open for the SMTP server to decide which methods it thinks is worth
>while to check.  The SMTP server must be free to check methods that
>the SMTP client doesn't list.  In fact, checking to see if methods
>that aren't listed actually fail may be a very good idea.
>
>The only advantage I can see is that if the SMTP server is willing to
>trust the results of one of the methods that the SMTP client suggests,
>it will be able to tell if the SMTP client is lying and ban the SMTP
>client if it is.
>
>While this isn't damaging, I'm not sure that it is that useful
>either.

Wayne has a good point here.  *All* information in the ID command is 
suspect, including the ID itself.  That is one reason I would prefer not to 
load up on options at this point.  It just gives the spammer more to play 
with.  We have to do a DNS query anyway, so
let's put the choice of methods in the Registry record, along with the 
method parameters, public keys, whatever the ID owner needs to keep safe.

I will still support this proposal in spite of these problems, because 
having a neutral ID is important, and we can ignore the cruft if it 
contradicts what the DNS record says.

What if the ID is fake?  The ID owner pays the price in lowered 
reputation.  ID owners will learn very quickly to fix their Registry 
records, limiting their exposure to just the IP's they can control, and not 
allow their ID to be abused.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 18:25:03 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Options for the ID Command 
Cc: [email-masked]
Sender: [email-masked]

At 08:27 PM 5/17/2005 -0400, [email-masked] wrote:
>On Tue, 17 May 2005 16:42:27 PDT, David MacQuigg said:

Re-inserting the previous paragraph for context:

The ID declaration is independent of the method, because we defer selection 
of the method until the next step, which is the DNS query.  The response to 
that query tells you what methods the ID offers for authentication, and 
each method may place additional restrictions on other identities in the email.

For example, let's say you get an email like this:

    EHLO  mailserver7.bigforwarder.com
    ID  bigforwarder.com
    MAIL FROM:<[email-masked]>
> >
> > Checking the TXT record at _AUTH.bigforwarder.com.ID-check.net gets a 
> response:
> >
> >     svc=S1:A,M2:A,H1+:B  dmn=QR1,SPF1+5,DK2
> >     QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
> >       +4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
> >     DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
> >       o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
> >       EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
> >
> > The supported methods are QR1, SPF1, and DK2.  QR1 makes no demands on any
> > other identities.  It just says "Any IP outside these blocks is not
> > us."  SPF1 requires that either the MAIL FROM or the HELO identity match
> > the declared Identity, and DK2 calls for a signature check using the 
> public
> > key provided in this record.
>
>You're *still* missing the point.  All you've done is pushed it into a 
>*huge* DNS
>record.  Or multiple huge DNS entries, more likely.

That record is 349 bytes, well within the 512-byte DNS packet size.  The 
cost is measured in DNS queries, not number of bytes.  We minimize that 
cost by packing as much as possible into one record, putting simple methods 
like QR1 first, and in general trying to make authentications finish with 
one or fewer queries.  Fewer happens when you can use the same record for 
multiple servers, thus making the local cache effective.

Before we get too far off track, let's recall the question - How can we 
have a neutral ID Declaration, when the different authentication methods 
expect different fields in an email to be the ID?  Have I answered that 
question?  Do you understand how having an ID declaration avoids multiple 
queries, "hunting" for DNS records?

I added the detail above, just to illustrate the answer, not to start a new 
argument on DNS record formats.  It is very frustrating to answer a 
question three times and not be sure if the answers were understood.

>Describe how to configure this to support the following:
>
>1) 3 domains test1.com through test3.com, which could each be sourced from
>either mail-out.testN.com or bigforwarder.com. Test1.com and test2.com 
>support SPF, test3.com doesnt..
>In addition, test1 and test3 support your AUTH scheme, but test2.com doesnt.
>
>2) In addition, bigforwarder.com is the only host for test4.net through 
>test6.net, each
>of which has a separate DomainKey.
>
>How many _AUTH entries did you need here?
>
>OK. That too simple?
>
>Describe how to do it for Postini or Comcast.

The record above was for a really huge domain, rr.com.  I'll be happy to 
discuss with you the proposal for DNS authentication records, but first, 
let me know that you have read the proposal.  purl.net/macquigg/email - 
draft-macquigg-authent-dns.  Also, the namedroppers list might be a better 
forum for that discussion.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

To: wayne <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 21:24:10 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 19:42:09 CDT, wayne said:
> > Now if your proposed tag said:
> >
> >        ID SPF=YES,YAHOO=NO,CVS=YES
> >
> > *THAT* I can do something with (namely, short-circuit that auth method with
> > whatever I do for a 'info-not-found' for that method).
> 
> Why would you trust this?  I mean, if a phisher wants to impersonate
> big-bank.com, all they would have to do is say "ID SPF=NO,YAHOO=NO,CVS=NO".

Hmm. Good point.  An attacker could conceivably intentionally *omit* listing
an auth method that would prove him a bogon.  There's a big difference between
'SPF authoritatively failed' and 'no SPF info available'.

Damn.  :)

Maybe allow/suggest that the server randomly attempt a given auth method some
small (2%? 5%?) amount of the time, and apply punitive scores for sources that
do that?  Probably need a DCC/Razor sort of distributed system to keep track
of people trying to do this while spreading it across enough sources/destinations
so they aren't likely to be punitively scored by any single site?

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

--==_Exmh_1116379450_5349P--

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: Sender's Declaration of Identity
Date:  Tue, 17 May 2005 20:04:08 -0500
Lines: 56
Cancel-Lock: sha1:Ua6ScajNcoFDb4nn16Reyy489Fw=
Sender: [email-masked]

In <02fa01c55b0e$3e15c110$6401a8c0@hdev1> "Hector Santos" <[email-masked]> writes:

> ----- Original Message -----
> From: "David MacQuigg" <[email-masked]>
>
>> Here is an incoming email with no ID declaration.
>>
>>       EHLO  mailserver7.bigforwarder.com
>>       MAIL FROM:<[email-masked]>
>>
>> What do you do next if you want to authenticate this message?
>
> Dave,
>
> That should depend on the server, not the client.  However, if I think where
> you going with this (and this is not the say I agree with it),  what you are
> looking for the server expose to the client how the client can be
> authenticated:
>
> The more propery way to do this today with ESMTP would be for the server to
> expose what methods it support:
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-SIZE 5120000
>     S: 250-ETRN
>     S: 250-ID SPF1 SPF2 CSV
>     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
>     S: 250-AUTH=LOGIN
>     S: 250 HELP
>
> So for this server, it supports SPF1, SPF2 and CSV.

Ok, so at this point, the phisher knows what will be required of the
email and can choose the appropriate 2821.MAILFROM or 2822.Resent-*
headers to make it past the authentication methods and yet minimize
the red lights that an MUA might display.  This is good?

The only thing I can see that does anything that isn't damaging is
having the SMTP client say which methods *WILL* work, and leave it
open for the SMTP server to decide which methods it thinks is worth
while to check.  The SMTP server must be free to check methods that
the SMTP client doesn't list.  In fact, checking to see if methods
that aren't listed actually fail may be a very good idea.

The only advantage I can see is that if the SMTP server is willing to
trust the results of one of the methods that the SMTP client suggests,
it will be able to tell if the SMTP client is lying and ban the SMTP
client if it is.

While this isn't damaging, I'm not sure that it is that useful
either.

-wayne

To: [email-masked]
From: wayne <[email-masked]>
Subject:  Re: Sender's Declaration of Identity
Date:  Tue, 17 May 2005 19:42:09 -0500
Lines: 14
Cancel-Lock: sha1:77qbC3BlT72eHISY5RXfPtDV0ug=
Sender: [email-masked]

In <[email-masked]> [email-masked] writes:

> Now if your proposed tag said:
>
>        ID SPF=YES,YAHOO=NO,CVS=YES
>
> *THAT* I can do something with (namely, short-circuit that auth method with
> whatever I do for a 'info-not-found' for that method).

Why would you trust this?  I mean, if a phisher wants to impersonate
big-bank.com, all they would have to do is say "ID SPF=NO,YAHOO=NO,CVS=NO".

-wayne

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Options for the ID Command 
From: [email-masked]
Date: Tue, 17 May 2005 20:27:38 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 16:42:27 PDT, David MacQuigg said:

>     ID  bigforwarder.com
>     MAIL FROM:<[email-masked]>
> 
> Checking the TXT record at _AUTH.bigforwarder.com.ID-check.net gets a response:
> 
>     svc=S1:A,M2:A,H1+:B  dmn=QR1,SPF1+5,DK2
>     QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
>       +4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
>     DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
>       o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
>       EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
> 
> The supported methods are QR1, SPF1, and DK2.  QR1 makes no demands on any 
> other identities.  It just says "Any IP outside these blocks is not 
> us."  SPF1 requires that either the MAIL FROM or the HELO identity match 
> the declared Identity, and DK2 calls for a signature check using the public 
> key provided in this record.

You're *still* missing the point.  All you've done is pushed it into a *huge* DNS
record.  Or multiple huge DNS entries, more likely.

Describe how to configure this to support the following:

1) 3 domains test1.com through test3.com, which could each be sourced from
either mail-out.testN.com or bigforwarder.com. Test1.com and test2.com support SPF, test3.com doesnt..
In addition, test1 and test3 support your AUTH scheme, but test2.com doesnt.

2) In addition, bigforwarder.com is the only host for test4.net through test6.net, each
of which has a separate DomainKey.

How many _AUTH entries did you need here?

OK. That too simple?

Describe how to do it for Postini or Comcast.

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

--==_Exmh_1116376058_5349P--

Date: Tue, 17 May 2005 17:23:36 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Who will lead the fight for email authentication 
Cc: [email-masked]
Sender: [email-masked]

At 06:42 PM 5/17/2005 -0400, [email-masked] wrote:

>On Tue, 17 May 2005 15:02:13 PDT, David MacQuigg said:
>
> > Looks like the two most likely leaders are the FTC and Microsoft.  I don't
> > see the IETF stepping up to the plate.  The FTC will give us a technically
> > clumsy, not very effective, and legally burdensome solution.
>
>There's a lot of places the FTC doesn't have jurisdiction.  In fact, there's
>a lot of things *inside* the US it doesn't get to regulate, because the 
>commerce
>involved doesn't cross state lines....

My first choice is a solution that is entirely voluntary.  If that doesn't 
happen, then some large organization is going to have to give it a 
push.  The FTC has plenty of power to do just that, even without any 
mandates or regulations.  See purl.net/macquigg/email Registry.htm for my 
"thoughts in progress" on this issue.

Microsoft also has the power, although it will take them a lot longer 
because there is so much resentment over their tactics, and they do seem 
truly confused over what to do next.

There is also a smaller possibility that some company like Spamhaus will 
step in and do the public a big favor.  It won't take much of an investment 
to establish a Registry of Public Email Servers.  All the information to 
create default records is publicly available.  Who knows, they might even 
make a profit from selling access to the Registry.

I think we are very close to the "tipping point".  That will occur when 
about 25% of email is being filtered based on domain ratings.  At that 
point, there will be a rush of domains wanting to get their Registry 
records narrowed down to just the few IPs that they control tightly, and 
keep the zombies from tarnishing their name.

This is about the last chance for the IETF to make a contribution, or to 
have any say in whatever de-facto standard emerges.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 16:42:27 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Options for the ID Command
Cc: [email-masked]
Sender: [email-masked]

At 06:12 PM 5/17/2005 -0400, [email-masked] wrote:

>On Tue, 17 May 2005 14:56:56 PDT, David MacQuigg said:
>
> > 1) It provides an unambiguous Identity that we can pick from the SMTP
> > session without transferring the DATA.
>
> > 2) There are no restrictions on the Identity that will favor one method
> > over another. i.e. It's just an Identity that we can check, no additional
> > requirements like it must be the PRA Identity (The reason SUBMITTER is 
> out.)
>
>You *do* realize that you're screwed at this point, because the different 
>proposals
>check different things.  What should the "identity" be when one proposal wants
>"the hostname claimed on the 821 MAIL FROM", another wants "the hostname 
>claimed
>on the 822 From:", and another wants the entire left/right side of one or 
>the other?

You misunderstood the proposal in this and the next four posts.  I'll 
provide one answer here.

The ID declaration is independent of the method, because we defer selection 
of the method until the next step, which is the DNS query.  The response to 
that query tells you what methods the ID offers for authentication, and 
each method may place additional restrictions on other identities in the email.

For example, let's say you get an email like this:

    EHLO  mailserver7.bigforwarder.com
    ID  bigforwarder.com
    MAIL FROM:<[email-masked]>

Checking the TXT record at _AUTH.bigforwarder.com.ID-check.net gets a response:

    svc=S1:A,M2:A,H1+:B  dmn=QR1,SPF1+5,DK2
    QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
      +4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
    DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
      o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
      EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB

The supported methods are QR1, SPF1, and DK2.  QR1 makes no demands on any 
other identities.  It just says "Any IP outside these blocks is not 
us."  SPF1 requires that either the MAIL FROM or the HELO identity match 
the declared Identity, and DK2 calls for a signature check using the public 
key provided in this record.

It is important that we not overload the ID Declaration with any other 
meanings, particularly any meanings assigned to pre-existing fields.  As 
the SPF folks have discovered, you can't get people to change the way they 
have been using MAIL FROM, even if you scream "forger" at them.

>If there was *agreement* on what to check, we'd not have competing proposals.

There are good and bad aspects to the present competition.  Good is that we 
will have available a variety of methods, so if one or another develops the 
problems their competitors worry about, we can switch to another.  Bad is 
that the competing groups are so hostile to each other that they won't 
cooperate on anything, and that lack of cooperation has blocked progress 
for nearly a year.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sender's Declaration of Identity 
Date: Tue, 17 May 2005 19:27:44 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 17, 2005 6:42 PM
Subject: Re: Sender's Declaration of Identity

On Tue, 17 May 2005 17:16:59 EDT, Hector Santos said:

>> Whoa!  Do you know what you just did?  You just gave me
>> encouragement and hope to maybe finish my ESMTP email authentication
>> proposal.  It is fundamentally based on these "optional
>> enforcement"  backward compatibility support level concepts.

> Well, if you have some scheme you'd want to write up, it can have room on
> the ID line right next to SPF1, SPF2, and CSV. ;)

Touch�!! :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: David MacQuigg <[email-masked]>
Cc: Hector Santos <[email-masked]>, [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 18:51:49 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 14:19:10 PDT, David MacQuigg said:

> What worries me about "going all the way" and including lots of nice
> options, is that the history of this project shows that even the most
> trivial of agreements among the different factions are impossible to

Yep. You think this is bad, you should have seen some of the flame-fests
that lead up to the RFC1341 MIME specs.. ;)

> negotiate.  The ID declaration is about as simple and "non-partisan" as I 
> can make it, and you can see the negative reactions that is 

That's it's major failing.  It tries to be non-partisan while papering over
the very deep and important reasons there's multiple factions here.  One ID
won't work when the players aren't agreeing on what an ID is.

> generating.  Imagine the arguments over which keywords (SPF1, SPF2,
> SENDERID(C), CSV, REQ, RES, AUTO, ... ) will be designated as IANA
> approved!!

Actually, what Hector and I are slowly thrashing out will bypass that.  We just
define the *frameworks*, and the "owner" of each proposal, SPF1, SPF2, CSV,
RES, HashCash, whatever just create the appropriate paperwork that registers
their pet scheme.  That can be done like this:

http://www.iana.org/assignments/media-types/index.htm

Seems to work OK for MIME media types.  I don't see any issue with doing it
for ID parameters.  (Seems to be not much more than a formalized "Hi, we're
company X, and our Foo product uses 'application/moby-foo' as a type"...)

>             If there is way to get the benefit of these options without 
> adding it all to SMTP, and I believe there is, then we should spend our 
> limited time and energy on just getting a simple, neutral way to declare an ID.

Hector and I are willing to settle on a simple, neutral way for client and
server to agree on *what* ID they want to declare. :)

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

--==_Exmh_1116370309_5349P--

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Who will lead the fight for email authentication 
From: [email-masked]
Date: Tue, 17 May 2005 18:42:34 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 15:02:13 PDT, David MacQuigg said:

> I'm sure you can think of a solution to this problem.  Hint: You have to 
> want a solution.

Important correction: I have to want a solution more than I want to avoid
giving control of the solution to whoever gets control.

And I'm not the only paranoid around - a reading of RFC2826 will show that they
were *very* careful to distinguish between "the DNS root must be singular" and
any statement of who should actually control it.

> Looks like the two most likely leaders are the FTC and Microsoft.  I don't 
> see the IETF stepping up to the plate.  The FTC will give us a technically 
> clumsy, not very effective, and legally burdensome solution.

There's a lot of places the FTC doesn't have jurisdiction.  In fact, there's
a lot of things *inside* the US it doesn't get to regulate, because the commerce
involved doesn't cross state lines....

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

--==_Exmh_1116369754_5349P--

To: Hector Santos <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 18:42:01 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 17:16:59 EDT, Hector Santos said:

> Whoa!  Do you know what you just did?  You just gave me
> encouragement and hope to maybe finish my ESMTP email authentication
> proposal.  It is fundamentally based on these "optional
> enforcement"  backward compatibility support level concepts.

Well, if you have some scheme you'd want to write up, it can have room on
the ID line right next to SPF1, SPF2, and CSV. ;)

> Good point. I was thinking as a "submitter" replacement to handle
> transition points.  But yes, by default, SPF1 would apply to the
> current email and/or optionally client domain depending in the
> implementor.
> 
>       ID SPF1 [responsible-domain]

Non-starter unless you require this to match where SPF1 usually checks - and
at that point, the only value is the information "It's worth checking SPF1".
Which is why I dropped the identifier off...

> I always thought SUBMITTER was vulnerable for the reasons you
> pointed out, so the same applies here I believe. The only way I
> saw around this is with HOP analysis.

Fortunately, that's a separate issue. ;)

> Ahhh, I see, sorta like a PPP LCP negotiation?  Gosh, I think
> you are going to force me to finish me work. :-)

Exactly.  I was actually thinking Telnet Will/Wont, but I suspect the LCP
guys were thinking about that too..;)

> I don't have all the answers of course, and nothing would tickle
> me pink to get an honest open discussion on the possibilities.
> 
> But how to best handle rejection is important and needs to be
> discussed as I see this as the major key in addressing backward
> compatibility.  The growth of "greylisting" has made these type of
> proposal more possible.

There's a number of ways to approach this one.  Personally, I prefer
"Client send an ID, server replies with 2XX, 4XX, or 5XX, client does
what it would do on a 2/4/5XX on a MAIL FROM: (basically, continue, queue
for retry later, or give up and either RSET or QUIT as appropriate).

> The basic idea behind optional enforcment modifier is to begin
> offering an backward compatible changing of the mindset the
> industry so desperately needs.   Of course, early implementators
> would not be so restricted. They will have atleast one method
> that is optional, thus allowing a non-compliant clients to
> continue.

That again is out-of-scope.  But at least *this* part will give client
and server a framework to discuss how either end is/isn't compliant..

> The goal is to gradually and eventually eliminate the non-SMTP
> compliancy issues that the spammer industry relies on to a very
> large degee.

The problem is that most spam is currently fairly SMTP compliant.  I think what
you *meant* to say was that "we would address the lack of additional *out of
band* authentication and authorization issues that spammers rely on".

And yes, it will involve out-of-band checking of some sort. (The only proposal
I've seen that doesn't is HashCash, which has its own issues which are, ironically
enough, based on the fact it isn't out-of-band...)

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

--==_Exmh_1116369721_5349P--

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 18:32:25 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 15:08:00 PDT, David MacQuigg said:

> The Sender's Declaration of Identity is one piece of that standard.  I 
> think of it as a kind of "broadcast license", but without government 
> regulation.  You must tell me who you are before I will bother even looking 
> up your reputation.  And if you make me do ten failed lookups in less than 
> an hour, I'll ignore your IP.

Which "who" is Keith supposed to tell you he is?  The sending system? The MAIL FROM
the system is sending for? The RFC822 From: field? Note that these are *often*
different.

Some people want to verify the sending system, to make sure it's an authorized
sender of mail.

Some poeple what to verify the MAIL FROM, to make sure that it's coming from the
correct place (this is *different* than the previous).

And so on.

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

--==_Exmh_1116369145_5349P--

To: David MacQuigg <[email-masked]>
Cc: Hector Santos <[email-masked]>, [email-masked]
Subject: Re: Options for the ID Command 
From: [email-masked]
Date: Tue, 17 May 2005 18:12:29 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 14:56:56 PDT, David MacQuigg said:

> 1) It provides an unambiguous Identity that we can pick from the SMTP 
> session without transferring the DATA.

> 2) There are no restrictions on the Identity that will favor one method 
> over another. i.e. It's just an Identity that we can check, no additional 
> requirements like it must be the PRA Identity (The reason SUBMITTER is out.)

You *do* realize that you're screwed at this point, because the different proposals
check different things.  What should the "identity" be when one proposal wants
"the hostname claimed on the 821 MAIL FROM", another wants "the hostname claimed
on the 822 From:", and another wants the entire left/right side of one or the other?

If there was *agreement* on what to check, we'd not have competing proposals.

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

--==_Exmh_1116367949_5349P--

Date: Tue, 17 May 2005 14:19:10 -0700
To: "Hector Santos" <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Cc: <[email-masked]>
Sender: [email-masked]

At 02:27 PM 5/17/2005 -0400, Hector Santos wrote:
>----- Original Message -----
>From: "David MacQuigg" <[email-masked]>
>
> > Here is an incoming email with no ID declaration.
> >
> >       EHLO  mailserver7.bigforwarder.com
> >       MAIL FROM:<[email-masked]>
> >
> > What do you do next if you want to authenticate this message?
>
>Dave,
>
>That should depend on the server, not the client.  However, if I think where
>you going with this (and this is not the say I agree with it),  what you are
>looking for the server expose to the client how the client can be
>authenticated:
>
>The more propery way to do this today with ESMTP would be for the server to
>expose what methods it support:
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-SIZE 5120000
>     S: 250-ETRN
>     S: 250-ID SPF1 SPF2 CSV
>     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
>     S: 250-AUTH=LOGIN
>     S: 250 HELP
>
>So for this server, it supports SPF1, SPF2 and CSV.
>
>The compliant client can choose one.
>
>Example #1
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-SIZE 5120000
>     S: 250-ETRN
>     S: 250-ID SPF1 SPF2 CSV
>     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
>     S: 250-AUTH=LOGIN
>     S: 250 HELP
>     C: ID SPF1 somedomain.com
>     S: 250 Validated! Continue
>
>Example #2:
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-SIZE 5120000
>     S: 250-ETRN
>     S: 250-ID SPF1 SPF2 CSV
>     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
>     S: 250-AUTH=LOGIN
>     S: 250 HELP
>     C: ID CSV somedomain.com
>     S: 551Sorry, not validated.  Do not continue.
>
>But might be conflictive with the state flow with our CSV is done, Dave can
>answer that.
>
>Also, I would personally suggest introduce optional enforcement concepts
>that makes the proposal stronger in my view.
>
>Example #3
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-ID SPF1-REQ SPF2 CSV
>     S: 250 HELP
>
>Which would suggest that SPF1 is required if the optional SPF2 or CSV is not
>used by the client.
>
>To further this idea, throw in a RES (restricted) and AUTO modifiers.
>
>
>Example #4
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-REQ SPF2 CSV-RES
>     S: 250 HELP
>
>This would suggest that SPF2 is optional,  CSV is restricted to certain IP
>addresses (or domains) and is required if the client falls in this
>classification.  Otherwise SPF1 is required.
>
>Example #5
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-AUTO SPF2 CSV-RES
>     S: 250 HELP
>
>This would suggest that SPF2 is optional,  CSV is restricted to certain IP
>addresses (or domains) and is required if the client falls in this
>classification.  Otherwise SPF1 is automatically applied, ID is not
>required:
>
>Example #6
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-AUTO SPF2 CSV-RES
>     S: 250 HELP
>     C: MAIL FROM: <reverse-path>
>     S: 451 Sorry, this DOMAIN failed SPF1
>
>Example #7
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-REQ SPF2 CSV-RES
>     S: 250 HELP
>     C: MAIL FROM: <reverse-path>
>     S: 551 Sorry, Please Provide ID command
>
>Example #8
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-REQ SPF2 CSV-RES
>     S: 250 HELP
>     C: ID SPF2 pra-domain.com
>     S: 250 pass!
>
>Example #9
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-REQ SPF2 CSV-AUTO
>     S: 250 HELP
>     [CVS checking done]
>     S: 551 - Sorry, you are not validated
>
>etc. etc.
>
>So basically, you need to map the behavior of all methods and then come up
>with the functional specification on how the SMTP server will behave.
>
>Now, will it work?
>
>Probably not.  For many reason, but the most important one from my stand
>point is that it is a big change and if we are considering a big change, we
>might as well go all the way with other more stronger methods.
>
>But I do think if you continue with the proposal, you should consider the
>modifies REQ, RES and AUTO.

What worries me about "going all the way" and including lots of nice 
options, is that the history of this project shows that even the most 
trivial of agreements among the different factions are impossible to 
negotiate.  The ID declaration is about as simple and "non-partisan" as I 
can make it, and you can see the negative reactions that is 
generating.  Imagine the arguments over which keywords (SPF1, SPF2, 
SENDERID(C), CSV, REQ, RES, AUTO, ... ) will be designated as IANA 
approved!!  If there is way to get the benefit of these options without 
adding it all to SMTP, and I believe there is, then we should spend our 
limited time and energy on just getting a simple, neutral way to declare an ID.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 15:08:00 -0700
To: <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Sender: [email-masked]

At 01:48 PM 5/17/2005 -0400, Hector Santos wrote:
>From: "Keith Moore" <[email-masked]>
>
> > 1) No one is going to trust what a client says.   You need an "anchor"
> > that he has basically no control of. Like the IP address.
>
> > no, not like the IP address, because in general IP address has nothing to
> > do with the sender's identity...
>
>Keith,
>
>I was implying some example "piece of information" that the SMTP client
>itself can not easily change.   I agree,  IP is not the best example, but it
>probably the best we have from a proof of concept and "anchor" example
>today.  Ironically,  I did have it parenthically stated to make sure we
>didn't get hung on it.  But I decided to remove it and crossed my finger
>that there woudn't be any nick picking.
>
> > it will have even less to do with the sender's identity in the future
> > than it does now.
>
>You and I seem to have similar crystal balls.

I'm assuming that the information returned by a DNS query is our ultimate 
"anchor".  This in turn, depends on the security of routing tables, 
physical access to wires and DNS servers, registrar's competence and 
integrity, and lots of other worries, but all of that is outside the scope 
of the present proposals.  If these foundation blocks are solid, then it 
should be possible for any authentication method, be it IP-based or 
signature-based, to build on a simple neutral standard.

The Sender's Declaration of Identity is one piece of that standard.  I 
think of it as a kind of "broadcast license", but without government 
regulation.  You must tell me who you are before I will bother even looking 
up your reputation.  And if you make me do ten failed lookups in less than 
an hour, I'll ignore your IP.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 15:02:13 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Who will lead the fight for email authentication
Cc: [email-masked]
Sender: [email-masked]

At 03:21 PM 5/17/2005 -0400, [email-masked] wrote:

>On Tue, 17 May 2005 12:06:16 PDT, David MacQuigg said:
>
>I would look for a TXT record at
> > _AUTH.spammers-r-us.com.mail.gov
>
>If you don't understand why such a mail.gov solution won't fly, you probably
>shouldn't be designing stuff in this area.
>
>Hint:  There's more Internet than US.  And most of the world has good reason
>to distrust anything in .GOV because it's US-run.

I'm sure you can think of a solution to this problem.  Hint: You have to 
want a solution.

>Hint 2: Nobody trusts ICANN to manage this correctly either.

Looks like the two most likely leaders are the FTC and Microsoft.  I don't 
see the IETF stepping up to the plate.  The FTC will give us a technically 
clumsy, not very effective, and legally burdensome solution.  Microsoft 
will give us a convoluted mess, which won't work well at first, but given a 
couple more years of stumbling around by the competition, they will 
eventually get it to work.

>Hint 3: The only reason why people trust IETF as far as they do is because
>it's easier to follow somebody else's specs to get interoperable than design
>your own (unless you're a company bent on vendor lock-in, of course).

I'm still hoping for an IETF solution, but not counting on it.  The IETF 
process has worked well for most of its history.  Maybe it will continue to 
work for problems other than spam, but it looks to me like they gave up 
after MARID.  You can't get a consensus when there is an uncompromising 
minority, and anything related to spam is going to nothing but 
uncompromising minorities.

The ID Declaration proposal is the easiest piece.  I'll see how that goes 
before committing any more time to the IETF process.

By the way Microsoft is not the only group bent on "lock-in".  Sometimes I 
think its easier to deal with people whose motivations are financial than 
those who have their ego tied up in a computer program.  :>)

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 14:56:56 -0700
To: "Hector Santos" <[email-masked]>, <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Options for the ID Command
Cc: <[email-masked]>
Sender: [email-masked]

Changing the title, so we can keep the original thread on track.

Hector, I haven't thought through all the implications of your proposal, 
but I will support it if:
1) It provides an unambiguous Identity that we can pick from the SMTP 
session without transferring the DATA.
2) The Identity can be used to locate a DNS record with no "hunting".
2) There are no restrictions on the Identity that will favor one method 
over another. i.e. It's just an Identity that we can check, no additional 
requirements like it must be the PRA Identity (The reason SUBMITTER is out.)
3) You can ram it past the Nattering Nabobs of Negativism. (oops, I'm 
showing my age ! :>)

--
Dave
*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

At 05:16 PM 5/17/2005 -0400, Hector Santos wrote:
>----- Original Message -----
>From: <[email-masked]>
>To: "Hector Santos" <[email-masked]>
>Sent: Tuesday, May 17, 2005 4:06 PM
>Subject: Re: Sender's Declaration of Identity
>
>On Tue, 17 May 2005 14:27:56 EDT, Hector Santos said:
>
> >>     S: 250-ID SPF1 SPF2 CSV
> >>
> >> So for this server, it supports SPF1, SPF2 and CSV.
>
> > OK.. That's a nice SMTP-extension friendly way to do it.  You've
> > got my attention :)
>
>Whoa!  Do you know what you just did?  You just gave me
>encouragement and hope to maybe finish my ESMTP email authentication
>proposal.  It is fundamentally based on these "optional
>enforcement"  backward compatibility support level concepts.
>
> >>     C: ID SPF1 somedomain.com
> >
> > You really want to just trim this reply back to 'ID SPF1' and
> > have SPF still look up the info based on the usual places -
> > otherwise you allow an attacker to claim one thing on the ID line
> > and something else in the now-unchecked fields.
>
>Good point. I was thinking as a "submitter" replacement to handle
>transition points.  But yes, by default, SPF1 would apply to the
>current email and/or optionally client domain depending in the
>implementor.
>
>       ID SPF1 [responsible-domain]
>
>I always thought SUBMITTER was vulnerable for the reasons you
>pointed out, so the same applies here I believe. The only way I
>saw around this is with HOP analysis.
>
> >Possibly modifying the ID command to return a list:
> >
> >    ID CSV SPF1
> >
> >to say "This mail should be authenticatable via either CSV or
> >SPF1", and allowing the server to '550 5.7.1 No acceptable auth
> >proto' at that point would be a better approach - Server lists
> >the acceptables, client lists the availables, and server then
> >says "Yes, we have something that might authenticate when the
> >time comes", or "No, we have no possible way to make this work,
> >don't even bother sending the MAIL FROM"....
>
>Ahhh, I see, sorta like a PPP LCP negotiation?  Gosh, I think
>you are going to force me to finish me work. :-)
>
> >>     S: 250-ID SPF1-REQ SPF2 CSV-RES
> >
> > Interesting idea - not sure how that would interact with the
> > alternate ID command I listed above.  What should a client do at
> > this point if it realizes it has no acceptable authenticator?
> > Just bail and send an RSET or QUIT, or other action?
>
>I don't have all the answers of course, and nothing would tickle
>me pink to get an honest open discussion on the possibilities.
>
>But how to best handle rejection is important and needs to be
>discussed as I see this as the major key in addressing backward
>compatibility.  The growth of "greylisting" has made these type of
>proposal more possible.
>
>The basic idea behind optional enforcment modifier is to begin
>offering an backward compatible changing of the mindset the
>industry so desperately needs.   Of course, early implementators
>would not be so restricted. They will have atleast one method
>that is optional, thus allowing a non-compliant clients to
>continue.
>
>So initial default is backward compatibility for the client.  If the sender
>is eventually deemed problematic, it might move the domain/IP into a -RES
>classification based.
>
>As time moves on, each system from small to corporate can decide
>how to apply their client/server security policy.  I suspect this
>will take a long time, but atleast the avenue will be there for
>new policies to grow and become more acceptable and main stream.
>
>The goal is to gradually and eventually eliminate the non-SMTP
>compliancy issues that the spammer industry relies on to a very
>large degee.
>
>I don't want to speak much about it, but in my more radical
>proposal with optional enforcement ideas,  optional "Hours of
>operations" is a small and important part it.
>
>     Hours for vendors (social networks)
>     Hours for {SPF1, SPF1, CSV, other] compliant clients
>     Hours for the general public
>
>etc, including:
>
>     Hours for compliant CANSPAM SPAMMERS
>
>Again, all optional with backward compatibility in mind, to begin
>introducing new enforcment policies that can be introduced over time.
>
> > I'm thinking that having the client reply 'ID SPF2 CSV'
> > (basically, enumerate the list of offered methods that it
> > recognizes/supports), and then the server can either '250 OK' or
> > '550 5.7.1 No way..'.  If the server gives back a 250 then it
> > also knows which methods to try or not try at the appropriate
> > times.
> >
> > I see this proposal as best suited for a framework to allow the
> > server end to say "your mail must be at least this
> > authenticated", and for a client to tell the server "Don't bother
> > trying methods X, Y, or Z at all" to minimize the server's
> > workload, and possibly for a client to have some form of early
> > disconnect if it can verify that there is no way the mail will be
> > accepted.
>
>Yes, I agreed with the idea of a stronger client/server negotiated
>handshake.
>
>The issue will be how the results and correlate them to local mail
>policies because ultimately this will defined the level of support for
>backward compatibility.
>
>Dave's proposal is attractive because makes us consider all the
>proposals out there so see how they can work in concert.
>
>But no idea will be effective until we begin to honestly look at
>the enforcement concepts and tying it to local system/server
>policies.  I have hope that it may possibly work if we begin with
>a "standard" method of defining optional enforcment ideas
>regardless of the security method in place.
>
>--
>Hector Santos, Santronics Software, Inc.
>http://www.santronics.com

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sender's Declaration of Identity 
Date: Tue, 17 May 2005 17:16:59 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: "Hector Santos" <[email-masked]>
Sent: Tuesday, May 17, 2005 4:06 PM
Subject: Re: Sender's Declaration of Identity

On Tue, 17 May 2005 14:27:56 EDT, Hector Santos said:

>>     S: 250-ID SPF1 SPF2 CSV
>>
>> So for this server, it supports SPF1, SPF2 and CSV.

> OK.. That's a nice SMTP-extension friendly way to do it.  You've
> got my attention :)

Whoa!  Do you know what you just did?  You just gave me
encouragement and hope to maybe finish my ESMTP email authentication
proposal.  It is fundamentally based on these "optional
enforcement"  backward compatibility support level concepts.

>>     C: ID SPF1 somedomain.com
>
> You really want to just trim this reply back to 'ID SPF1' and
> have SPF still look up the info based on the usual places -
> otherwise you allow an attacker to claim one thing on the ID line
> and something else in the now-unchecked fields.

Good point. I was thinking as a "submitter" replacement to handle
transition points.  But yes, by default, SPF1 would apply to the
current email and/or optionally client domain depending in the
implementor.

      ID SPF1 [responsible-domain]

I always thought SUBMITTER was vulnerable for the reasons you
pointed out, so the same applies here I believe. The only way I
saw around this is with HOP analysis.

>Possibly modifying the ID command to return a list:
>
>    ID CSV SPF1
>
>to say "This mail should be authenticatable via either CSV or
>SPF1", and allowing the server to '550 5.7.1 No acceptable auth
>proto' at that point would be a better approach - Server lists
>the acceptables, client lists the availables, and server then
>says "Yes, we have something that might authenticate when the
>time comes", or "No, we have no possible way to make this work,
>don't even bother sending the MAIL FROM"....

Ahhh, I see, sorta like a PPP LCP negotiation?  Gosh, I think
you are going to force me to finish me work. :-)

>>     S: 250-ID SPF1-REQ SPF2 CSV-RES
>
> Interesting idea - not sure how that would interact with the
> alternate ID command I listed above.  What should a client do at
> this point if it realizes it has no acceptable authenticator?
> Just bail and send an RSET or QUIT, or other action?

I don't have all the answers of course, and nothing would tickle
me pink to get an honest open discussion on the possibilities.

But how to best handle rejection is important and needs to be
discussed as I see this as the major key in addressing backward
compatibility.  The growth of "greylisting" has made these type of
proposal more possible.

The basic idea behind optional enforcment modifier is to begin
offering an backward compatible changing of the mindset the
industry so desperately needs.   Of course, early implementators
would not be so restricted. They will have atleast one method
that is optional, thus allowing a non-compliant clients to
continue.

So initial default is backward compatibility for the client.  If the sender
is eventually deemed problematic, it might move the domain/IP into a -RES
classification based.

As time moves on, each system from small to corporate can decide
how to apply their client/server security policy.  I suspect this
will take a long time, but atleast the avenue will be there for
new policies to grow and become more acceptable and main stream.

The goal is to gradually and eventually eliminate the non-SMTP
compliancy issues that the spammer industry relies on to a very
large degee.

I don't want to speak much about it, but in my more radical
proposal with optional enforcement ideas,  optional "Hours of
operations" is a small and important part it.

    Hours for vendors (social networks)
    Hours for {SPF1, SPF1, CSV, other] compliant clients
    Hours for the general public

etc, including:

    Hours for compliant CANSPAM SPAMMERS

Again, all optional with backward compatibility in mind, to begin
introducing new enforcment policies that can be introduced over time.

> I'm thinking that having the client reply 'ID SPF2 CSV'
> (basically, enumerate the list of offered methods that it
> recognizes/supports), and then the server can either '250 OK' or
> '550 5.7.1 No way..'.  If the server gives back a 250 then it
> also knows which methods to try or not try at the appropriate
> times.
>
> I see this proposal as best suited for a framework to allow the
> server end to say "your mail must be at least this
> authenticated", and for a client to tell the server "Don't bother
> trying methods X, Y, or Z at all" to minimize the server's
> workload, and possibly for a client to have some form of early
> disconnect if it can verify that there is no way the mail will be
> accepted.

Yes, I agreed with the idea of a stronger client/server negotiated
handshake.

The issue will be how the results and correlate them to local mail
policies because ultimately this will defined the level of support for
backward compatibility.

Dave's proposal is attractive because makes us consider all the
proposals out there so see how they can work in concert.

But no idea will be effective until we begin to honestly look at
the enforcement concepts and tying it to local system/server
policies.  I have hope that it may possibly work if we begin with
a "standard" method of defining optional enforcment ideas
regardless of the security method in place.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: Hector Santos <[email-masked]>
Cc: [email-masked], David MacQuigg <[email-masked]>, [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 16:06:23 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 14:27:56 EDT, Hector Santos said:

> The more propery way to do this today with ESMTP would be for the server to
> expose what methods it support:
> 
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-SIZE 5120000
>     S: 250-ETRN
>     S: 250-ID SPF1 SPF2 CSV
>     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
>     S: 250-AUTH=LOGIN
>     S: 250 HELP
> 
> So for this server, it supports SPF1, SPF2 and CSV.

OK.. That's a nice SMTP-extension friendly way to do it.  You've got my
attention :)

> The compliant client can choose one.
> 
> Example #1
> 
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Plesase to meet you.
>     S: 250-SIZE 5120000
>     S: 250-ETRN
>     S: 250-ID SPF1 SPF2 CSV
>     S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
>     S: 250-AUTH=LOGIN
>     S: 250 HELP
>     C: ID SPF1 somedomain.com

You really want to just trim this reply back to 'ID SPF1' and have SPF still
look up the info based on the usual places - otherwise you allow an attacker
to claim one thing on the ID line and something else in the now-unchecked fields.

It would also address this issue:

>    C: ID CSV somedomain.com
>    S: 551Sorry, not validated.  Do not continue.

> But might be conflictive with the state flow with our CSV is done, Dave can
> answer that.

because CSV checking would still happen at the regular time.

Possibly modifying the ID command to return a list:

    ID CSV SPF1

to say "This mail should be authenticatable via either CSV or SPF1", and allowing
the server to '550 5.7.1 No acceptable auth proto' at that point would be a
better approach - Server lists the acceptables, client lists the availables,
and server then says "Yes, we have something that might authenticate when
the time comes", or "No, we have no possible way to make this work, don't even
bother sending the MAIL FROM"....

>     S: 250-ID SPF1-REQ SPF2 CSV
>     S: 250 HELP
> 
> Which would suggest that SPF1 is required if the optional SPF2 or CSV is not
> used by the client.

>     S: 250-ID SPF1-REQ SPF2 CSV-RES

Interesting idea - not sure how that would interact with the alternate ID
command I listed above.  What should a client do at this point if it realizes
it has no acceptable authenticator?  Just bail and send an RSET or QUIT, or
other action?

I'm thinking that having the client reply 'ID SPF2 CSV' (basically, enumerate
the list of offered methods that it recognizes/supports), and then the server
can either '250 OK' or '550 5.7.1 No way..'.  If the server gives back a 250
then it also knows which methods to try or not try at the appropriate times.

I see this proposal as best suited for a framework to allow the server end
to say "your mail must be at least this authenticated", and for a client to
tell the server "Don't bother trying methods X, Y, or Z at all" to minimize
the server's workload, and possibly for a client to have some form of
early disconnect if it can verify that there is no way the mail will be accepted.

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

--==_Exmh_1116360383_5349P--

From: "Hector Santos" <[email-masked]>
To: "David MacQuigg" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Date: Tue, 17 May 2005 15:23:38 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Hector Santos" <[email-masked]>
Sent: Tuesday, May 17, 2005 2:27 PM
Subject: Re: Sender's Declaration of Identity

> Example #9
>
>     C: EHLO  mailserver7.bigforwarder.com
>     S: 250-hostdomain.com,  Please to meet you.
>     S: 250-ID SPF1-REQ SPF2 CSV-AUTO
>     S: 250 HELP
>     [CVS checking done]
>     S: 551 - Sorry, you are not validated
>
> etc. etc.
>

This CSV example would be incorrect.

However, the main reason to follow up on this example is that you will be in
conflict with Dave's CSV proposal .

Of course, this presumes you like the idea of modifiers:

So for example #9.1:

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-RES SPF2 CSV-AUTO
    S: 250 HELP

Here we have a system that will automatically apply CSV.  But it is a
chicken and egg situation when it comes to CSV.

Since Dave has not cleanly defines how CSV should be done, the default mode
would be to immediately apply the checking:

    C: EHLO  mailserver7.bigforwarder.com
    [CSV checking]
    S: 551 - Sorry, you are not validated

So for your proposal to support CSV, you will have update Dave's
specification to include a delayed verification conception that would be
applied at or before MAIL FROM:

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-RES SPF2 CSV-AUTO
    S: 250 HELP
    C: MAIL FROM <reverse path>
    [CSV checking]
    S: 551 - Sorry, you are not CSV validated at the EHLO domain/ip.

So in my opinion, your proposal benefits the CSV proposals or show it can't
be use in AUTO mode but instead in REQ or RES mode:

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-RES SPF2 CSV-AUTO
    S: 250 HELP
    ID SPF1 domain.com
    [CSV checking]
    S: 551 - Sorry, you are not CSV validated at the EHLO domain/ip.

Of course, Dave will probably disagree. I just illustrating how your
proposal may conflict with it.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 15:21:10 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 12:06:16 PDT, David MacQuigg said:

> Well, assuming you can get this syntax past Bruce Lilly (ID declaration 
> outside the SMTP session), I would look for a TXT record at 
> _AUTH.spammers-r-us.com.mail.gov

If you don't understand why such a mail.gov solution won't fly, you probably
shouldn't be designing stuff in this area.

Hint:  There's more Internet than US.  And most of the world has good reason
to distrust anything in .GOV because it's US-run.

Hint 2: Nobody trusts ICANN to manage this correctly either.

Hint 3: The only reason why people trust IETF as far as they do is because
it's easier to follow somebody else's specs to get interoperable than design
your own (unless you're a company bent on vendor lock-in, of course).

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

--==_Exmh_1116357670_5349P--

Date: Tue, 17 May 2005 12:06:16 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity 
Cc: [email-masked]
Sender: [email-masked]

At 02:27 PM 5/17/2005 -0400, [email-masked] wrote:

>On Tue, 17 May 2005 02:08:44 PDT, David MacQuigg said:
>
> >        EHLO  mailserver7.bigforwarder.com
> >        MAIL FROM:<[email-masked]>
> >
> > What do you do next?
>
>*I* get to decide that.  If I wish to do SPF checks, I perform the 
>required SPF
>checks.  If I wish to check a Yahoo-style signature, I do that. And so on.

You will waste a bunch of DNS queries and possibly conclude this message 
offers no authentication.  For each possible Identity 
(mailserver7.bigforwarder.com, bigforwarder.com, sales.some-company.com, 
some-company.com) you need to search every possible location for DNS 
records (<Identity>, _client._smtp.<Identity>, ...), and we still haven't 
searched all the header identities.

>Changing your transaction to read:
>
>        ID spammers-r-us.com
>        EHLO mailserver7.bigforwarder.com
>        MAIL FROM:<[email-masked]>
>
>What do *you* do next? (Note that for *ANY* authentication method I've seen so
>far, validating the 'spammers-r-us.com' value is the *WRONG* thing to do, 
>because
>spammers-r-us.com will be set up to verify correctly, even if the 
>EHLO/MAIL FROM
>don't).

Well, assuming you can get this syntax past Bruce Lilly (ID declaration 
outside the SMTP session), I would look for a TXT record at 
_AUTH.spammers-r-us.com.mail.gov, check the reputation listings in that 
record, then run whatever authentication method(s) the record calls for, 
assuming I have those methods installed on my MTA, and my server isn't too 
overloaded to perform whatever twists and turns the method calls for.

>Now if your proposed tag said:
>
>        ID SPF=YES,YAHOO=NO,CVS=YES
>
>*THAT* I can do something with (namely, short-circuit that auth method with
>whatever I do for a 'info-not-found' for that method).

My proposal is even better.  You query _AUTH.<Identity>.mail.gov, and get 
not only the list of supported authentication methods, but all the 
parameters for those methods, plus a list of reputation services and their 
ratings of the <Identity>, plus some links to additional records, in case 
all of this doesn't fit into one 512-byte DNS packet.  See 
purl.net/macquigg/email  draft-macquigg-authent-dns.htm  for work-in-progress.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "David MacQuigg" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Date: Tue, 17 May 2005 14:27:56 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "David MacQuigg" <[email-masked]>

> Here is an incoming email with no ID declaration.
>
>       EHLO  mailserver7.bigforwarder.com
>       MAIL FROM:<[email-masked]>
>
> What do you do next if you want to authenticate this message?

Dave,

That should depend on the server, not the client.  However, if I think where
you going with this (and this is not the say I agree with it),  what you are
looking for the server expose to the client how the client can be
authenticated:

The more propery way to do this today with ESMTP would be for the server to
expose what methods it support:

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-ID SPF1 SPF2 CSV
    S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
    S: 250-AUTH=LOGIN
    S: 250 HELP

So for this server, it supports SPF1, SPF2 and CSV.

The compliant client can choose one.

Example #1

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-ID SPF1 SPF2 CSV
    S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
    S: 250-AUTH=LOGIN
    S: 250 HELP
    C: ID SPF1 somedomain.com
    S: 250 Validated! Continue

Example #2:

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-ID SPF1 SPF2 CSV
    S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
    S: 250-AUTH=LOGIN
    S: 250 HELP
    C: ID CSV somedomain.com
    S: 551Sorry, not validated.  Do not continue.

But might be conflictive with the state flow with our CSV is done, Dave can
answer that.

Also, I would personally suggest introduce optional enforcement concepts
that makes the proposal stronger in my view.

Example #3

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Plesase to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV
    S: 250 HELP

Which would suggest that SPF1 is required if the optional SPF2 or CSV is not
used by the client.

To further this idea, throw in a RES (restricted) and AUTO modifiers.

Example #4

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-RES
    S: 250 HELP

This would suggest that SPF2 is optional,  CSV is restricted to certain IP
addresses (or domains) and is required if the client falls in this
classification.  Otherwise SPF1 is required.

Example #5

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-AUTO SPF2 CSV-RES
    S: 250 HELP

This would suggest that SPF2 is optional,  CSV is restricted to certain IP
addresses (or domains) and is required if the client falls in this
classification.  Otherwise SPF1 is automatically applied, ID is not
required:

Example #6

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-AUTO SPF2 CSV-RES
    S: 250 HELP
    C: MAIL FROM: <reverse-path>
    S: 451 Sorry, this DOMAIN failed SPF1

Example #7

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-RES
    S: 250 HELP
    C: MAIL FROM: <reverse-path>
    S: 551 Sorry, Please Provide ID command

Example #8

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-RES
    S: 250 HELP
    C: ID SPF2 pra-domain.com
    S: 250 pass!

Example #9

    C: EHLO  mailserver7.bigforwarder.com
    S: 250-hostdomain.com,  Please to meet you.
    S: 250-ID SPF1-REQ SPF2 CSV-AUTO
    S: 250 HELP
    [CVS checking done]
    S: 551 - Sorry, you are not validated

etc. etc.

So basically, you need to map the behavior of all methods and then come up
with the functional specification on how the SMTP server will behave.

Now, will it work?

Probably not.  For many reason, but the most important one from my stand
point is that it is a big change and if we are considering a big change, we
might as well go all the way with other more stronger methods.

But I do think if you continue with the proposal, you should consider the
modifies REQ, RES and AUTO.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 14:27:18 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 02:08:44 PDT, David MacQuigg said:

>        EHLO  mailserver7.bigforwarder.com
>        MAIL FROM:<[email-masked]>
> 
> What do you do next?

*I* get to decide that.  If I wish to do SPF checks, I perform the required SPF
checks.  If I wish to check a Yahoo-style signature, I do that. And so on.
Changing your transaction to read:

       ID spammers-r-us.com
       EHLO mailserver7.bigforwarder.com
       MAIL FROM:<[email-masked]>

What do *you* do next? (Note that for *ANY* authentication method I've seen so
far, validating the 'spammers-r-us.com' value is the *WRONG* thing to do, because
spammers-r-us.com will be set up to verify correctly, even if the EHLO/MAIL FROM
don't).

Now if your proposed tag said:

       ID SPF=YES,YAHOO=NO,CVS=YES

*THAT* I can do something with (namely, short-circuit that auth method with
whatever I do for a 'info-not-found' for that method).

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

--==_Exmh_1116354438_5349P--

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Tue, 17 May 2005 14:19:45 -0400
Sender: [email-masked]

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

On Tue, 17 May 2005 02:08:44 PDT, David MacQuigg said:

> And we don't know, when the message arrives, whether it uses Sender-ID, 
> SPF, or some other method.

I'm the *receiver* of the message. *I* decide if I want to check Sender-ID,
SPF, or some other method. *I* get to choose what to do if the site it's
coming from doesn't support whatever scheme I'm using.

If you want to be *helpful*, give me a hint what scheme you think your
site supports.  Should I *bother* with an SPF check, or does the site
flag their outbound mail as "we don't believe in SPF"?  Similarly for
other protocols that involve often-expensive DNS or other remote lookups.

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

--==_Exmh_1116353984_5349P--

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Date: Tue, 17 May 2005 13:48:47 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Keith Moore" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 17, 2005 12:58 PM
Subject: Re: Sender's Declaration of Identity

> 1) No one is going to trust what a client says.   You need an "anchor"
that
> he has basically no control of. Like the IP address.

> no, not like the IP address, because in general IP address has nothing to
> do with the sender's identity...

Keith,

I was implying some example "piece of information" that the SMTP client
itself can not easily change.   I agree,  IP is not the best example, but it
probably the best we have from a proof of concept and "anchor" example
today.  Ironically,  I did have it parenthically stated to make sure we
didn't get hung on it.  But I decided to remove it and crossed my finger
that there woudn't be any nick picking.

> it will have even less to do with the sender's identity in the future
> than it does now.

You and I seem to have similar crystal balls.

Glad to see you reading my mail again. :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Tue, 17 May 2005 12:58:34 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Sender's Declaration of Identity
Sender: [email-masked]

> 1) No one is going to trust what a client says.   You need an "anchor" that
> he has basically no control of. Like the IP address.

no, not like the IP address, because in general IP address has nothing to
do with the sender's identity...it will have even less to do with the sender's
identity in the future than it does now.

Keith

Date: Tue, 17 May 2005 09:59:51 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Cc: [email-masked]
Sender: [email-masked]

At 08:57 AM 5/17/2005 -0700, [email-masked] wrote:

>>I assume from the position of your comment above, that you are objecting to
>>the expectation that Reply Code 500 could be a normal and harmless
>>response.  The key question for me is - Will it actually break
>>something?  I've tried sending the ID command to a variety of receivers
>>using different server software, and they all respond with either 500 or
>>502, yes even Hector's super-strict Winserver!
>
>Servers exist that will hang up on the first invalid command they receive.
>Examples include the Microsoft Mail SMTP server (where it was a bug since it
>also applied to EHLO) as well as a bunch of more modern servers, many of which
>are configurable to allow only so many bad commands before hanging up. I don't
>think it is wise for people to set such limits to 1, but I've seen several
>people do it.

Can you give me some example domains, so I can do an experiment?

>It is therefore essential that the EHLO negotation framework be used to
>avoid sending unrecognized commands.

Done.  I added a short example to the IANA section.  See previous post.

>But this isn't the real problem with your proposal - fixing it so it
>used EHLO is simple enough. The real problem is that you have yet to
>demonstrate how adding an ID command is actually effective in combating
>spam. I'm with Valdis on this one.

This is not the right forum for an extended discussion of email 
authentication, but many, including myself, believe that authentication is 
a key enabler to stopping spam.  Without forgery, spam couldn't exist.

Assuming more than one authentication method will be widely deployed, 
receivers will have a problem knowing exactly what method a sender is 
using.  Valdis didn't reply to my earlier challenge, so I'll ask you the 
same question.

Here is an incoming email with no ID declaration.

       EHLO  mailserver7.bigforwarder.com
       MAIL FROM:<[email-masked]>

What do you do next if you want to authenticate this message?

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 09:45:33 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Sender: [email-masked]

At 11:44 AM 5/17/2005 -0400, Bruce Lilly wrote:
>On Tue May 17 2005 11:07, David MacQuigg wrote:
> > > At 07:19 AM 5/17/2005 -0400, Bruce Lilly wrote:
> >
> > >On Sun May 15 2005 21:23, David MacQuigg wrote:
> > > > My main concern is backward compatibility.  Here are the
> > > > relevant paragraphs:
> > > >
> > > >     EHLO  mailserver7.my-company.com
> > > >     ID  mycompany.com
> > > >     MAIL FROM: [email-masked]
> > > >
> > > >     ...
> > > >
> > > >     The proposed syntax will require extension of SMTP standard [RFC-
> > > >     2821] and changes in current MTA software and practices.  See 
> section
> > > >     7. IANA Considerations.
> > > >
> > > >     MTA software will need to be enhanced and deployed at sites that
> > > >     provide email authentication.  To minimize upgrade efforts these
> > > >     changes should be bundled with the upgrade to enable 
> authentication.
> > > >
> > > >     Receivers that don't recognize the ID command should return a Reply
> > > >     Code 500 COMMAND UNRECOGNIZED.
> > >[...]
> > >
> > >This is NOT backward compatible.  See separate message on ietf-smtp for
> > >an overview and pointers to detailed references.
> >
> > Bruce, I appreciate your general advice, and I do read it carefully.  I'll
> > need something more specific in this case, however.
> >
> > I assume from the position of your comment above, that you are 
> objecting to
> > the expectation that Reply Code 500 could be a normal and harmless
> > response.
>
>No, the objection is to sending an extended command that does not have a
>corresponding ESMTP keyword extension in the EHLO response.  You need to
>establish such a keyword and stipulate that clients MUST NOT send an ID
>command unless that keyword is offered in the server's EHLO response. In
>that case "Receivers that don;t recognize the ID command" never arises.
>That is the established ESMTP negotiation mechanism, and if you don't
>play by those rules, your proposal will go nowhere.

Sorry to be breaking the rules.  I wanted to find out first if there is 
some fundamental problem before spending a lot of time on documentation.

I've re-written the IANA section.

IANA Considerations

    The proposed syntax will require an SMTP service extension for a new ID 
command.

            C: EHLO example.com
            S: 250-host.com, welcome
            S: 250-SIZE ETRN ID
            S: 250-AUTH LOGIN
            S: 250 HELP

I understand there is a lot more documentation still needed.  I can do that 
if and when it gets to the RFC stage.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: [email-masked]
Cc: [email-masked]
Date: Tue, 17 May 2005 08:57:23 -0700 (PDT)
Subject: Re: Sender's Declaration of Identity
To: David MacQuigg <[email-masked]>
Sender: [email-masked]

> I assume from the position of your comment above, that you are objecting to
> the expectation that Reply Code 500 could be a normal and harmless
> response.  The key question for me is - Will it actually break
> something?  I've tried sending the ID command to a variety of receivers
> using different server software, and they all respond with either 500 or
> 502, yes even Hector's super-strict Winserver!

Servers exist that will hang up on the first invalid command they receive.
Examples include the Microsoft Mail SMTP server (where it was a bug since it
also applied to EHLO) as well as a bunch of more modern servers, many of which
are configurable to allow only so many bad commands before hanging up. I don't
think it is wise for people to set such limits to 1, but I've seen several
people do it.

It is therefore essential that the EHLO negotation framework be used to
avoid sending unrecognized commands.

But this isn't the real problem with your proposal - fixing it so it
used EHLO is simple enough. The real problem is that you have yet to
demonstrate how adding an ID command is actually effective in combating
spam. I'm with Valdis on this one.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Sender's Declaration of Identity
Date: Tue, 17 May 2005 11:44:05 -0400
Cc: David MacQuigg <[email-masked]>
Sender: [email-masked]

On Tue May 17 2005 11:07, David MacQuigg wrote:
> 
> At 07:19 AM 5/17/2005 -0400, Bruce Lilly wrote:
> 
> >On Sun May 15 2005 21:23, David MacQuigg wrote:
> > > My main concern is backward compatibility.  Here are the
> > > relevant paragraphs:
> > >
> > >     EHLO  mailserver7.my-company.com
> > >     ID  mycompany.com
> > >     MAIL FROM: [email-masked]
> > >
> > >     ...
> > >
> > >     The proposed syntax will require extension of SMTP standard [RFC-
> > >     2821] and changes in current MTA software and practices.  See section
> > >     7. IANA Considerations.
> > >
> > >     MTA software will need to be enhanced and deployed at sites that
> > >     provide email authentication.  To minimize upgrade efforts these
> > >     changes should be bundled with the upgrade to enable authentication.
> > >
> > >     Receivers that don't recognize the ID command should return a Reply
> > >     Code 500 COMMAND UNRECOGNIZED.
> >[...]
> >
> >This is NOT backward compatible.  See separate message on ietf-smtp for
> >an overview and pointers to detailed references.
> 
> Bruce, I appreciate your general advice, and I do read it carefully.  I'll 
> need something more specific in this case, however.
> 
> I assume from the position of your comment above, that you are objecting to 
> the expectation that Reply Code 500 could be a normal and harmless 
> response.

No, the objection is to sending an extended command that does not have a
corresponding ESMTP keyword extension in the EHLO response.  You need to
establish such a keyword and stipulate that clients MUST NOT send an ID
command unless that keyword is offered in the server's EHLO response. In
that case "Receivers that don;t recognize the ID command" never arises.
That is the established ESMTP negotiation mechanism, and if you don't
play by those rules, your proposal will go nowhere.

All of which is orthogonal to whether or not the extension has any
practical value, as discussed by others.

Date: Tue, 17 May 2005 08:07:12 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Sender: [email-masked]

At 07:19 AM 5/17/2005 -0400, Bruce Lilly wrote:

>On Sun May 15 2005 21:23, David MacQuigg wrote:
> > My main concern is backward compatibility.  Here are the
> > relevant paragraphs:
> >
> >     EHLO  mailserver7.my-company.com
> >     ID  mycompany.com
> >     MAIL FROM: [email-masked]
> >
> >     ...
> >
> >     The proposed syntax will require extension of SMTP standard [RFC-
> >     2821] and changes in current MTA software and practices.  See section
> >     7. IANA Considerations.
> >
> >     MTA software will need to be enhanced and deployed at sites that
> >     provide email authentication.  To minimize upgrade efforts these
> >     changes should be bundled with the upgrade to enable authentication.
> >
> >     Receivers that don't recognize the ID command should return a Reply
> >     Code 500 COMMAND UNRECOGNIZED.
>[...]
>
>This is NOT backward compatible.  See separate message on ietf-smtp for
>an overview and pointers to detailed references.

Bruce, I appreciate your general advice, and I do read it carefully.  I'll 
need something more specific in this case, however.

I assume from the position of your comment above, that you are objecting to 
the expectation that Reply Code 500 could be a normal and harmless 
response.  The key question for me is - Will it actually break 
something?  I've tried sending the ID command to a variety of receivers 
using different server software, and they all respond with either 500 or 
502, yes even Hector's super-strict Winserver!

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 07:13:17 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: RE: Authentication by Prior Arrangement
Cc: "John P Baker" <[email-masked]>
Sender: [email-masked]

This is clearly off the topic of Sender's Declaration of Identity.  Please 
change the subject when you go off topic.  It will help if we ever need to 
go back and review a discussion.  Thanks.
--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

At 07:54 AM 5/17/2005 -0400, Bruce Lilly wrote:

>On Mon May 16 2005 23:00, John P Baker wrote:
>
> > First, let us consider a local mail server receiving mail from a directly
> > connected remote client
>
>Which is it -- "directly connected" or "remote"?  What is the significance?
>
> > to whom is allocated a mailbox address
>
>"Mailbox" or "address" ((at least) two different things -- see RFC 2822)?
>
> > on the
> > server.
>
>One use of "mailbox" -- a mailbox receives mail -- makes little sense:
>o you speak of "allocated" and "client", but a mailbox has no relationship
>   to any specific instance of "client" (MTA, MUA, or IP address) and need
>   not have a one-to-one relationship with any person.
>o in the scenario posited, where the sender is associated with the mailbox
>   for receipt of the message, the sender is sending mail to himself, which
>   is at best an edge case of little general interest or utility.
>The other use of mailbox -- name-addr / addr-spec -- makes zero sense in
>the scenario.
>
>One use of "address" -- as in IP address -- has no relationship to either
>meaning of "mailbox".  Another use of "address" -- mailbox / group --
>relates the syntax of message header "address" (a third use, categorizing
>a set of message header fields) field components and has no involvement in
>mail transport.
>
> > In this scenario, I will argue that when the mail origination
> > authentication extension is enabled, the local mail server should verify
> > that the "From:" mail address specified in the message header
>
>NO!  The message header is end-to-end, user-to-user communication.
>Delivery transport uses SMTP command RCPT TO arguments.  Transport
>agents (other than gateways) are forbidden from poking around in the
>users' private communications -- see RFC 2821.
>
>[...]
> > Second, let us consider a local mail server receiving mail from a connected
> > remote mail server.  In this scenario, I will argue that when the mail
> > origination authentication extension is enabled, the local mail server
> > should be required to maintain a resident list of "trusted" remote mail
> > servers (i.e., remote mail servers who stipulate that they require that all
> > mail message traffic must comply with the requirements of the mail
> > origination authentication extension), and no SMTP session establishment to
> > a "non-trusted" remote mail server should be permitted.
>[...]
>
>One of the fundamental rules of email is that no prior arrangement is
>required between sender and recipient.  You seem to have completely
>missed that fundamental rule.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Backward compatible SMTP extensions
Date: Tue, 17 May 2005 07:59:04 -0400
Sender: [email-masked]

On Sun May 15 2005 23:16, Bruce Lilly wrote:

> Before making extension proposals, authors should carefully review these
> considerations, RFC 1869, RFC 822 (base SMTP), and other available

Typo: "822" should be "821".

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: RE: Sender's Declaration of Identity
Date: Tue, 17 May 2005 07:54:07 -0400
Cc: "John P Baker" <[email-masked]>
Sender: [email-masked]

On Mon May 16 2005 23:00, John P Baker wrote:

> First, let us consider a local mail server receiving mail from a directly
> connected remote client

Which is it -- "directly connected" or "remote"?  What is the significance?

> to whom is allocated a mailbox address

"Mailbox" or "address" ((at least) two different things -- see RFC 2822)?

> on the  
> server.

One use of "mailbox" -- a mailbox receives mail -- makes little sense:
o you speak of "allocated" and "client", but a mailbox has no relationship
  to any specific instance of "client" (MTA, MUA, or IP address) and need
  not have a one-to-one relationship with any person.
o in the scenario posited, where the sender is associated with the mailbox
  for receipt of the message, the sender is sending mail to himself, which
  is at best an edge case of little general interest or utility.
The other use of mailbox -- name-addr / addr-spec -- makes zero sense in
the scenario.

One use of "address" -- as in IP address -- has no relationship to either
meaning of "mailbox".  Another use of "address" -- mailbox / group --
relates the syntax of message header "address" (a third use, categorizing
a set of message header fields) field components and has no involvement in
mail transport.

> In this scenario, I will argue that when the mail origination 
> authentication extension is enabled, the local mail server should verify
> that the "From:" mail address specified in the message header

NO!  The message header is end-to-end, user-to-user communication.
Delivery transport uses SMTP command RCPT TO arguments.  Transport
agents (other than gateways) are forbidden from poking around in the
users' private communications -- see RFC 2821.

[...]
> Second, let us consider a local mail server receiving mail from a connected
> remote mail server.  In this scenario, I will argue that when the mail
> origination authentication extension is enabled, the local mail server
> should be required to maintain a resident list of "trusted" remote mail
> servers (i.e., remote mail servers who stipulate that they require that all
> mail message traffic must comply with the requirements of the mail
> origination authentication extension), and no SMTP session establishment to
> a "non-trusted" remote mail server should be permitted.
[...]

One of the fundamental rules of email is that no prior arrangement is
required between sender and recipient.  You seem to have completely
missed that fundamental rule.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity
Date: Tue, 17 May 2005 07:19:57 -0400
Cc: [email-masked]
Sender: [email-masked]

On Sun May 15 2005 21:23, David MacQuigg wrote:
> My main concern is backward compatibility.  Here are the 
> relevant paragraphs:
> 
>     EHLO  mailserver7.my-company.com
>     ID  mycompany.com
>     MAIL FROM: [email-masked]
> 
>     ...
> 
>     The proposed syntax will require extension of SMTP standard [RFC-
>     2821] and changes in current MTA software and practices.  See section
>     7. IANA Considerations.
> 
>     MTA software will need to be enhanced and deployed at sites that
>     provide email authentication.  To minimize upgrade efforts these
>     changes should be bundled with the upgrade to enable authentication.
> 
>     Receivers that don't recognize the ID command should return a Reply
>     Code 500 COMMAND UNRECOGNIZED.
[...]

This is NOT backward compatible.  See separate message on ietf-smtp for
an overview and pointers to detailed references.

From: "Hector Santos" <[email-masked]>
To: "David MacQuigg" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Sender's Declaration of Identity 
Date: Tue, 17 May 2005 07:08:01 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

David,

A few things:

1) No one is going to trust what a client says.   You need an "anchor" that
he has basically no control of. Like the IP address.

2) If you do use a ID command, what method does the server use?  It would be
more appropriate with something like:

        ID method method_entity

3) But #1 still applies.

In short,  the server defines what security context the client will run
under.  Not the client.

4) Enforcement.  How do you plan to enforce it?

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "David MacQuigg" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 17, 2005 5:08 AM
Subject: Re: Sender's Declaration of Identity

At 11:58 PM 5/16/2005 -0400, [email-masked] wrote:

>On Mon, 16 May 2005 14:49:02 PDT, David MacQuigg said:
>
> > The ID is used only to locate the authentication records.  The actual
> check
> > is done per the requirements of whatever method is specified in the DNS
> > records at the ID.  For example, if the ID is ebay.com, and ebay says
> "Here
> > is an SPF record to use in checking that IP", then the check will be
done
> > against the MAIL FROM and HELO domains.  If ebay says "Here is a Sender
ID
> > record", then it will be a different set of domains that gets
> > checked.  Whatever method is used, it is the ID that is responsible to
> > chose the method and provide proper DNS records for that method.
>
>But Sender-ID and SPF already *know* where to look for the data they want.

And we don't know, when the message arrives, whether it uses Sender-ID,
SPF, or some other method.

>You stick an ID record in there, what are you *really* accomplishing?

Avoid multiple DNS queries hunting for authentication records.

>Let's say we're looking at a scheme that validates MAIL FROM. Either:
>
>1) The ID and MAIL FROM match.  Why bother?
>
>2) The ID and MAIL FROM don't match.  Now you either have to check the
>MAIL FROM
>*anyhow* and flag an error, or allow the spammer to hand you a valid ID and
a
>bogus MAIL FROM.

You seem to be assuming SPF.  What if the method is CSV?

>Work through your protocol, and assume that the spammer will *LIE* with
>whatever
>value they think they can get the best results with.

Let's work through it together.  Here is an incoming email.

       EHLO  mailserver7.bigforwarder.com
       MAIL FROM:<[email-masked]>

What do you do next?

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 02:08:44 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity 
Cc: [email-masked]
Sender: [email-masked]

At 11:58 PM 5/16/2005 -0400, [email-masked] wrote:

>On Mon, 16 May 2005 14:49:02 PDT, David MacQuigg said:
>
> > The ID is used only to locate the authentication records.  The actual 
> check
> > is done per the requirements of whatever method is specified in the DNS
> > records at the ID.  For example, if the ID is ebay.com, and ebay says 
> "Here
> > is an SPF record to use in checking that IP", then the check will be done
> > against the MAIL FROM and HELO domains.  If ebay says "Here is a Sender ID
> > record", then it will be a different set of domains that gets
> > checked.  Whatever method is used, it is the ID that is responsible to
> > chose the method and provide proper DNS records for that method.
>
>But Sender-ID and SPF already *know* where to look for the data they want.

And we don't know, when the message arrives, whether it uses Sender-ID, 
SPF, or some other method.

>You stick an ID record in there, what are you *really* accomplishing?

Avoid multiple DNS queries hunting for authentication records.

>Let's say we're looking at a scheme that validates MAIL FROM. Either:
>
>1) The ID and MAIL FROM match.  Why bother?
>
>2) The ID and MAIL FROM don't match.  Now you either have to check the 
>MAIL FROM
>*anyhow* and flag an error, or allow the spammer to hand you a valid ID and a
>bogus MAIL FROM.

You seem to be assuming SPF.  What if the method is CSV?

>Work through your protocol, and assume that the spammer will *LIE* with 
>whatever
>value they think they can get the best results with.

Let's work through it together.  Here is an incoming email.

       EHLO  mailserver7.bigforwarder.com
       MAIL FROM:<[email-masked]>

What do you do next?

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Tue, 17 May 2005 03:14:56 -0700
To: "John P Baker" <[email-masked]>, <[email-masked]>
From: David MacQuigg <[email-masked]>
Subject: Authentication by Prior Arrangement
Sender: [email-masked]

At 11:00 PM 5/16/2005 -0400, John P Baker wrote:

>I am intrigued by your proposal.
>
>However, I don't see that it will wholly address the underlying
>authentication problems.

The ID declaration is only the first step in an authentication 
process.  The proposal addresses only that step, not the whole 
process.  I'm not ready yet to submit the other pieces, but if you want to 
look ahead see purl.net/macquigg/email.

>Sometime back, I had raised the issue of having some type of authentication
>method.
>
>However, I believe that we really have to look at two separate
>authentication points.
>
>First, let us consider a local mail server receiving mail from a directly
>connected remote client to whom is allocated a mailbox address on the
>server.  In this scenario, I will argue that when the mail origination
>authentication extension is enabled, the local mail server should verify
>that the "From:" mail address specified in the message header for each
>message submitted from the remote client to the local mail server is a valid
>mail address allocated by the local mail server to that remote client (i.e.,
>the remote client's mailbox address, or some other mail address which the
>local mail server recognizes as properly associated with that remote
>client).
>
>Second, let us consider a local mail server receiving mail from a connected
>remote mail server.  In this scenario, I will argue that when the mail
>origination authentication extension is enabled, the local mail server
>should be required to maintain a resident list of "trusted" remote mail
>servers (i.e., remote mail servers who stipulate that they require that all
>mail message traffic must comply with the requirements of the mail
>origination authentication extension), and no SMTP session establishment to
>a "non-trusted" remote mail server should be permitted.  The local mail
>server need only maintain a list of remote mail servers from which it
>receives mail message traffic directly.  Mail message traffic originating in
>or routed through such remote mail servers should be permitted to flow
>freely.
>
>There may be some holes in this proposal.  Let me know what you think.

I would need to see a lot more detail, something like what the other 
methods have written, but a quick response is that it looks like you are 
assuming a prior relationship between sender and receiver.  The general 
problem is that we need to authenticate when there is no prior relationship.

I have thought a bit about how you could use a protocol separate from SMTP 
to establish such a relationship, but I concluded that there would be not 
enough advantage over doing it within the SMTP session.  The idea for the 
separate protocol, call it RSMTP (Request for SMTP service), is to 
intercept all attempts to connect on port 25, and let them through only if 
the incoming IP is on a whitelist.  To get on the whitelist, you first 
connect to RSMTP on a different port, then do an authentication via DNS, 
just like we do now with any of the proposed IP authentication methods.  If 
the result is PASS, the IP goes on the whitelist for whatever time is 
allowed by the DNS record.

This assumes that a particular IP will be using one ID for all of its 
transmissions.  It saves a few DNS queries, but it looks like the savings 
over one query per SMTP session is insignificant.

I'm holding RSMTP in reserve, in case there are unexpected problems adding 
an ID command to SMTP.

--
Dave

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of David MacQuigg
>Sent: Sunday, May 15, 2005 21:24
>To: [email-masked]
>Subject: Sender's Declaration of Identity
>
>
>I've written a draft that I hope will help resolve some of the
>inter-operability problems for different email authentication
>methods.  Before submitting it, I would like to make sure I haven't missed
>something important.
>
>The proposal is to add an ID command to the SMTP exchange, after EHLO, but
>before MAIL.  My main concern is backward compatibility.  Here are the
>relevant paragraphs:
>
>     EHLO  mailserver7.my-company.com
>     ID  mycompany.com
>     MAIL FROM: [email-masked]
>
>     ...
>
>     The proposed syntax will require extension of SMTP standard [RFC-
>     2821] and changes in current MTA software and practices.  See section
>     7. IANA Considerations.
>
>     MTA software will need to be enhanced and deployed at sites that
>     provide email authentication.  To minimize upgrade efforts these
>     changes should be bundled with the upgrade to enable authentication.
>
>     Receivers that don't recognize the ID command should return a Reply
>     Code 500 COMMAND UNRECOGNIZED.  Receivers that recognized the
>     command, but chose to ignore it, should return 502 COMMAND
>     UNIMPLEMENTED.  [RFC-2821] section 4.2.4.  Senders should ignore
>     these errors, and proceed with the MAIL command.
>
>     Backward compatibility may be an issue for receivers that do not wish
>     to add authentication, but have been enforcing overly strict
>     requirements on SMTP syntax, perhaps for the purpose of spam
>     filtering.  Mail with an unrecognized command should not be rejected.
>
>The complete draft is at:
>http://purl.net/net/macquigg/email draft-macquigg-authent-declare
>
>Comments will be appreciated.
>
>--
>Dave
>
>************************************************************     *
>* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
>* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
>* Analog Design Methodologies                                 *  *  *
>*                                 9320 East Mikelyn Lane       * * *
>* VRS Consulting, P.C.            Tucson, Arizona 85710          *
>************************************************************     *

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Mon, 16 May 2005 23:58:09 -0400
Sender: [email-masked]

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

On Mon, 16 May 2005 14:49:02 PDT, David MacQuigg said:

> The ID is used only to locate the authentication records.  The actual check 
> is done per the requirements of whatever method is specified in the DNS 
> records at the ID.  For example, if the ID is ebay.com, and ebay says "Here 
> is an SPF record to use in checking that IP", then the check will be done 
> against the MAIL FROM and HELO domains.  If ebay says "Here is a Sender ID 
> record", then it will be a different set of domains that gets 
> checked.  Whatever method is used, it is the ID that is responsible to 
> chose the method and provide proper DNS records for that method.

But Sender-ID and SPF already *know* where to look for the data they want.

You stick an ID record in there, what are you *really* accomplishing?

Let's say we're looking at a scheme that validates MAIL FROM. Either:

1) The ID and MAIL FROM match.  Why bother?

2) The ID and MAIL FROM don't match.  Now you either have to check the MAIL FROM
*anyhow* and flag an error, or allow the spammer to hand you a valid ID and a
bogus MAIL FROM.

Work through your protocol, and assume that the spammer will *LIE* with whatever
value they think they can get the best results with.

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

--==_Exmh_1116302288_12766P--

From: "John P Baker" <[email-masked]>
To: <[email-masked]>
Subject: RE: Sender's Declaration of Identity
Date: Mon, 16 May 2005 23:00:01 -0400
Sender: [email-masked]

I am intrigued by your proposal.

However, I don't see that it will wholly address the underlying
authentication problems.

Sometime back, I had raised the issue of having some type of authentication
method.

However, I believe that we really have to look at two separate
authentication points.

First, let us consider a local mail server receiving mail from a directly
connected remote client to whom is allocated a mailbox address on the
server.  In this scenario, I will argue that when the mail origination
authentication extension is enabled, the local mail server should verify
that the "From:" mail address specified in the message header for each
message submitted from the remote client to the local mail server is a valid
mail address allocated by the local mail server to that remote client (i.e.,
the remote client's mailbox address, or some other mail address which the
local mail server recognizes as properly associated with that remote
client).

Second, let us consider a local mail server receiving mail from a connected
remote mail server.  In this scenario, I will argue that when the mail
origination authentication extension is enabled, the local mail server
should be required to maintain a resident list of "trusted" remote mail
servers (i.e., remote mail servers who stipulate that they require that all
mail message traffic must comply with the requirements of the mail
origination authentication extension), and no SMTP session establishment to
a "non-trusted" remote mail server should be permitted.  The local mail
server need only maintain a list of remote mail servers from which it
receives mail message traffic directly.  Mail message traffic originating in
or routed through such remote mail servers should be permitted to flow
freely.

There may be some holes in this proposal.  Let me know what you think.

John P Baker
Software Engineer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David MacQuigg
Sent: Sunday, May 15, 2005 21:24
To: [email-masked]
Subject: Sender's Declaration of Identity

I've written a draft that I hope will help resolve some of the 
inter-operability problems for different email authentication 
methods.  Before submitting it, I would like to make sure I haven't missed 
something important.

The proposal is to add an ID command to the SMTP exchange, after EHLO, but 
before MAIL.  My main concern is backward compatibility.  Here are the 
relevant paragraphs:

    EHLO  mailserver7.my-company.com
    ID  mycompany.com
    MAIL FROM: [email-masked]

    ...

    The proposed syntax will require extension of SMTP standard [RFC-
    2821] and changes in current MTA software and practices.  See section
    7. IANA Considerations.

    MTA software will need to be enhanced and deployed at sites that
    provide email authentication.  To minimize upgrade efforts these
    changes should be bundled with the upgrade to enable authentication.

    Receivers that don't recognize the ID command should return a Reply
    Code 500 COMMAND UNRECOGNIZED.  Receivers that recognized the
    command, but chose to ignore it, should return 502 COMMAND
    UNIMPLEMENTED.  [RFC-2821] section 4.2.4.  Senders should ignore
    these errors, and proceed with the MAIL command.

    Backward compatibility may be an issue for receivers that do not wish
    to add authentication, but have been enforcing overly strict
    requirements on SMTP syntax, perhaps for the purpose of spam
    filtering.  Mail with an unrecognized command should not be rejected.

The complete draft is at:
http://purl.net/net/macquigg/email draft-macquigg-authent-declare

Comments will be appreciated.

--
Dave

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Mon, 16 May 2005 14:49:02 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Re: Sender's Declaration of Identity 
Cc: [email-masked]
Sender: [email-masked]

At 10:55 PM 5/15/2005 -0400, [email-masked] wrote:

>On Sun, 15 May 2005 18:23:55 PDT, David MacQuigg said:
>
> > The proposal is to add an ID command to the SMTP exchange, after EHLO, but
> > before MAIL.  My main concern is backward compatibility.  Here are the
> > relevant paragraphs:
> >
> >     EHLO  mailserver7.my-company.com
> >     ID  mycompany.com
> >     MAIL FROM: [email-masked]
>You get the point:
>
>    Unfortunately, there is no agreement on how this should be done.
>    Some believe firmly that it should be done in the EHLO command at the
>    start of each session, others insist that it should be done in the
>    MAIL command with each email.  Still others think the true Identity
>    should be extracted from one or another of the email headers that the
>    recipient actually sees.  Adding to the confusion is the fact that
>    each of these identities may legitimately differ from the Identity
>    that is to be authenticated, and may differ in having extra
>    "subdomain" labels that are not easily separated from the Identity to
>    be checked.
>
>and then promptly decide to ignore it.  The reason that there is disagreement
>is because the different choices have different semantics.  In addition, 
>many of
>the schemes involve the inability of the sender to overload a field.  So for
>instance, if you're trying to send a phish using a MAIL FROM: of @ebay.com,
>you're *stuck* with that MAIL FROM.

The different semantics are irrelevant to the initial declaration.  The 
common semantic is "This is the ID to be checked."  Once you have that ID, 
then you can do a query to a single location, and find out what 
authentication methods the ID owner offers.  The "overloading" you refer to 
is not necessary if the declared ID has its own field.

The ID is used only to locate the authentication records.  The actual check 
is done per the requirements of whatever method is specified in the DNS 
records at the ID.  For example, if the ID is ebay.com, and ebay says "Here 
is an SPF record to use in checking that IP", then the check will be done 
against the MAIL FROM and HELO domains.  If ebay says "Here is a Sender ID 
record", then it will be a different set of domains that gets 
checked.  Whatever method is used, it is the ID that is responsible to 
chose the method and provide proper DNS records for that method.

>Your proposal would allow:
>
>EHLO mailserver-7.my-company.com
>ID some-spammer-controlled-domain-that-will-verify.com
>MAIL FROM:<[email-masked]>
>
>In addition, being able to pick-n-choose and feed the value from a MAIL FROM
>to a scheme that wants to verify EHLO or the PTR of the source just opens up
>a lot of attacks.

The reputation check on some-spammer... will stop this example.  All 
methods depend on the reputation of the ID, whether that ID is assumed or 
declared.

>So how exactly does this improve the situation?

See section 2 of the draft for a summary of the advantages.  I've 
re-written this, hoping to make it more clear.  Here are the re-written 
paragraphs:
"""
    One way to standardize the Identity declaration is to use a new
    field, independent of existing fields, and not constrained by any
    pre-existing semantics.

       EHLO  mailserver7.bigforwarder.com
       ID  bigforwarder.com
       MAIL FROM:<[email-masked]>

    One advantage of this syntax is that the sender's ID is explicitly
    declared, not just assumed from existing information.  Not only will
    this remove the current uncertainty as to which ID the sender intends
    to use, but false information here is evidence of a serious problem,
    not just a forgivable error in passing on existing information (a
    long-standing problem with email).  This will greatly reduce the
    administrative burden in deciding whether to trust a sender.

    Another advantage is that there is no "hunting" for DNS records at
    various locations and multiple levels of a deep subdomain tree.  The
    ID should provide the exact location where the authorization records
    will be found.
"""

I don't know how to say it any better.  Perhaps an example to illustrate 
the first advantage would help.  If you get an email that says MAIL 
FROM:<[email-masked]>, but ebay says NO, it may be impossible to trace 
the source of the forgery.  The sending MTA is just passing on information 
that it received, and the "chain-of-trust" gets fuzzy very quickly.  If the 
sending MTA declares "ID ebay.com", then it cannot deny responsibility for 
its unauthorized use of that name.

I'm not sure if this is any more clear, but please let me know if there is 
still confusion.

--
Dave
************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Backward compatible SMTP extensions
Date: Sun, 15 May 2005 23:16:15 -0400
Sender: [email-masked]

Recently there has been a flurry of ill-considered schemes for extending
SMTP in a manner which is not compatible with the large deployed base of
products which implement ESMTP and which are used in mission-critical
applications.  Evidently the authors of such schemes are unfamiliar with
the existing mechanisms which provide for backward-compatible extensions.
Details are in RFC 1869; what follows here is a brief introductory
tutorial.

1. Vanilla SMTP
   Here is how an error-free SMTP session for sending a single message
   proceeds:

   Client opens connection to server
   Server sends greeting
   Client sends HELO command
   Server responds
   Client sends MAIL FROM command
   Server responds
   Client sends RCPT TO command
   Server responds
   Client sends DATA command
   Server responds
   Client sends byte-stuffed message, ends with CRLF.CRLF
   Server responds
   Client sends QUIT command
   Server responds and closes connection

   All commands in that sequence are part of the base SMTP command set,
   guaranteed to be supported by all servers.

2. Capability Negotiation and Fallback
   In order to handle extended functionality in a backwards-compatible
   manner, it is necessary for the client and server to negotiate
   capabilities.  It is unacceptable for a client to issue random commands
   which are not known to be supported by the server.  If some extension is
   not announced by the server in negotiation, the client must avoid that
   extension, falling back to the set of announced extensions plus the base
   SMTP commands.  A session with a server that does not support extensions
   and a client attempting ESMTP begins:

   Client opens connection to server
   Server sends greeting
   Client sends EHLO command
   Server sends error response code
   Client sends HELO command; remainder of session is as above for basic SMTP

3. Negotiation Mechanisms
   The established negotiation mechanism uses the following components:

   o One extension command, EHLO, similar to HELO, which informs the
     server that the client wishes to be informed of extensions supported by
     the server.  If the server responds with an error code to the EHLO
     command, the client must fall back to using HELO (and exclusively
     other base SMTP commands) or QUIT.

   o extension keywords, which identify extended capability features and
     which are listed in the server response to EHLO to indicate supported
     extensions.  Keywords are registered by IANA.

   o optional extension commands, associated with a feature named by an
     extension keyword

   o optional command parameters, associated with a feature named by an
     extension keyword.

4. Extended SMTP (ESMTP) Operation
   An ESMTP session proceeds as follows:

   Client opens connection to server
   Server sends greeting
   Client sends EHLO command
   Server responds, listing supported extension keywords
   Client may send commands and parameters associated with supported
     extensions announced by the server, and base SMTP commands

5. Ground rules
   Clients must not send extended commands other than EHLO unless an
   associated keyword is announced by the server in response to EHLO.
   Clients may not use extended parameters with base commands unless
   an associated keyword is announced by the server.  Servers must
   support base SMTP commands.  Servers announcing extensions must be
   prepared to accept any legal combination of commands and parameters
   associated with those extensions (e.g. by having sufficient command
   line length resources).

6. Choice
   A client that wishes to use some extension may try a different server
   if that extension is not announced by some particular server.  A client
   may choose to abort delivery and return an error to the return path if
   no suitable server can be found which supports an extension which the
   client must use for delivery.  A server may choose to offer, or not
   offer certain extensions based on the IP address of the connecting
   client, the port (e.g. 25 or 587), use of initial TLS, and/or the
   domain name or literal specified by the client in the EHLO command
   parameter, local policy, availability of resources, etc.; however, the 
   server must support the base SMTP commands.

7. Recipes for Failure
   Any of the following will doom a proposal:

   o requirement to simultaneously "upgrade" a significant fraction of
     SMTP servers (i.e. lack of negotiation and/or fallback)

   o requirement to simultaneously "upgrade" a significant fraction of
     SMTP clients (same as above)

   o specification of some extension without using the negotiation
     mechanism outlined above

   In addition, any Internet-Draft proposal that lacks appropriate IANA
   Considerations and Security Considerations sections is not likely to
   be taken seriously.

Before making extension proposals, authors should carefully review these
considerations, RFC 1869, RFC 822 (base SMTP), and other available
resources (RFCs 2223, 2119, 2277, 2360, 2434, 3365, 3552, and 3426, also
ID-Checklist and 1id-guidelines).

To: David MacQuigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Sender's Declaration of Identity 
From: [email-masked]
Date: Sun, 15 May 2005 22:55:50 -0400
Sender: [email-masked]

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

On Sun, 15 May 2005 18:23:55 PDT, David MacQuigg said:

> The proposal is to add an ID command to the SMTP exchange, after EHLO, but 
> before MAIL.  My main concern is backward compatibility.  Here are the 
> relevant paragraphs:
> 
>     EHLO  mailserver7.my-company.com
>     ID  mycompany.com
>     MAIL FROM: [email-masked]
You get the point:

   Unfortunately, there is no agreement on how this should be done.  
   Some believe firmly that it should be done in the EHLO command at the 
   start of each session, others insist that it should be done in the 
   MAIL command with each email.  Still others think the true Identity 
   should be extracted from one or another of the email headers that the 
   recipient actually sees.  Adding to the confusion is the fact that 
   each of these identities may legitimately differ from the Identity 
   that is to be authenticated, and may differ in having extra 
   "subdomain" labels that are not easily separated from the Identity to 
   be checked.

and then promptly decide to ignore it.  The reason that there is disagreement
is because the different choices have different semantics.  In addition, many of
the schemes involve the inability of the sender to overload a field.  So for
instance, if you're trying to send a phish using a MAIL FROM: of @ebay.com,
you're *stuck* with that MAIL FROM.

Your proposal would allow:

EHLO mailserver-7.my-company.com
ID some-spammer-controlled-domain-that-will-verify.com
MAIL FROM:<[email-masked]>

In addition, being able to pick-n-choose and feed the value from a MAIL FROM
to a scheme that wants to verify EHLO or the PTR of the source just opens up
a lot of attacks.

So how exactly does this improve the situation?

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

--==_Exmh_1116212150_5152P--

Date: Sun, 15 May 2005 18:23:55 -0700
To: [email-masked]
From: David MacQuigg <[email-masked]>
Subject: Sender's Declaration of Identity
Sender: [email-masked]

I've written a draft that I hope will help resolve some of the 
inter-operability problems for different email authentication 
methods.  Before submitting it, I would like to make sure I haven't missed 
something important.

The proposal is to add an ID command to the SMTP exchange, after EHLO, but 
before MAIL.  My main concern is backward compatibility.  Here are the 
relevant paragraphs:

    EHLO  mailserver7.my-company.com
    ID  mycompany.com
    MAIL FROM: [email-masked]

    ...

    The proposed syntax will require extension of SMTP standard [RFC-
    2821] and changes in current MTA software and practices.  See section
    7. IANA Considerations.

    MTA software will need to be enhanced and deployed at sites that
    provide email authentication.  To minimize upgrade efforts these
    changes should be bundled with the upgrade to enable authentication.

    Receivers that don't recognize the ID command should return a Reply
    Code 500 COMMAND UNRECOGNIZED.  Receivers that recognized the
    command, but chose to ignore it, should return 502 COMMAND
    UNIMPLEMENTED.  [RFC-2821] section 4.2.4.  Senders should ignore
    these errors, and proceed with the MAIL command.

    Backward compatibility may be an issue for receivers that do not wish
    to add authentication, but have been enforcing overly strict
    requirements on SMTP syntax, perhaps for the purpose of spam
    filtering.  Mail with an unrecognized command should not be rejected.

The complete draft is at:
http://purl.net/net/macquigg/email draft-macquigg-authent-declare

Comments will be appreciated.

--
Dave

************************************************************     *
* David MacQuigg, PhD     email: david_macquigg at yahoo.com     *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                 9320 East Mikelyn Lane       * * *
* VRS Consulting, P.C.            Tucson, Arizona 85710          *
************************************************************     *

Date: Fri, 13 May 2005 11:46:51 -0400
From: Keith Moore <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Early history and 2821 (was: draft-duan-smtp-receiver-driven-00.txt)
Sender: [email-masked]

> Also, the Return-Path is typically removed once the gate sees its a normal
> message (no bounce requiired) before final storage for the end-user.   It is
> not required any more at that point.

it is a violation of the standards for mail processors to remove Return-Path.
Return-Path is required even after delivery for proper processing of
message disposition notification requests and for generation of automatic
responses.

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Early history and 2821
Date:  Fri, 13 May 2005 13:54:58 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 18
Cc: [email-masked]
Sender: [email-masked]

Hector Santos wrote:

>> it's not 110% clear
[...]       ^^^^ 
 
> hmm, you put exactly what the Reverse Path (MAIL FROM)
> provided.

Of course.  It's a discussion with Bruce, so if the syntax
somewhere says ( "<>" / Reverse-Path ) and later talks only
about the Reverse-Path, then the empty case is lost.

It's not about understanding what to do in reality... ;-)

                        Bye, Frank

P.S., sorry for the ASRG copy, I wanted to remove it.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Frank Ellermann" <[email-masked]>
Cc: <[email-masked]>
Subject: Re:  Early history and 2821 (was: draft-duan-smtp-receiver-driven-00.txt)
Date: Fri, 13 May 2005 07:24:06 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

> Apparently Bruce found a minor problem in 2821, it's not 110%
> clear what to put in the Return-Path for a null MAIL FROM:<>

hmm, you put exactly what the Reverse Path (MAIL FROM) provided.

Return-Path was only meant for final destination mail as a way to provide a
post smtp system (i.e., gateway) a method to initiate a bounce process using
the proper reverse address that was not typically available using the older
SLIP/UUCP format.

There is no bounce process for a NULL reverse address (return path).

Also, the Return-Path is typically removed once the gate sees its a normal
message (no bounce requiired) before final storage for the end-user.   It is
not required any more at that point.

Before,  the gate had to play games like maybe checking for an
administrative address (Mailer-Daemon, PostMaster) in "822.From:"

A null return path, "Return-Path: <>",  a clear indication of a non-bouncing
potential process.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Early history and 2821 (was: draft-duan-smtp-receiver-driven-00.txt)
Date:  Fri, 13 May 2005 11:05:22 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 72
Cc: [email-masked]
Sender: [email-masked]

John C Klensin wrote:

> my involvement with ARPANET/ Internet email goes back to the
> decision to put a "MAIL" verb in the original FTP

Now that doesn't prove that you're guilty of any attempts to
twist the good old STD 10 reverse path into something like an
arbitrary "bounces to" construct.  Maybe it was somebody else.

For obscure reasons I'm almost always on the wrong list, 2822
issues here, because mail-arch mentions them, and 2821 on the
822 list when authors invent new header fields, last example:
<http://mid.gmane.org/[email-masked]>

Apparently Bruce found a minor problem in 2821, it's not 110%
clear what to put in the Return-Path for a null MAIL FROM:<>

> "former IAB Chair"

Do they discuss issues like "bounces-to" ?  <sarcasm> It's not
very serious, maybe some Terabytes, less than 1 billion USD
damage. </sarcasm>

When it hit me it was in total 150,000 bounces.  With an average
size of 4 KB and my V.90 line that's about 2000 minutes if I got
this right, or 20 EUR for the traffic to me.  Plus the time for
wading through this stuff, sending some complaints, inventing
filters to salvage good bounces and "good" spam (reportable via
SC, last year it didn't allow to report bounces), and solving
several hundreds of these funny C/R puzzles (UOL etc.).

> I'm pretty much about as implicated as one can get.  :-)

The crystal balls they sold 16 years ago were really bad, my
exemplar told me that today something like TCP or SMTP would
be ancient history.  All my prophecies were wrong, only SGML
was at least not completely wrong.

Maybe the author of STD 10 had a _working_ crystal ball, his
idea of a "reverse path" was actually correct.  But that was
23 years ago, the quality of crystal balls varies with the
years.  1982 I (ab)used DEV PUN on a VM/370 for local mail,
and I didn't know what a "modem", "ftp", or "smtp" might be.

  [1123]
>> As soon as time travel is available I intend to discuss
>> all implications of 5.3.6 (a) and 5.3.3 with the authors.
>> Maybe the net at large sponsors the trip back to 1989.

> Some of those issues where intended to be clarified in 2821.
> If you don't think the clarifications were adequate

It's clear from my POV, the only missing piece is to fix it,
back to the working concept of a "reverse path" in STD 10.

> this would be a good time to let me know.

That sounds like you're planning a 2821bis anytime soon (?)

In that case I'd like to discuss the 2821bis syntax for an
IPv6-address-literal and a General-address-literal, adding
"IPv6:" is odd, how about adopting the syntax in RfC 3986 ?

It was a pain to find a new syntax for the msg-id in USEFOR,
the "dcontent" in your syntax isn't allowed in news / NNTP,
and it's also "suboptimal" in news: URLs.  After some weeks
we found a working "maximal" syntax.  But your "dcontent" is
defined in RfC 2822, and as always I'm on the wrong list.

        Bye, Frank (only sent to the SMTP list, not ASRG)

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Early history and 2821 (was: draft-duan-smtp-receiver-driven-00.txt)
Date:  Fri, 13 May 2005 11:05:22 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 71
Cc: [email-masked]
Sender: [email-masked]

John C Klensin wrote:

> my involvement with ARPANET/ Internet email goes back to the
> decision to put a "MAIL" verb in the original FTP

Now that doesn't prove that you're guilty of any attempts to
twist the good old STD 10 reverse path into something like an
arbitrary "bounces to" construct.  Maybe it was somebody else.

For obscure reasons I'm almost always on the wrong list, 2822
issues here, because mail-arch mentions them, and 2821 on the
822 list when authors invent new header fields, last example:
<http://mid.gmane.org/[email-masked]>

Apparently Bruce found a minor problem in 2821, it's not 110%
clear what to put in the Return-Path for a null MAIL FROM:<>

> "former IAB Chair"

Do they discuss issues like "bounces-to" ?  <sarcasm> It's not
very serious, maybe some Terabytes, less than 1 billion USD
damage. </sarcasm>

When it hit me it was in total 150,000 bounces.  With an average
size of 4 KB and my V.90 line that's about 2000 minutes if I got
this right, or 20 EUR for the traffic to me.  Plus the time for
wading through this stuff, sending some complaints, inventing
filters to salvage good bounces and "good" spam (reportable via
SC, last year it didn't allow to report bounces), and solving
several hundreds of these funny C/R puzzles (UOL etc.).

> I'm pretty much about as implicated as one can get.  :-)

The crystal balls they sold 16 years ago were really bad, my
exemplar told me that today something like TCP or SMTP would
be ancient history.  All my prophecies were wrong, only SGML
was at least not completely wrong.

Maybe the author of STD 10 had a _working_ crystal ball, his
idea of a "reverse path" was actually correct.  But that was
23 years ago, the quality of crystal balls varies with the
years.  1982 I (ab)used DEV PUN on a VM/370 for local mail,
and I didn't know what a "modem", "ftp", or "smtp" might be.

  [1123]
>> As soon as time travel is available I intend to discuss
>> all implications of 5.3.6 (a) and 5.3.3 with the authors.
>> Maybe the net at large sponsors the trip back to 1989.

> Some of those issues where intended to be clarified in 2821.
> If you don't think the clarifications were adequate

It's clear from my POV, the only missing piece is to fix it,
back to the working concept of a "reverse path" in STD 10.

> this would be a good time to let me know.

That sounds like you're planning a 2821bis anytime soon (?)

In that case I'd like to discuss the 2821bis syntax for an
IPv6-address-literal and a General-address-literal, adding
"IPv6:" is odd, how about adopting the syntax in RfC 3986 ?

It was a pain to find a new syntax for the msg-id in USEFOR,
the "dcontent" in your syntax isn't allowed in news / NNTP,
and it's also "suboptimal" in news: URLs.  After some weeks
we found a working "maximal" syntax.  But your "dcontent" is
defined in RfC 2822, and as always I'm on the wrong list.

        Bye, Frank (only sent to the SMTP list, not ASRG)

Date: Fri, 13 May 2005 10:11:06 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: [email-masked]
Cc: wayne <[email-masked]>, [email-masked]
Subject: Re: error in RFC2821 "section 2.4.1"
Organization: NIC France
Sender: [email-masked]

On Fri, May 13, 2005 at 03:51:03AM -0400,
 [email-masked] <[email-masked]> wrote 
 a message of 28 lines which said:

> John Klensin posted here back in 2002 that those references to 2.4.1
> were incorrect and should be to 6.3 instead.

Not all of them. 

4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
...
   Although EHLO keywords may be specified in upper, lower, or mixed
   case, they MUST always be recognized and processed in a case-
   insensitive manner.  This is simply an extension of practices
   specified in RFC 821 and section 2.4.1.

Here, 6.3 never talks about case. It is certainly 2.4:

   Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
   and extension name keywords) are not case sensitive, 

Date: Fri, 13 May 2005 10:08:52 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: wayne <[email-masked]>
Cc: [email-masked]
Subject: Re: error in RFC2821 "section 2.4.1"
Organization: NIC France
Sender: [email-masked]

On Fri, May 13, 2005 at 02:12:44AM -0500,
 wayne <[email-masked]> wrote 
 a message of 18 lines which said:

> In several places, RFC2821 makes references to "section 2.4.1",
> however, there *is* no section 2.4.1 in RFC2821.

>From the context, it seems clear it is actually 2.4. And, yes, it
seems to be a bug. I find that incredible that people do not use a
tool like xml2rfc which handles crossrefs :-(

To: wayne <[email-masked]>
Cc: [email-masked]
Subject: Re: error in RFC2821 "section 2.4.1" 
From: [email-masked]
Date: Fri, 13 May 2005 03:51:03 -0400
Sender: [email-masked]

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

On Fri, 13 May 2005 02:12:44 CDT, you said:

> In several places, RFC2821 makes references to "section 2.4.1",
> however, there *is* no section 2.4.1 in RFC2821.

John Klensin posted here back in 2002 that those references to 2.4.1
were incorrect and should be to 6.3 instead.

And yes, we should have errata'd this.

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

--==_Exmh_1115970663_3671P--

To: [email-masked]
From: wayne <[email-masked]>
Subject:  error in RFC2821 "section 2.4.1"
Date:  Fri, 13 May 2005 02:12:44 -0500
Lines: 18
Cancel-Lock: sha1:wUMa5vMm4qHddIyncuZSwrWzrm8=
Sender: [email-masked]

Hi.

In several places, RFC2821 makes references to "section 2.4.1",
however, there *is* no section 2.4.1 in RFC2821.  I have checked the
errata page for RFC2821 on the rfc-editor website, but there is no
mention of this problem there.  I have also tried to figure out which
section is really being referred to, but it isn't obvious to me what
it could be.  Maybe it was a section that was deleted during editing?

Can anyone help clarify this for me?

thanks

-wayne

To: Hector Santos <[email-masked]>
Cc: Zhenhai Duan <[email-masked]>, Kartik Gopalan <[email-masked]>, IETF-SMTP <[email-masked]>, Yingfei Dong <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt 
From: [email-masked]
Date: Thu, 12 May 2005 12:26:33 -0400
Sender: [email-masked]

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

On Wed, 11 May 2005 10:15:43 EDT, Hector Santos said:

> Call Back Verifiers (CBV) are also in place which is essentially a
> "SMTP-based challenge" to validate the reverse path, dynamically and only
> the spot, based on the theory that a Bounce Address must be correct as soon
> as it is provided.   This helps eliminates NXDOMAIN and bad email domains
> transactions.  Rejection are 45x based so a good system that is
> "temporarily" down will try again.  Bad Systems do not.

And how, exactly, does *my* system distinguish between "This is Hector's
stuff doing a call-back" and "This is a spammer doing listwashing"?
(Remember that at many sites, you will be connecting to an inbound MX which
can't correlate your callback to an outbound connection from the outbound
gateway).  Alternately phrased, what call-back scheme are you using that
I'm not likely to refuse because it looks like a data trawl of some sort?

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

--==_Exmh_1115915193_15361P--

Date: Thu, 12 May 2005 13:37:09 +0100
To: <[email-masked]>
From: Paul Smith <[email-masked]>
Subject: Re: About TURN and ETRN command
Sender: [email-masked]

--=====================_700780546==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

>i wanna clarify my doubt in using TURN and ETRN commands
>
>
>i cldn't understand that what this RFC documents r telling.. i will give 
>one runtime sample , as what i'm thinking..
>
>1. starting SMTP session.
>
>2. starting the mail transaction for <mailbox 1>
>3. queuing the mail..
>
>4. starting the mail transaction for <mailbox 2>
>5. queuing the mail..
>
>6. starting the mail transaction for <mailbox 1>
>7. queuing the mail..
>
>8. ETRN <MailBox1>
>
>9. starting mail transaction for another mail boxes..
>.....
>...
>...
>...
>10. quit

Why on earth would you do that?

ETRN is intended to be used by the users of the mailbox it refers to (ie 
the owners of 'Mailbox 1' in this example), so you wouldn't typically send 
mail to yourself then immediately ask for it to be dequeued back to your 
own mail server..

>This session will despatch the mails 1, 3 for mailbox 1 immediately.. and 
>the remaining mails will be despatched after the smtp session quits..
>is it like that..?????

It's however the mail server that you're talking to wants to do it... I'd 
expect a mail server that didn't know anything about "mailbox1" just to 
ignore (or return an error for) the ETRN command.
Some mail servers may dispatch all the messages immediately, or they may 
wait an unspecified amount of time before dispatching them, or they may 
dispatch some sooner than others, etc. The SMTP standard doesn't specify 
anything about this at all.

Paul                            VPOP3 - Internet Email Server/Gateway
[email-masked]                      http://www.pscs.co.uk/

--=====================_700780546==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
<blockquote type=cite class=cite cite=""><font face="Courier New, Courier" size=2 color="#0000FF">i
wanna clarify my doubt in using </font><b>TURN </b>and<b> ETRN
</b><font face="Courier New, Courier" size=2 color="#0000FF">commands<br>
</font>&nbsp;<br>
&nbsp;<br>
<font face="Courier New, Courier" size=2 color="#0000FF">i cldn't
understand that what this RFC documents r telling.. i will give one
runtime sample , as what i'm thinking..<br>
</font>&nbsp;<br>

<dl>
<dl>
<dd><font face="Courier New, Courier" size=2 color="#0000FF">1. starting
SMTP session.<br>
</font>
<dd>&nbsp;<br>

<dd><font face="Courier New, Courier" size=2 color="#0000FF">2. starting
the mail transaction for &lt;mailbox 1&gt;<br>
</b>
<dd>3. queuing the mail..<br>
</font>
<dd>&nbsp;<br>

<dd><font face="Courier New, Courier" size=2 color="#0000FF">4. starting
the mail transaction for &lt;mailbox 2&gt;<br>
</b>
<dd>5. queuing the mail..<br>
</font>
<dd>&nbsp;<br>

<dd><font face="Courier New, Courier" size=2 color="#0000FF">6. starting
the mail transaction for &lt;mailbox 1&gt;<br>
</b>
<dd>7. queuing the mail..<br>
</font>
<dd>&nbsp;<br>

<dd><font face="Courier New, Courier" size=2 color="#0000FF">8. ETRN
&lt;MailBox1&gt;<br>
</b></font>
<dd>&nbsp;<br>

<dd><font face="Courier New, Courier" size=2 color="#0000FF">9.</b>
starting mail transaction for another mail boxes..<br>

<dd>.....<br>

<dd>...<br>

<dd>...<br>

<dd>...<br>

<dd>10. quit</font></blockquote>
</dl>
</dl><br>
Why on earth would you do that?<br><br>
ETRN is intended to be used by the users of the mailbox it refers to (ie the owners of 'Mailbox 1' in this example), so you wouldn't typically send mail to yourself then immediately ask for it to be dequeued back to your own mail server..<br><br>
<blockquote type=cite class=cite cite=""><font face="Courier New, Courier" size=2 color="#0000FF">This session will despatch the mails 1, 3 for mailbox 1 </b>immediately.. and the remaining mails will be despatched after the smtp session quits..<br>
is it like that..?????</font></blockquote><br>
It's however the mail server that you're talking to wants to do it... I'd expect a mail server that didn't know anything about &quot;mailbox1&quot; just to ignore (or return an error for) the ETRN command.<br>
Some mail servers may dispatch all the messages immediately, or they may wait an unspecified amount of time before dispatching them, or they may dispatch some sooner than others, etc. The SMTP standard doesn't specify anything about this at all.<br><br>
<x-sigsep><p></x-sigsep>
Paul<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>VPOP3 - Internet Email Server/Gateway<br>
[email-masked]<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab><a href="http://www.pscs.co.uk/" eudora="autourl">http://www.pscs.co.uk/<br><br>
</a></body>
</html>

--=====================_700780546==.ALT--

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: About TURN and ETRN command
Date: Thu, 12 May 2005 08:17:07 -0400
Cc: "Vijayan" <[email-masked]>
Sender: [email-masked]

On Thu May 12 2005 07:24, Vijayan wrote:

> i wanna clarify my doubt in using TURN and ETRN commands

You probably don't "wanna" use TURN; it has some security issues.

ETRN isn't generally useful; some of the problems are described along
with the specification, in RFC 1985.  Note that it can only be used
with ESMTP, and only if offered by the server as a supported extension.
 
> This session will despatch the mails 1, 3 for mailbox 1 immediately.. and the remaining mails will be despatched after the smtp session quits..
> is it like that..?????

No.

A single transaction consists of
 MAIL FROM: <[email-masked]>
 RCPT TO: <[email-masked]>
 DATA
commands (after a session is started, of course). Between multiple
transactions, there is usually a RSET command.  And theree may be
multiple RCPT TO commands within a single transaction.

After a successful response to the DATA command, the message is queued
for delivery.  Even if the session times out or the TCP connection is
broken, that will happen (in conforming implementations).  A particular
implementation might immediately process (rather than defer queue
processing) a given transaction while other transactions are taking
place in a session.  So in general you cannot say when a particular
transaction will be processed -- once the server has issued a positive
response to the DATA command, it has taken responsibility for delivery.

ETRN is supposedly used to cause queued messages (on the server)
"destined" for some domain to be processed when the client sends an
ETRN command specifying that domain, as in
 ETRN foo.bar.grimble.pritz.example.com
One problem is that the server might not recognize that domain name;
it might queue messages for that domain under mx.blurfl.example.com,
for example (and in general, the client has no way of knowing that).
Note in particular that ETRN does not take a mailbox as the argument
(unlike MAIL FROM and RCPT TO).

From: "Vijayan" <[email-masked]>
To: <[email-masked]>
Cc: "Robert A. Rosenberg" <[email-masked]>, "John C Klensin" <[email-masked]>, "Hector Santos" <[email-masked]>
Subject: About TURN and ETRN command
Date: Thu, 12 May 2005 16:54:03 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_01B1_01C55713.33E10FF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

sorry for disturbing u guys..

pls help me in this..!!

i wanna clarify my doubt in using TURN and ETRN commands

i cldn't understand that what this RFC documents r telling.. i will give =
one runtime sample , as what i'm thinking..

    1. starting SMTP session.

    2. starting the mail transaction for <mailbox 1>
    3. queuing the mail..

    4. starting the mail transaction for <mailbox 2>
    5. queuing the mail..

    6. starting the mail transaction for <mailbox 1>
    7. queuing the mail..

    8. ETRN <MailBox1>

    9. starting mail transaction for another mail boxes..
    .....
    ...
    ...
    ...
    10. quit

This session will despatch the mails 1, 3 for mailbox 1 immediately.. =
and the remaining mails will be despatched after the smtp session =
quits..
is it like that..?????

if it is wrong please let me know the actual use of this commands, using =
some runtime samples..

thanks in advance.
Vijayan

------=_NextPart_000_01B1_01C55713.33E10FF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>sorry for =
disturbing u=20
guys..</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>pls help me in=20
this..!!</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>i wanna clarify =
my doubt in=20
using </FONT><STRONG>TURN </STRONG>and<STRONG> ETRN </STRONG><FONT=20
face=3D"Courier New" color=3D#0000ff size=3D2>commands</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>i cldn't =
understand that what=20
this RFC documents r telling.. i will give one runtime sample , as what =
i'm=20
thinking..</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>1. starting =
SMTP=20
    session.</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>2. starting =
the mail=20
    transaction for <STRONG>&lt;mailbox 1&gt;</STRONG></FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>3. queuing =
the=20
    mail..</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>4. starting =
the mail=20
    transaction for <STRONG>&lt;mailbox 2&gt;</STRONG></FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>5. queuing =
the=20
    mail..</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>6. starting =
the mail=20
    transaction for <STRONG>&lt;mailbox 1&gt;</STRONG></FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>7. queuing =
the=20
    mail..</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>8. ETRN=20
    <STRONG>&lt;MailBox1&gt;</STRONG></FONT></DIV>
    <DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
    size=3D2></FONT></STRONG>&nbsp;</DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff=20
    size=3D2><STRONG>9.</STRONG>&nbsp;starting mail transaction for =
another mail=20
    boxes..</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>.....</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>...</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>...</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>...</FONT></DIV>
    <DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>10.=20
  quit</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff size=3D2>This =
session will=20
despatch the mails 1, 3 for <STRONG>mailbox 1 </STRONG>immediately.. and =
the=20
remaining mails will be despatched after the smtp session =
quits..</FONT></DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff size=3D2>is it =
like=20
that..?????</FONT></DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff size=3D2>if it =
is wrong please=20
let me know the actual use of this commands, using some runtime=20
samples..</FONT></DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>thanks in=20
advance.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2>Vijayan</FONT></DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_01B1_01C55713.33E10FF0--

Date: Thu, 12 May 2005 11:47:35 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: Stephane Bortzmeyer <[email-masked]>, [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Organization: NIC France
Sender: [email-masked]

On Tue, May 10, 2005 at 05:06:09PM +0200,
 Markus Stumpf <[email-masked]> wrote 
 a message of 24 lines which said:

> Are you sure this is done in the MTA phase and not in the MDA oder
> MSA phase?

Many programs do not clearly separate the MTA and the MSA. Postfix is
a typical example. Again, the reality is not what we would like it to
be.

Date: Thu, 12 May 2005 02:00:49 -0400
To: <[email-masked]>
From: "Robert A. Rosenberg" <[email-masked]>
Subject: Re: HELO/EHLO questions [was Re: New guy to this list..]
Sender: [email-masked]

At 11:11 -0400 on 05/11/2005, Hector Santos wrote about HELO/EHLO 
questions [was Re: New guy to this list..]:

>Since ESMTP is optional,  legacy SMTP client systems will use the HELO
>command.

I think this should be "Since ESMTP is optional (UNLESS ISP Policy is 
to REQUIRE ESMTP),  legacy SMTP client systems will use the HELO 
command".

If I am running a MSA ESMTP Server on Port 587, then EHLO is REQUIRED 
and an attempt to try to connect with HELO is cause for a REJECTION 
(since there is no way to offer the needed 250 AUTH reply to a HELO).

Date: Wed, 11 May 2005 16:14:21 -0400
From: John C Klensin <[email-masked]>
To: Frank Ellermann <[email-masked]>, [email-masked]
cc: [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

--On Wednesday, 11 May, 2005 21:19 +0200 Frank Ellermann
<[email-masked]> wrote:

> 
> John C Klensin wrote:
> 
>> I am, "dude" or not, somewhat familiar with how SMTP works.
> 
> :-)
>    
> Anybody listed in RfC 1123 is "guilty until proven innocent".

Well, since my name is also at the top of RFC 1869 and its
predecessors and on RFC 2821, my involvement with ARPANET/
Internet email goes back to the decision to put a "MAIL" verb in
the original FTP, and my resume has both "former IETF Area
Director for Applications" and "former IAB Chair" on it, I'm
pretty much about as implicated as one can get.  :-)

> As soon as time travel is available I intend to discuss all
> implications of 5.3.6 (a) and 5.3.3 with the authors.  Maybe
> the net at large sponsors the trip back to 1989.

Some of those issues where intended to be clarified in 2821.  If
you don't think the clarifications were adequate, or if there is
still uncertainty for other reasons, this would be a good time
to let me know.

  Bye, Frank

best,
    john

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: draft-duan-smtp-receiver-driven-00.txt
Date:  Wed, 11 May 2005 21:19:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 11
Cc: [email-masked]
Sender: [email-masked]

John C Klensin wrote:

> I am, "dude" or not, somewhat familiar with how SMTP works.

:-)
   
Anybody listed in RfC 1123 is "guilty until proven innocent".
As soon as time travel is available I intend to discuss all
implications of 5.3.6 (a) and 5.3.3 with the authors.  Maybe
the net at large sponsors the trip back to 1989.  Bye, Frank

Date: Wed, 11 May 2005 12:15:37 -0700
From: David Hagel <[email-masked]>
Reply-To: David Hagel <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 5/11/05, Arnt Gulbrandsen <[email-masked]> wrote:
> David hagel writes:
> > its almost impossible to spoof tcp sessions now. spoofer needs to
> > correctly guess the randomly generated sequence/ack numbers.
> 
> Have a look at http://www.completewhois.com/hijacked/ for an
> alternative, simpler approach.

granted one can steal whole ip blocks. 
its still ok blacklisting those ip blocks if its in the hands of
spammers. right?

Date: Wed, 11 May 2005 15:05:30 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: John C Klensin <[email-masked]>
Cc: David hagel <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

John,

>
> That situation is precisely why I started my comment with
> "unless you abandon mail relaying".  If you insist on direct
> connections between the initial sender (or an MTA that will take
> responsibility for the sender and which you trust to do so) and
> the receiver/ delivery SMTP server, then you are quite right and
> the spoofing issue depends on control of intermediate routers
> (and/or much more sophisticated tricks).  But, as long as
> intermediate SMTP relays (not routers, but at the SMTP level)
> continue to be permitted, TCP is just not the issue because
> there is no end to end connection.

This (open relay) is one part that puzzled me from time to time. Correct 
me if I am wrong. In the early days, the Internet is not stable and we may 
have difficults sometime to deliver a message from the source MTA directly 
to the destination MTA. Under this kind of circumstance, I may appreciate 
open relays. However, as the Internet is getting so (reasonably) reliable. 
I think some assumption should be changed. I do not know how often we 
still encounter network problems when we (sender) try to deliver a message 
to a receiver. I assume it is rare. And even if this happens, I do not see 
it is a big problem for the original SMTA to hold the message and retry 
later.

In a nutshell, I believe all open relays should be disabled or otherwise 
blocked.

(I do not want to go into a fight:-), so I make it clear that we are 
talking about open relay, not MTA clusters, not the cases where a company 
have multiple MTAs, and one (or more) are used for external-internal 
interface, while others are used internals and depending on the interface 
MTA to do the relay. It can be seen that these situations can be addressed 
adequately.)

-Zhenhai
>
> The workings of most blacklists have nothing to do with this
> because they depend on either most-recent-hop or on assumptions
> about [dis]trusted SMTP servers at intermediate points rather
> than, as this does, properties of the initiating sender system.
> And, of course, if they worked better, you presumably would not
> need the draft in question.
>
>       john
>
>
>
>
>
>

Date: Wed, 11 May 2005 14:51:18 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: Kartik Gopalan <[email-masked]>, [email-masked], [email-masked], [email-masked], Yingfei Dong <[email-masked]>
Subject: Re: Re: Re: draft-duan-smtp-receiver-driven-00.txt 
Sender: [email-masked]

Tony,

>
>> It is possible that instead of relying on RMTA to record the SMTA IP
>> address, we can do a DNS MX lookup of sender email address to get the
>> MTA IP address at the sender side. However, this indeed means that if
>> sender side uses different MTA servers for incoming and outgoing
>> messages, they need to be in sync about state of outgoing message queue
>> (for example, shared file systems).
>
> Gee, that's a good idea. Imagine a shared filesystem supporting the whole
> email infrastructure for millions of customers!
>

I think there is some misunderstanding. Note that this is for supporting 
MTA clusters. Shared file systems/NFS/Replications are used in today's MTA 
clusters.

-Zhenhai
> 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: Wed, 11 May 2005 11:48:17 -0700
From: David hagel <[email-masked]>
Reply-To: David hagel <[email-masked]>
To: John C Klensin <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> That situation is precisely why I started my comment with
> "unless you abandon mail relaying".  If you insist on direct
> connections between the initial sender (or an MTA that will take
> responsibility for the sender and which you trust to do so) and
> the receiver/ delivery SMTP server, then you are quite right and
> the spoofing issue depends on control of intermediate routers
> (and/or much more sophisticated tricks).  But, as long as
> intermediate SMTP relays (not routers, but at the SMTP level)
> continue to be permitted, TCP is just not the issue because
> there is no end to end connection.
> 
> The workings of most blacklists have nothing to do with this
> because they depend on either most-recent-hop or on assumptions
> about [dis]trusted SMTP servers at intermediate points rather
> than, as this does, properties of the initiating sender system.

ah, then ip spoofing is not quite the same as hiding behind 
someone else's mail relays. i admit missing the connection 
you made there. but open mail relays are hated and justifiably blacklisted 
aggresively (i am sure you know).  its the right thing to do. ain't it?
no harm blocking someone who lets their mail server to be 
used by spammers.

david

Date: Wed, 11 May 2005 14:45:38 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: Hector Santos <[email-masked]>
Cc: Kartik Gopalan <[email-masked]>, IETF-SMTP <[email-masked]>, Yingfei Dong <[email-masked]>
Subject: Re: [SPAM] - Re: Re: draft-duan-smtp-receiver-driven-00.txt - Email found in subject
Sender: [email-masked]

Hector,

> For example, I don't want to put a barrier up to potential customers sending
> sales inquiries to [email-masked].
>

I do not like neither :-)

That is why *I* think that the definition of the sender classes should be 
separated from the protocol design itself. For example, I can include only 
my regular contacts in the allowed class, others (not black listed) are in 
the unclassified class, no matter I first time see it or I saw it before.

Dont get me wrong. Of course the definition of regular contacts for 
different accounts can be quite different. For example, 
[email-masked] may have a much less retricted rule about the allowed 
class, while some others would like to open to the world.

> Keep in mind the idea of receiving a payload for post authentication
> concepts can be very problematic. Microsoft's SenderID proposal has this
> problem and the key reason why we won't directly implement it into the SMTP
> server.

I guess I did not make it clear. I menioned that we can use the sender 
email address to look up the SMTA instead of relying on the RMTA to record 
the IP address of the SMTA, it does not mean that we will accept the 
payload (the DATA command). We just need the sender email address from the 
MAIL FROM command.

> Please note, as a SMTP vendor, I am all for a great idea.  But if massive
> changes is going to be required, then it needs to make sense across the
> board.   In my view,  SMTP is a great protocol which has the elements to

Agreed. I like to hear from you guys who work in this aread.

Cheers,
-Zhenhai
> eliminate the "forging" aspect of the transaction.  SPAM Analysis and
> content analysis, to me, is out of the scope of SMTP.  It can be hooked in
> today already.  But 2822 and 2821 are two different things.   Its like the
> US postal mail man.  He could care less what he is delivering to you.  But
> you as a receiver might have place some level of scrutiny at the mail man
> before you even look at the content he is handing over to you.   Does he
> have a uniform?  Does he have a badge?  Does he look like a bum?  Do you
> recognize him?  Does he have a permit to deliver mail?   Or is he just a
> friendly neighbor who is routing mail to you?
>
> So unless the mind set can be changed to begin looking at stronger
> client/server negotiations of the SMTP transactions, and more important
> adding an enforcement level of compliance,  big changes like you suggest, I
> don't see having much value.
>
>
> --
> Hector Santos, Santronics Software, Inc.
> http://www.santronics.com
>
>
>
>
>
>
>
>
>
>
>

Date: Wed, 11 May 2005 20:38:15 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Cc: David hagel <[email-masked]>, [email-masked]
Sender: [email-masked]

David hagel writes:
> its almost impossible to spoof tcp sessions now. spoofer needs to 
> correctly guess the randomly generated sequence/ack numbers.

Have a look at http://www.completewhois.com/hijacked/ for an 
alternative, simpler approach.

(And please don't spell your name like that. It makes you look like a 
419 spammer.)

Arnt

Date: Wed, 11 May 2005 14:28:45 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: [email-masked]
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

Bruce,

>
> We already have a large, distributed, heterogeneous, deployed
> email architecture infrastructure and MTAs.  Extensions need
> to work with that existing, deployed infrastructure in a
> backwards-compatible way.  Believe it or not, the world isn't
> going to switch over to completely new MTAs overnight just
> because some draft says so.
>

Indeed we took great care of the incremental deployment issue because we 
understand the value of the infratrstucture.

1) It is easy to see that if a receiver does not support DMTP, then 
everything will be fine (it does not matter the sender supports DMTP or 
not).

2) Assuming the receiver supports DMTP, then we have two cases:

2.1) the sender supports DMTP. If so, the receiver will know this because 
of the extension we added in the ELHO command (admitted: we may have not 
followed the standarded way to extend, we will make changes in the new 
draft). So the sender and the receiver can proceed according to DMTP.

2.2) the sender does not support DMTP, the receiver will also know this 
from the extension, so they proceed using the incremental deployment 
algorithm.

Thanks,
-Zhenhai

Date: Wed, 11 May 2005 14:02:46 -0400
From: John C Klensin <[email-masked]>
To: David hagel <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

--On Wednesday, 11 May, 2005 10:43 -0700 David hagel
<[email-masked]> wrote:

> 
> On 5/10/05, John C Klensin <[email-masked]> wrote:
>> 
>> Unless you abandon mail relaying, and perhaps even if you do,
>> domain names and IP addresses are as easily spoofed as full
>> email addresses.  The spammers figured both out many years
>> ago.
>> 
> 
> you're mistaken. udp spoofing is easy BUT smtp uses tcp.
> its almost impossible to spoof tcp sessions now.
> spoofer needs to correctly guess the randomly generated
> sequence/ack numbers. even if you magically do this, you gotta
> control ALL intermediate routers or else smtp server's
> responses will be misdirected. meaning you cannot create a
> normal tcp session.
> it's a common misconception that "ip spoofing"
> can be used to hide your ip address while surfing the net,
> chatting on-line, sending e-mail, and so forth.
> this is not true unless you're on the same subnet as victim
> where you can sniff their tcp seq. #'s.
> if whay you say is true, all DNSBLs would stop working dude.

(The reply below was previously sent privately because Mr Hagel
and/or his MUA seem to be unable to send an individual message
that reflects the mailing lists to which it was copied.)

David,

I am, "dude" or not, somewhat familiar with how SMTP works.
There are rumors that I actually also understand something about
TCP and about the DNS, but those rumors are less well
established.

However, the comment I made is not dependent on TCP, merely on
the ability of a spammer who is operating an SMTP-sender to fake
the Received headers in a message prior to those representing
the SMTP-receiver over which you have presumed control and/or
trust.  There are various tricks for detecting such spoofing.
Some of them can be quite effective against spammers who are
either dumb or too lazy to be careful and intelligent about
construction of those trace fields... both of which disabilities
tend to disappear if their incentives were strong enough.

That situation is precisely why I started my comment with
"unless you abandon mail relaying".  If you insist on direct
connections between the initial sender (or an MTA that will take
responsibility for the sender and which you trust to do so) and
the receiver/ delivery SMTP server, then you are quite right and
the spoofing issue depends on control of intermediate routers
(and/or much more sophisticated tricks).  But, as long as
intermediate SMTP relays (not routers, but at the SMTP level)
continue to be permitted, TCP is just not the issue because
there is no end to end connection.

The workings of most blacklists have nothing to do with this
because they depend on either most-recent-hop or on assumptions
about [dis]trusted SMTP servers at intermediate points rather
than, as this does, properties of the initiating sender system.
And, of course, if they worked better, you presumably would not
need the draft in question.

       john

Date: Wed, 11 May 2005 10:43:05 -0700
From: David hagel <[email-masked]>
Reply-To: David hagel <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

On 5/10/05, John C Klensin <[email-masked]> wrote:
>
> Unless you abandon mail relaying, and perhaps even if you do,
> domain names and IP addresses are as easily spoofed as full
> email addresses.  The spammers figured both out many years ago.
>

you're mistaken. udp spoofing is easy BUT smtp uses tcp.
its almost impossible to spoof tcp sessions now.
spoofer needs to correctly guess the randomly generated sequence/ack
numbers. even if you magically do this, you gotta control ALL
intermediate routers or else smtp server's responses will be misdirected.
meaning you cannot create a normal tcp session.
it's a common misconception that "ip spoofing"
can be used to hide your ip address while surfing the net,
chatting on-line, sending e-mail, and so forth.
this is not true unless you're on the same subnet as victim
where you can sniff their tcp seq. #'s.
if whay you say is true, all DNSBLs would stop working dude.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked], Kartik Gopalan <[email-masked]>
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Date: Wed, 11 May 2005 11:35:17 -0400
Sender: [email-masked]

On Tue May 10 2005 22:50, Kartik Gopalan wrote:
>That's why DMTP  *is* backward-compatible
> and would work with any legacy SMTP MTAs.

It most certainly is not backwards compatible:
o it foists "new" response codes on servers w/o negotiation
o it adds new requirements for long-term storage of messages
etc.

That's simply unacceptable for an extension to a core applications
protocol which carries mission-critical payloads.  There is an
established extension mechanism (RFC 1869).  See RFCs 1870, 2920,
and 3461 for examples of how to extend the protocol in a backwards
compatible manner.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, "Vijayan" <[email-masked]>
Cc: "John C Klensin" <[email-masked]>
Subject: HELO/EHLO questions [was Re: New guy to this list..]
Date: Wed, 11 May 2005 11:11:22 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Vijayan" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, May 11, 2005 9:52 AM
Subject: New guy to this list..

> This is Vijayan from Bangalore,India, working as a Soft.Engr.
> Presently i'm doing a project in a Mailing application.. my module is
SMTP.

Welcome.

> I have some couple of doubts in SMTP standards..

You mean you have a couple of misunderstanding in the SMTP standards?  :-)

> 1. What is the actual difference between HELO and EHLO commands.. what is
the
> use of these two different commands.. when to use which... and why..???

EHLO stands for "Extended HELO."

Extended SMTP (ESMTP) offers developers a way to add new features, commands
or keywords, etc.

For a standard HELO,  you don't except to see multiline responses:

    C: HELO <our client domain host name>
    S: 250 <your host domain name>, welcome string

When EHLO is sent, the response is usually a multi-line response that
exposes the "extended options available" by the server:

    C: EHLO <our client domain host name>
    S: 250-<your host domain name>, welcome string
    S: 250-SIZE 5120000
    S: 250-ETRN
    S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1
    S: 250-AUTH=LOGIN
    S: 250 HELP

So the EHLO response contains keywords to tells the ESMTP compliant client
software what features are available at the ESMTP compliant server software.

Since ESMTP is optional,  legacy SMTP client systems will use the HELO
command.

If a SMTP client system supports ESMTP, then it must use EHLO first, and
fall back to HELO if the remote hosting server does not recognize EHLO.

    C: EHLO <our client domain host name>
    S: 502 unrecognized command
    C: HELO <our client domain host name>
    S: 250 <your host domain name>, welcome string

>  2. I had read in the RFC , that this commands (HELO/EHLO) r used to tell
what
> is the Client SMTP the SMTP Server. (is it correct ??)..

If I understand your question,  I believe it is just a BCP (Best Current
Practice) and not a required standard where the the initial connection
server 220 welcome response string *may* include a tag "ESMTP" to indicate
this server is ESMTP ready, some like so:

        Incoming connection:
        S: 220 <your domain> [product name version ] ESMTP ready

But you can't rely on this and the standard for ESMTP clients is to try EHLO
first and fall back to HELO if EHLO is not supported.

> then in that case even if i'm sending a command like
>
>   EHLO 123 or EHLO junk / EHLO pheeeen"
>
> it is accepting.. why..??

Because SMTP does not have real "strong" rules about the validity of the
helo/ehlo client domain name.

However, this is changing as part of the new era of client
authentication/authorization systems being explored.  So you are best to
follow the RULES and supply a valid client domain name.

To John Klensin:

This is what I am talking about the outdated specifications.  We need to get
them updated to guide and change the mind set for new developers.   The
spirit of the document has to mandate technical compliance and security
first in the new era.  We need to get server developers "more" authority in
enforcing the rules without being condemned.

This is the only way the new proposals are going to have a chance to be
effective.  It will take a while, but atleast we will have it written in
stone.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Wed, 11 May 2005 10:26:33 -0400
From: John C Klensin <[email-masked]>
To: Vijayan <[email-masked]>
cc: [email-masked]
Subject: Re: New guy to this list..
Sender: [email-masked]

--On Wednesday, 11 May, 2005 19:22 +0530 Vijayan
<[email-masked]> wrote:

> Hi All,
> 
> This is Vijayan from Bangalore,India, working as a Soft.Engr.
> Presently i'm doing a project in a Mailing application.. my
> module is SMTP.
> 
> I have some couple of doubts in SMTP standards..
> 
> 1. What is the actual difference between HELO and EHLO
> commands.. what is the use of these two different commands..
> when to use which... and why..???

Use of HELO indicates support for (only) SMTP as defined in RFC
821.  Use of EHLO indicates that one is able to handle the
extended options and responses of RFC 2821 and related
standards.   If you are doing any sort of new development,
support of RFC 2821, and hence EHLO, is strongly recommended
since a number of new features depend on it.

> 2. I had read in the RFC , that this commands (HELO/EHLO) r
> used to tell what is the Client SMTP the SMTP Server. (is it
> correct ??).. then in that case even if i'm sending a command
> like " EHLO 123 or EHLO junk / EHLO pheeeen" it is accepting..
> why..??

The EHLO command normally contains the official domain name of
the client.   However, that text is largely informational as
authentication, if needed, should come in other ways.
Consequently, rejection of an EHLO command because the domain
name is not valid is prohibited.  However, invalid syntax is
another matter: it is permitted for a server to reject an EHLO
(or HELO) command to reject all three of the examples you give
since they are clearly not fully-qualified domain names or,
using an explicit exception in RFC 2821, IP addresses.  Some
servers do reject on that basis, others do not.

> plese clarify my doubts..
> 
> hope to get an earlier response..

Hope that helps.

    john

From: "Hector Santos" <[email-masked]>
To: "Zhenhai Duan" <[email-masked]>
Cc: "Kartik Gopalan" <[email-masked]>, "IETF-SMTP" <[email-masked]>, "Yingfei Dong" <[email-masked]>
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Date: Wed, 11 May 2005 10:15:43 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Zhenhai Duan" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: "Kartik Gopalan" <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Yingfei Dong" <[email-masked]>
Sent: Tuesday, May 10, 2005 4:03 PM
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt

> Our comparison above was to IM2000. Indeed the current SMTP servers
> know how to handle senders that are denied (blacklisted), or allowed
> (whitelisted). A message that falls in neither class is currently
> subject to the content filters to decide if it is a spam message or
> not. To put it another way, the current SMTP does not have an explicit
> concept of unclassified senders.

Hmmm,  I believe we do. It is called "anonymous" clients.

Currently, the BCP is to only allow anonymous "unclassified" senders to send
local or hosted final destination mail. Otherwise we have what is generally
called a "open relay."  The basic rule of thumb is  Anonymous Senders
(unclassified) can only send local mail and  Authorized Senders (classified)
can relay mail.

Since some form of authentication is required for relaying mail,  by far,
the troublesome issue of problematic transactions is due to the unclassified
nature of anonymous senders.

For our SMTP server logic,  the default is email
authentication/authorization only kicks in for anonymous "unclassified"
clients.

> The one we are aware of that supports
> the similar concept is Greylisting, which defines unclassified sources
> as new triplets that are not in the whitelist and blacklist yet.

Call Back Verifiers (CBV) are also in place which is essentially a
"SMTP-based challenge" to validate the reverse path, dynamically and only
the spot, based on the theory that a Bounce Address must be correct as soon
as it is provided.   This helps eliminates NXDOMAIN and bad email domains
transactions.  Rejection are 45x based so a good system that is
"temporarily" down will try again.  Bad Systems do not.

Don't forget SPF (and her clones) - which is currently arguably the
"pseudo-standard" and/or direction many in the industry is heading and/or
exploring.  SPF attempts to validate the transaction IP address against the
email and/or client domains using a DNS based domain published policy.

So indeed there is quite an effort going on to address the "unclassified"
anonymous senders.

Mind you, a recent concern is addressing the abused ISP user who will
authenticate to bypass any smtp checking.     I believe most believe the
only non-intrusive effective way to address this is by using a message
posting pattern recognition technique.

> However, as other people on this list have pointed out already,
> spammers haven't yet adapted to this scheme because it hasn't impacted
> their bottomline. This would happen once greylisting becomes
> widespread.

Greylisting, in my perspective , is mostly used at the low end of the
spectrum. Although there are more of the low end server than the comparably
less large systems as a whole, off hand, I don't know of any major or larger
ISP or corporation that uses GreyListing, and for good reason.  These
delayed challenge response systems is problematic in the business market.
For example, I don't want to put a barrier up to potential customers sending
sales inquiries to [email-masked].

So I personally don't see Greylisting become mainstream. I think the
industry will look for something else first before they put up contact
barriers.

> This is a good point and Kartik's email addressed your question to
> some extent by mentioning that some MTA modifications are inevitable
> to make them DMTP-compliant. As it is in the current draft, the sender
> MTA IP address is used for the RMTA to retrieve the complete message.

Keep in mind the idea of receiving a payload for post authentication
concepts can be very problematic. Microsoft's SenderID proposal has this
problem and the key reason why we won't directly implement it into the SMTP
server.

The idea is to not accept the payload if the transaction parameters are not
good.

By accepting the payload, you increase the effectiveness of spammer's
mailing list.  They could care less of the payload is eventually accepted or
not.   If a spammer can show thier customers that a good bit of their
addresses are making it pass the door (SMTP level) then this tends to
increase the marketability of the mailing list.   The secondary acceptance
of the message itself by the user is just the cat's meow.

> We made this choice because of security concerns and also for the
> simplicity of the RMTA. It is possible that instead of relying on RMTA
> to record the SMTA IP address, we can do a DNS MX lookup of sender
> email address to get the MTA IP address at the sender side. However,
> this indeed means that if sender side uses different MTA servers for
> incoming and outgoing messages, they need to be in sync about state of
> outgoing message queue (for example, shared file systems). In the long
> run, its a tradeoff worth making.

Personally, I doubt that it is. I think the redesign requirements do not
give you
any more value than what is currently available and in place using a
"current
SMTP compliant" model to address the anonymous (unclassified) mail sender.

You need to keep in mind that based on industry empirical data, 60-80% of
all anonymous transactions are problematic and a majority of these can be
addressed at the SMTP level.  Most of the concern I believe the cogs have
with the proposed methods is overhead and redundancy related.

At the very least, I think the only real bonus in the proposal is Message ID
tracking.

If MSID is used to track messages, then call back or other similar systems
can use this information to obtain originality.

If every system was required to keep a table of MSID, then we have
trackability (technical) and accountability (legal).

Please note, as a SMTP vendor, I am all for a great idea.  But if massive
changes is going to be required, then it needs to make sense across the
board.   In my view,  SMTP is a great protocol which has the elements to
eliminate the "forging" aspect of the transaction.  SPAM Analysis and
content analysis, to me, is out of the scope of SMTP.  It can be hooked in
today already.  But 2822 and 2821 are two different things.   Its like the
US postal mail man.  He could care less what he is delivering to you.  But
you as a receiver might have place some level of scrutiny at the mail man
before you even look at the content he is handing over to you.   Does he
have a uniform?  Does he have a badge?  Does he look like a bum?  Do you
recognize him?  Does he have a permit to deliver mail?   Or is he just a
friendly neighbor who is routing mail to you?

So unless the mind set can be changed to begin looking at stronger
client/server negotiations of the SMTP transactions, and more important
adding an enforcement level of compliance,  big changes like you suggest, I
don't see having much value.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

From: "Vijayan" <[email-masked]>
To: <[email-masked]>
Subject: New guy to this list..
Date: Wed, 11 May 2005 19:22:00 +0530
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0160_01C5565E.B4BFCB30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All,

This is Vijayan from Bangalore,India, working as a Soft.Engr.
Presently i'm doing a project in a Mailing application.. my module is =
SMTP.

I have some couple of doubts in SMTP standards..

1. What is the actual difference between HELO and EHLO commands.. what =
is the use of these two different commands.. when to use which... and =
why..???

2. I had read in the RFC , that this commands (HELO/EHLO) r used to tell =
what is the Client SMTP the SMTP Server. (is it correct ??)..
then in that case even if i'm sending a command like " EHLO 123 or EHLO =
junk / EHLO pheeeen" it is accepting.. why..??

plese clarify my doubts..

hope to get an earlier response..

thanks in advance..

bye..

Vijayan

------=_NextPart_000_0160_01C5565E.B4BFCB30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Hi =
All,</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>This is Vijayan =
from=20
Bangalore,India,&nbsp;working as a Soft.Engr.</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>Presently i'm =
doing a project=20
in a Mailing application.. my module is SMTP.</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>I have some =
couple of doubts=20
in SMTP standards..</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2><STRONG>1.</STRONG> What is=20
the actual difference between <STRONG>HELO</STRONG> and =
<STRONG>EHLO</STRONG>=20
commands.. what is the use of these two different commands.. when to use =

which... and why..???</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff =
size=3D2><STRONG>2.</STRONG> I had=20
read in the RFC , that this commands (HELO/EHLO) r used to tell what is =
the=20
Client SMTP the SMTP Server. (is it correct ??)..</FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff size=3D2>then in that =
case even if i'm=20
sending a command like " <STRONG>EHLO 123</STRONG> or <STRONG>EHLO =
junk</STRONG>=20
/ <STRONG>EHLO pheeeen" </STRONG>it is accepting.. why..??</FONT></DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff size=3D2>plese =
clarify my=20
doubts..</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff size=3D2>hope to =
get an=20
earlier response..</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff size=3D2>thanks =
in=20
advance..</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2>bye..</FONT></STRONG></DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT></STRONG>&nbsp;</DIV>
<DIV><STRONG><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2>Vijayan</FONT></STRONG></DIV>
<DIV><FONT face=3D"Courier New" color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0160_01C5565E.B4BFCB30--

Date: Tue, 10 May 2005 19:50:03 -0700
From: Kartik Gopalan <[email-masked]>
Reply-To: Kartik Gopalan <[email-masked]>
To: [email-masked]
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

> > The point is to design the
> > MTA to fit the email architecture, not to design the email
> > architecture to fit the current MTA design. Else you are simply
> > putting the cart before the horse.
> 
> We already have a large, distributed, heterogeneous, deployed
> email architecture infrastructure and MTAs.  Extensions need
> to work with that existing, deployed infrastructure in a
> backwards-compatible way.  Believe it or not, the world isn't
> going to switch over to completely new MTAs overnight just
> because some draft says so.

I agree completely with you. That's why DMTP  *is* backward-compatible
and would work with any legacy SMTP MTAs. There is no requirement for
everyone to switch to DMTP overnight at the same time. This is indeed
one of the central considerations in this proposal. The argument we
were responding to above was that it is supposedly impossible to
redesign MTA clusters -- takes some effort, but its feasible and
doesn't have to be done overnight by everybody. These systems designs
are not that static anyway, they have to be evolving even now as we
speak.

- Kartik

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Date: Tue, 10 May 2005 19:15:50 -0400
Sender: [email-masked]

On Tue May 10 2005 18:27, Kartik Gopalan wrote:

> The point is to design the
> MTA to fit the email architecture, not to design the email
> architecture to fit the current MTA design. Else you are simply
> putting the cart before the horse.

We already have a large, distributed, heterogeneous, deployed
email architecture infrastructure and MTAs.  Extensions need
to work with that existing, deployed infrastructure in a
backwards-compatible way.  Believe it or not, the world isn't
going to switch over to completely new MTAs overnight just
because some draft says so.

Date: Tue, 10 May 2005 15:27:29 -0700
From: Kartik Gopalan <[email-masked]>
Reply-To: Kartik Gopalan <[email-masked]>
To: Tony Finch <[email-masked]>
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> > You missed one more piece of information in the notification: a
> > limited subject header summarizing the contents.
> 
> A wonderful place to put a spam message and URL.

It says "limited subject header" above which can include restrictions
on placing URLs.
(I had mentioned this already earlier.)

> > 1) Your regular contacts will typically be in the allowed class. If
> > you see a notification from your regular contact that is in the
> > unclassified folder, it is easy to tell it is a faked message and you
> > need not spend time on it.
> 
> This statement is not generally true. For example, the IP addresses of the
> sending site's MTAs may have changed, or the sender may be roaming.

Its the sender that's is roaming, not the sending MTA -- I don't see
any problem. And if the sending MTA changes its IP address, the
currently used  IP-based blacklists and whitelists go for a toss
anyway. So its not a new problem here.

> > messages, they need to be in sync about state of outgoing message queue
> > (for example, shared file systems).
> 
> Gee, that's a good idea. Imagine a shared filesystem supporting the whole
> email infrastructure for millions of customers!

Again, it said "for example" above. Its an engineering decision that
would be different for different situations that designers make every
day depending on the scale of the system. The point is to design the
MTA to fit the email architecture, not to design the email
architecture to fit the current MTA design. Else you are simply
putting the cart before the horse.

- Kartik

Date: Tue, 10 May 2005 21:54:33 +0100
From: Tony Finch <[email-masked]>
To: Zhenhai Duan <[email-masked]>
cc: Tony Finch <[email-masked]>, Kartik Gopalan <[email-masked]>, [email-masked], [email-masked], [email-masked], Yingfei Dong <[email-masked]>
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

> You missed one more piece of information in the notification: a
> limited subject header summarizing the contents.

A wonderful place to put a spam message and URL.

> 1) Your regular contacts will typically be in the allowed class. If
> you see a notification from your regular contact that is in the
> unclassified folder, it is easy to tell it is a faked message and you
> need not spend time on it.

This statement is not generally true. For example, the IP addresses of the
sending site's MTAs may have changed, or the sender may be roaming.

> 2) For the other legitimate senders that are not in your allowed
> class, how often you hear from them?

These kinds of messages are frequently extremely valuable.

> It is possible that instead of relying on RMTA to record the SMTA IP
> address, we can do a DNS MX lookup of sender email address to get the
> MTA IP address at the sender side. However, this indeed means that if
> sender side uses different MTA servers for incoming and outgoing
> messages, they need to be in sync about state of outgoing message queue
> (for example, shared file systems).

Gee, that's a good idea. Imagine a shared filesystem supporting the whole
email infrastructure for millions of customers!

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: Tue, 10 May 2005 16:03:26 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: Kartik Gopalan <[email-masked]>, [email-masked], [email-masked], [email-masked], Yingfei Dong <[email-masked]>
Subject: Re: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

Tony,

Thank you for the helpful discussions. Let me try to clarify some of
the intuition behind the schemes in the I-D.

>> DMTP classifies sender MTAs into three categories: allowed, denied, and
>> unclassified.
>
> So do SMTP servers.

Our comparison above was to IM2000. Indeed the current SMTP servers
know how to handle senders that are denied (blacklisted), or allowed
(whitelisted). A message that falls in neither class is currently
subject to the content filters to decide if it is a spam message or
not. To put it another way, the current SMTP does not have an explicit
concept of unclassified senders. The one we are aware of that supports
the similar concept is Greylisting, which defines unclassified sources
as new triplets that are not in the whitelist and blacklist yet.
However, as other people on this list have pointed out already,
spammers haven't yet adapted to this scheme because it hasn't impacted
their bottomline. This would happen once greylisting becomes
widespread.

>> The receiver pull model is only used for messages from the unclassified
>> category.
>
> And this is the category of messages where it is least useful. You are
> forcing people to guess whether they want to receive a message before you
> have expended any automated effort to classify it.
>

This really is related to what kind of classification we are talking
about. As one example, the receiver can configure his/her MTA such
that most regular contacts are in the allowed class. As a consequence,
after a brief learning time period, most important messages fall in
the allowed category (that do not need the notification process) and
the receiver pays only infrequent attention to the notifications in
the unclassfied folder. Note that this definition of classification is
different and orthogonal from classifying a message based on its
content. Occasionally, an important message may lie unread for a long
time -- its not desirable but it is not a new problem. It happens even
now with automated content-based classifiers you mention above. You
get false positives all the time even now -- they are either tagged as
[SPAM] to be stored away in a junk folder or (worse yet) deleted
without receiver's knowledge. With DMTP, at least receiver gets to
periodically review the notifications from these unclassified senders
(if receivers so choose to).

> You have not addressed the user interface issues of DMTP. How is a user
> supposed to decide whether to receive a message given only the sender
> address and message ID? You suggest that message IDs should be
> cryptographically generated, and therefore meaningless to people, and you
> do not address the problem of forged sender addresses. Therefore DMTP's
> notification messages are useless to the recipient.

You missed one more piece of information in the notification: a
limited subject header summarizing the contents.  You may say that
"well subject can be misleading and sender address can be forged to
make it appear like a regular contact". Its possible and happens with
viruses all the time. But this technique is useless to spammers
because it doesn't help them to send the tremendous volume of
commercial traffic that makes spamming so attractive. Just imagine the
amount of state and association they need to maintain per spammed
receiver to make heavy volume mailing successful with this technique.

Also,
1) Your regular contacts will typically be in the allowed class. If
you see a notification from your regular contact that is in the
unclassified folder, it is easy to tell it is a faked message and you
need not spend time on it.

2) For the other legitimate senders that are not in your allowed
class, how often you hear from them? and how likely is it that a
spammer knows that this is not only your legitimate contact but ALSO
is not in your regular contact class?

> You are assuming that each server's idea of its own IP address is the same
> as the other TCP endpoint's idea of it. You are assuming that incoming and
> outgoing connections to an MTA are symmetrical.

This is a good point and Kartik's email addressed your question to
some extent by mentioning that some MTA modifications are inevitable
to make them DMTP-compliant. As it is in the current draft, the sender
MTA IP address is used for the RMTA to retrieve the complete message.
We made this choice because of security concerns and also for the
simplicity of the RMTA. It is possible that instead of relying on RMTA
to record the SMTA IP address, we can do a DNS MX lookup of sender
email address to get the MTA IP address at the sender side. However,
this indeed means that if sender side uses different MTA servers for
incoming and outgoing messages, they need to be in sync about state of
outgoing message queue (for example, shared file systems). In the long
run, its a tradeoff worth making.

>> There is no attempt at PKI whatsoever, if that is what you mean.
>
> No, I mean that you are using a cryptographic hash incompetently.
>

We do not quite see you mentioning a specific concern here. As long as
the sender-side hash serves the purpose, it does not matter how
simple/complicated it is. For example, when you subscribe to a mailing
list, you normally receive a message asking you to confirm the intent
to subscribe. How complicated do you think the method to generate the
random text on the Subject line is?

Thank you,
  -Zhenhai

Date: Tue, 10 May 2005 15:59:45 -0400
From: John C Klensin <[email-masked]>
To: Kartik Gopalan <[email-masked]>, John C Klensin <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

--On Tuesday, 10 May, 2005 12:35 -0700 Kartik Gopalan
<[email-masked]> wrote:

> Thanks for your note. In DMTP, we use coarser MTA classifiers
> at the level of their IP address or domain names -- not the
> fine-grained email-address classifiers (as you seem to mention
> below). Using the latter would indeed have the problems you
> describe -- but DMTP I-D does not use email-address
> classifiers. Its possible to do that, but only with the kind
> of strong sender authentication you mention, which is the
> reason we steered away from them in the first place.

Unless you abandon mail relaying, and perhaps even if you do,
domain names and IP addresses are as easily spoofed as full
email addresses.  The spammers figured both out many years ago.

     john

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 10 May 2005 21:50:07 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Tue, May 10, 2005 at 02:17:00PM -0400, Bruce Lilly wrote:
> Which is equivalent to saying -- with or without RFC 2119 -- that
> success (2) and temporary failure (4) in conjunction with the
> remainder of the code is *not* useful.

No. The author writes that at the time of writing he can see no use
for that message and code other than for a permanent error. He expressly
does not forbid it (indicated by no use of RFC 2119 syntax).

If I now design a bottle opener and write "it is only useful for opening
bottles" and someone finds out that it is also perfect to screw a
certain nut in a XYZ car where is the problem? Is he not allowed to use
the bottle opener for screwing the nut because I said it is only useful
for opening bottles?

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

Date: Tue, 10 May 2005 12:35:20 -0700
From: Kartik Gopalan <[email-masked]>
Reply-To: Kartik Gopalan <[email-masked]>
To: John C Klensin <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

John, 

Thanks for your note. In DMTP, we use coarser MTA classifiers at the
level of their IP address or domain names -- not the fine-grained
email-address classifiers (as you seem to mention below). Using the
latter would indeed have the problems you describe -- but DMTP I-D
does not use email-address classifiers. Its possible to do that, but
only with the kind of strong sender authentication you mention, which
is the reason we steered away from them in the first place.

- Kartik

On 5/10/05, John C Klensin <[email-masked]> wrote:
> 
> 
> --On Tuesday, 10 May, 2005 00:52 -0400 Kartik Gopalan
> <[email-masked]> wrote:
> 
> >...
> > DMTP gives solution to the scenario that none of the currently
> > used anti-spam technologies can satisfactorily handle without
> > receiving the entire message. DMTP intent messages are used
> > ONLY for unclassified senders that are neither in receivers
> > MTA's whitelists nor blacklists.  It is only unclassified
> > senders who are treated using the receiver-pull model. And
> > even to this category you can apply the same
> > sender-discouragement schemes that are currently being applied
> > -- such as greylisting, any other challenge-response schemes,
> > etc.
> >...
> 
> Kartik,
> 
> I want to reinforce, from a different perspective, one of Tony's
> points.
> 
> Ultimately, to let a message through, you are depending on a
> whitelist that is, in turn, based on sender addresses.  Your
> greylist technique, effective or not, is ultimately just a
> technique for determining which addresses get onto the
> whitelist. That causes you to inherit all of the issues with
> whitelists based on sender addresses, especially the fact that,
> in the absence of strong authentication, sender addresses are
> easily faked.  If, as a receiver, I've got sufficient
> infrastructure --probably, but perhaps not necessarily, PKI
> machinery-- in place to authenticate sender addresses, then I
> probably don't need your technique.  If I don't, then all the
> spammer needs to do is to send messages to me that are "from"
> people whom I know and with whom I have corresponded in the
> past.
> 
> Not only is that not hard, but they are doing it today.
> 
> That brings me to the serious downside of this, and many other,
> "maybe it would help at least a little bit" ideas.    Assume,
> for purposes of argument, that the details of your proposal,
> such as not understanding how to use the SMTP extension model,
> can be sorted out.   Assume you can get it widely enough
> deployed in sending and receiving SMTP servers to make it useful
> without putting huge burdens on legitimate, known, users trying
> to exchange mail with each other (for better or worse, this is a
> very high barrier).     Now, what we end up with is:
> 
> (1) Another list of really-good addresses that can presumably be
> easily harvested by an address-harvesting virus.   Note that
> your technique is of almost zero use against a spam generator
> who relies on compromising a machine and using the sender name
> to spam the people in the and address books or using the names
> in the address book to spam the machine's owner from other
> machines at a later date.  In either case, names intentionally
> put in the address book or whitelist are presumably already
> whitelisted.
> 
> (2) Another cycle in which: (i) A technique reduces the amount
> of spam that is received slightly. (ii) The spammers respond by
> increasing the amount of spam sent by, say, twice that amount,
> resulting in a slight increase in the amount of spam received.
> (iii) The spammers then devise a countermeasure.  In this case,
> the countermeasure is quite easy: address-pair lists are
> apparently already in heavy use by some spammer-enabling tools.
> Net result is an increase in the total amount of spam being
> delivered by around twice the amount that your method presumably
> stopped.
> 
> Those "arms race" cycles are not good for anyone concerned.
> 
>      john
> 
>

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Date: Tue, 10 May 2005 14:17:00 -0400
Sender: [email-masked]

On Tue May 10 2005 11:39, Markus Stumpf wrote:

> My version of the RFC says (like yours):
> 
>    This is useful only as a permanent error.

Which is equivalent to saying -- with or without RFC 2119 -- that
success (2) and temporary failure (4) in conjunction with the
remainder of the code is *not* useful.

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 10 May 2005 17:39:52 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Cc: [email-masked], "Vaudreuil, Greg M \(Greg\)" <[email-masked]>
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Mon, May 09, 2005 at 04:11:59PM -0400, Bruce Lilly wrote:
>       X.7.1   Delivery not authorized, message refused
> 
>          The sender is not authorized to send to the destination.  This
>          can be the result of per-host or per-recipient filtering.  This
>          memo does not discuss the merits of any such filtering, but
>          provides a mechanism to report such.  This is useful only as a
>          permanent error.
> [ ... ]
> No:
> o there is no 4.7.1, only a 5.7.1.

The RFC says:
   Document Conventions
   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 BCP 14 [RFC2119].

My version of the RFC says (like yours):

   This is useful only as a permanent error.

If the author of the RFC had the intention to forbid it for non-permanent
errors he would have had to write

   This MAY only be used for permanent errors.
or
   This MUST NOT be used for non-permanent errors.

As he didn't, the comment about usefulness is a hint. Not more, not less.

I think we should stick to what is written and not to what one could interpret
from it.

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

On the topic of
   450 and 451
SMTP codes ...

http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?rev=1.11

# Before submitting a potential entry, please check that your implementation
# uses the 451 error code (not 450 or another 4xx code).  Some problems have
# been reported for sites like MSN/Hotmail, Prodigy, and various other 
# senders that appear to be having "weird" retry patterns (sometimes 
# resulting in bounces) when using code 450 or others.

# Because error code 450 is most commonly used for a mailbox lock failure,
# many sites seem to treat it as a very short duration failure, and will
# retry several times within seconds, and then bounce the mail, while they
# handle a code 451 more "normally".

We currently use

    451 4.7.1 Delivery not authorized, message refused for policy reasons, try again later

as we have noticed that a lot of communication partners often treat 450 -
besides the problems mentioned above - as a permanent error *sigh*

	\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: "Hector Santos" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: "Kartik Gopalan" <[email-masked]>, "Tony Finch" <[email-masked]>, <[email-masked]>, "Zhenhai Duan" <[email-masked]>, "Yingfei Dong" <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Date: Tue, 10 May 2005 11:16:25 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: "Tony Finch" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: "Kartik Gopalan" <[email-masked]>; "Tony Finch"
<[email-masked]>; <[email-masked]>; "Zhenhai Duan" <[email-masked]>;
"Yingfei Dong" <[email-masked]>
Sent: Tuesday, May 10, 2005 10:51 AM
Subject: Re: draft-duan-smtp-receiver-driven-00.txt

> On Tue, 10 May 2005, Hector Santos wrote:
> >
> > Off hand, I think I see a potential of DMTP becoming a source of
phishing.
> > Once the user authorizes the intent,  how to you control that a
different
> > final body of message with different intent is not delivered?
>
> You could include in the message ID a hash of the message, which the
> client can use to verify that the offered message corresponds to the
> message that was received.

But this means the message must be received ... or is this part of the
responsibility of the client?

I had a example in my original message. I removed it to reduce the message
length.  Let me show it this way.  In regards to DMTP,  a RMTP issues a MSID
line:

    MSID  id-hash-includes-msg-hash  "SMTP topic"

How would the user know what the body intent is really about?   The user
sees this system "post master" message:

        From:  DMTP PostMaster
        To: User Address
        Subject:  [Auto-Authorized Hash]

       We received an unclassified message from:

            Reverse-Address

       regarding

            "SMTP Topic"

        If you want to to receive this message, simply reply to this DMTP
notification
        message.

        DMTP PostMaster

Besides the ergonomic nuisances behind this,  how will a user know any
better?  Seems like an interesting message purely based on the topic.  Maybe
its an direct email from a person in this mailing list?

So what I am saying is that if DMTP is adopted widely, anonymous spammers
can simply use MSID lines which do not raise a red-flag.

The actual message body can be something entirely different from the topic.

> (Note: Adding this feature does not prevent stateless spam servers because
> they can still use other information in the opaque part of the message ID
> to generate spam consistent with the hash on the fly.)

I think this depends on the hasing algorythm, but I see your point.

Consider also this:

If a client system "purports" compliance with DMTP or with any advanced
extended SMTP logic, then you "got him" exactly where you want him -
adapting.

In such a movement does occur, then we got better ideas than DMTP to secure
the transaction. :-)

The problem is compliance.  No compliance.  You are back to square one.

The "greylisting" that is being implement by many is that it works with the
current SMTP flow control concepts.  No change required and its based on the
theory that bad systems do not honor the retry response codes.  Only good
systems do.  If good systems did not, then greylisting would not be used.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Tue, 10 May 2005 17:06:09 +0200
From: Markus Stumpf <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
Cc: [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Mon, May 09, 2005 at 04:26:18PM +0200, Stephane Bortzmeyer wrote:
> May be SMTP servers should not touch the headers. But they do (besides
> the obvious of adding a Received header).
> 
> * Postfix checks the Delivered-To (loop detection).
> 
> * Most MTAs add Date, To and Message-Id if they are missing (may be
> they should not, if only message submission and transfer were properly
> separated...)

Are you sure this is done in the MTA phase and not in the MDA oder MSA
phase? qmail e.g. also checks Delivered-To fields but it is done in the
MDA phase by qmail-local (i.e. during the delivery and this is also
where they get added). And qmail also adds Date and other fields but
it is done in the "sendmail" substitute that is the queue injector for non
SMTP/MSA connections.

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

Date: Tue, 10 May 2005 15:51:58 +0100
From: Tony Finch <[email-masked]>
To: Hector Santos <[email-masked]>
cc: Kartik Gopalan <[email-masked]>, Tony Finch <[email-masked]>, [email-masked], Zhenhai Duan <[email-masked]>, Yingfei Dong <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

On Tue, 10 May 2005, Hector Santos wrote:
>
> Off hand, I think I see a potential of DMTP becoming a source of phishing.
> Once the user authorizes the intent,  how to you control that a different
> final body of message with different intent is not delivered?

You could include in the message ID a hash of the message, which the
client can use to verify that the offered message corresponds to the
message that was received.

(Note: Adding this feature does not prevent stateless spam servers because
they can still use other information in the opaque part of the message ID
to generate spam consistent with the hash on the fly.)

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: "Hector Santos" <[email-masked]>
To: "Kartik Gopalan" <[email-masked]>, "Tony Finch" <[email-masked]>
Cc: <[email-masked]>, "Zhenhai Duan" <[email-masked]>, "Yingfei Dong" <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Date: Tue, 10 May 2005 10:43:20 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Hello,

The problem I have with DMTP is that its more than just SMTP. It requires
changes across a few boundaries and quite frankly, I am not too sure there
is not much added value here.

Like any other challenge system,  what you will have to deal with is:

1) Backward compliance
2) Non-Compliance

The two is different.   The first deals with legacy systems, the second
deals with systems that do not wish to implement it including malicious
systems that find it best to ignore any "schema" that will prohibit their
transaction.

You are in effect "greylisting" the client.  The concept of push or pull is
inconsequence since the overall effect is to stop the reception (pushed or
pulled) of so called "bad" mail.   You are issuing a challenge to the
"unclassified" client.

Based on experience, I can't see DMTP having any more added value just
greylisting.  Sure, I'm sure it works great with a compliant system.

But what about the non-compliant client?

What makes Greylisting attractive is that it based on the theory that
spammers will not comply with standard "SMTP flow control" concepts (retry
response codes).  Only good systems comply.  Bad systems do not.

So what other added value can a DMTP offer when considering all the pretty
extensive redesigned logic required to make it work?    What is gained?

I can see maybe two things:

1) Changing the mind set of the industry.
2) Stronger Message ID tracking and Recording.

As with most proposed SMTP extended/email protocols,  all suffered from how
to deal with non-compliance.  There is no incentive for spammers to comply.
As you suggest, unless it effects their bottom line,  they have no reason to
adapt.   The industry does not help the adaptation simply because there is
no enforcement behind it as of yet.    We still need to deal with legacy
systems.

The tracking of message is would be useful for many obvious reasons.

Finally, question about security:

Off hand, I think I see a potential of DMTP becoming a source of phishing.
Once the user authorizes the intent,  how to you control that a different
final body of message with different intent is not delivered?   The RMTP
only has the message id and subject to 'hash." and a return path and subject
is all the user has to go by to make a decision.

PS: I have a daughter at the FSU College of Music.  Nice school. :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Kartik Gopalan" <[email-masked]>
To: "Tony Finch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; "Zhenhai
Duan" <[email-masked]>; "Yingfei Dong" <[email-masked]>
Sent: Tuesday, May 10, 2005 12:52 AM
Subject: Re: draft-duan-smtp-receiver-driven-00.txt

>
> Before replying to your comments specifically, we'd like to stress
> again that, unlike  IM2000, DMTP classifies sender MTAs into three
> categories: allowed, denied, and unclassified. The receiver pull model
> is only used for messages from the unclassified category. Just as
> usual, whitelisted senders can send mail using normal SMTP and
> blacklisted ones are summarily declined, with no additional overhead.
>
> > The fundamental idea that it shares with IM2000 is based on a
mis-targeted
> > optimisation. The main cost of spam is the human time it wastes, whereas
> > disk space on the recipient servers is very cheap.
>
> DMTP holds the unclassified senders responsible for *managing* their
> own outgoing messages. Storage  is just one component of this
> management. DMTP strongly discourages the current
> "fire-forget-and-disappear" behaviour of  spammers who now need to
> wait (potentially indefinitely) for receivers to retrieve their
> messages. This goal can hardly be called a mis-targeted optimization.
> Now spammers would face the dilemma: They should online longer if they
> want more people to read, on the other hand, the longer they stay
> online, the more likely that they will be black listed.
>
> > In fact DMTP makes
> > dealing with poorly-classified email MORE time-consuming than it is
> > already, because a recipient must deal with a content-free notification
> > (containing only a forged sender address and a message ID) as well as
the
> > actual message.
>
> DMTP gives solution to the scenario that none of the currently  used
> anti-spam technologies can satisfactorily handle without receiving the
> entire message. DMTP intent messages are used ONLY for unclassified
> senders that are neither in receivers MTA's whitelists nor blacklists.
>  It is only unclassified senders who are treated using the
> receiver-pull model. And even to this category you can apply the same
> sender-discouragement schemes that are currently being applied -- such
> as greylisting, any other challenge-response schemes, etc.
>
> > If you enhance notification messages so that they are sufficiently
> > informative for a recipient to be able to decide whether to retrieve the
> > bulk message, then spammers will just put the entirety of their payload
in
> > the notification message. This has already occurred with certain kinds
of
> > mobile phone spam.
>
> First, this is inevitable in *ANY* form of communication where you
> wish to allow untrusted parties to communicate with you (or to express
> their intent to communicate). It is just like when your phone rings
> and you can't recognize the caller ID, you either ignore it or pick it
> up anyway. If its a wrong number, prank call, or a telemarketer, you
> simply hang up. So the problem is not specific to DMTP.
>
> Secondly, DMTP requires a configurable upper limit on the notification
> size. It is effective to the extent that it limits the content of SPAM
> delivered (just as phone caller ID helps in making an initial
> decision). If one wishes, one could place additional restrictions like
> not permitting HTML tags in the notification to make spammer's life
> more difficult.
>
> > When in doubt about the spamminess of a message it is better to receive
> > the whole thing. This allows the full gamut of classification technology
> > can be applied to it, so that there is a greater chance of it being
> > classified before it wastes the time of a person.
>
> One can still apply the whole gamut of classification technologies on
> any complete emails in DMTP. Handling intent messages for a small
> unclassified category of senders will not be too much of trouble. This
> can even be implemented as transparently as retrieving the complete
> message when *and only when* the receiver issues the open command on
> the intent message at his/her MUA (again simply like deciding whether
> to press talk/ignore upon receiving a caller-ID on the phone).
>
> > IM2000 and DMTP are also based on an incorrect assumption, that spam
> > messages actually cost space on the senders disks. Most spam software is
> > stateless, and it can continue to be in IM2000 or DMTP: the spammer just
> > encodes enough information in the message ID in order to be able to
> > reconstruct the message when it is requested.
>
> As mentioned earlier, the primary goal is to discourage the
> "fire-forget-and-disappear" behaviour that the current sender-push
> model of SMTP encourages. Storage overhead is only one small part of
> the picture. The bigger advantage is that spammer MTA needs to be up
> and running for potentially indefinite duration if it wants the
> receiver to read the entire message. In any event, storage becomes one
> less problem for the receiver to deal with even if the spammer does
> the kind of encoding you mention above.
>
> > It fails to use the SMTP extension model correctly. A client indicates
> > that it wishes to use an extension by using a command from the
extenstion
> > or a MAIL or RCPT parameter, NOT by appending a keyword to its EHLO
> > command. It shows a misunderstanding of the difference between the SMTP
> > envelope and the message header. It has inexplicable colons in its
command
> > names, in contradiction to SMTP's requirement that commands are
> > alphabetic.
>
> The above is more a issue of syntax than of content and can be easily
> addressed. We have noticed this issue already and are fixing it in our
> next draft. As mentioned in the initial post,  being new to IETF
> process we appreciate such feedback.
>
> > It makes assumptions about IP routeing which compromise the usability of
> > DMTP with highly scaled MTA clusters, which often involve NAT and/or
> > multi-homed servers.
>
> There is no assumption about IP routing anywhere in the draft. It is
> true if you mean making MTA clusters DMTP-compliant would require
> changes depending on nature of the cluster. However these are fairly
> simple and straightforward changes. Also note that DMTP-compliant MTAs
> can interoperate with non-DMTP-compliant legacy MTAs, whether latter
> is a scalable cluster or standalone MTA. If the latter is whitelisted
> with the former, the transaction is same as regular SMTP. If the
> latter is unclassified, it is subject to sender-discouragement
> mechanisms at the same cost as today.
>
> > The attempt at cryptography in section 3.4 is laughable.
>
> There is no attempt at PKI whatsoever, if that is what you mean. The
> terminology may be similar and can be easily clarified. If you read
> that section carefully, the sole purpose of the related paragraph is
> to make the mapping between a message id and a message itself less
> guessable, and to speedup the lookup of the message when the message
> id is presented. Moreover, as stated in the section, this is just one
> of possible design choices. Different schemes can be deployed by
> different MTAs, as long as it achieves the above purpose, given that
> this is really a local matter at the sending MTAs.
>
> - Kartik
>
>

Date: Tue, 10 May 2005 08:06:29 -0400
From: John C Klensin <[email-masked]>
To: Kartik Gopalan <[email-masked]>, Tony Finch <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Zhenhai Duan <[email-masked]>, Yingfei Dong <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

--On Tuesday, 10 May, 2005 00:52 -0400 Kartik Gopalan
<[email-masked]> wrote:

>...
> DMTP gives solution to the scenario that none of the currently
> used anti-spam technologies can satisfactorily handle without
> receiving the entire message. DMTP intent messages are used
> ONLY for unclassified senders that are neither in receivers
> MTA's whitelists nor blacklists.  It is only unclassified
> senders who are treated using the receiver-pull model. And
> even to this category you can apply the same
> sender-discouragement schemes that are currently being applied
> -- such as greylisting, any other challenge-response schemes,
> etc.
>...

Kartik,

I want to reinforce, from a different perspective, one of Tony's
points.

Ultimately, to let a message through, you are depending on a
whitelist that is, in turn, based on sender addresses.  Your
greylist technique, effective or not, is ultimately just a
technique for determining which addresses get onto the
whitelist. That causes you to inherit all of the issues with
whitelists based on sender addresses, especially the fact that,
in the absence of strong authentication, sender addresses are
easily faked.  If, as a receiver, I've got sufficient
infrastructure --probably, but perhaps not necessarily, PKI
machinery-- in place to authenticate sender addresses, then I
probably don't need your technique.  If I don't, then all the
spammer needs to do is to send messages to me that are "from"
people whom I know and with whom I have corresponded in the
past.    

Not only is that not hard, but they are doing it today.

That brings me to the serious downside of this, and many other,
"maybe it would help at least a little bit" ideas.    Assume,
for purposes of argument, that the details of your proposal,
such as not understanding how to use the SMTP extension model,
can be sorted out.   Assume you can get it widely enough
deployed in sending and receiving SMTP servers to make it useful
without putting huge burdens on legitimate, known, users trying
to exchange mail with each other (for better or worse, this is a
very high barrier).     Now, what we end up with is:

(1) Another list of really-good addresses that can presumably be
easily harvested by an address-harvesting virus.   Note that
your technique is of almost zero use against a spam generator
who relies on compromising a machine and using the sender name
to spam the people in the and address books or using the names
in the address book to spam the machine's owner from other
machines at a later date.  In either case, names intentionally
put in the address book or whitelist are presumably already
whitelisted.

(2) Another cycle in which: (i) A technique reduces the amount
of spam that is received slightly. (ii) The spammers respond by
increasing the amount of spam sent by, say, twice that amount,
resulting in a slight increase in the amount of spam received.
(iii) The spammers then devise a countermeasure.  In this case,
the countermeasure is quite easy: address-pair lists are
apparently already in heavy use by some spammer-enabling tools.
Net result is an increase in the total amount of spam being
delivered by around twice the amount that your method presumably
stopped.  

Those "arms race" cycles are not good for anyone concerned.

     john

Date: Tue, 10 May 2005 11:07:17 +0100
From: Tony Finch <[email-masked]>
To: Kartik Gopalan <[email-masked]>
cc: Tony Finch <[email-masked]>, [email-masked], [email-masked], [email-masked], Zhenhai Duan <[email-masked]>, Yingfei Dong <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

On Tue, 10 May 2005, Kartik Gopalan wrote:
>
> DMTP classifies sender MTAs into three categories: allowed, denied, and
> unclassified.

So do SMTP servers.

> The receiver pull model is only used for messages from the unclassified
> category.

And this is the category of messages where it is least useful. You are
forcing people to guess whether they want to receive a message before you
have expended any automated effort to classify it.

> > When in doubt about the spamminess of a message it is better to receive
> > the whole thing. This allows the full gamut of classification technology
> > can be applied to it, so that there is a greater chance of it being
> > classified before it wastes the time of a person.
>
> One can still apply the whole gamut of classification technologies on
> any complete emails in DMTP.

But only after you have wasted someone's time.

You have not addressed the user interface issues of DMTP. How is a user
supposed to decide whether to receive a message given only the sender
address and message ID? You suggest that message IDs should be
cryptographically generated, and therefore meaningless to people, and you
do not address the problem of forged sender addresses. Therefore DMTP's
notification messages are useless to the recipient.

> > It makes assumptions about IP routeing which compromise the usability of
> > DMTP with highly scaled MTA clusters, which often involve NAT and/or
> > multi-homed servers.
>
> There is no assumption about IP routing anywhere in the draft.

You are assuming that each server's idea of its own IP address is the same
as the other TCP endpoint's idea of it. You are assuming that incoming and
outgoing connections to an MTA are symmetrical.

> > The attempt at cryptography in section 3.4 is laughable.
>
> There is no attempt at PKI whatsoever, if that is what you mean.

No, I mean that you are using a cryptographic hash incompetently.

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: Tue, 10 May 2005 00:52:24 -0400
From: Kartik Gopalan <[email-masked]>
Reply-To: Kartik Gopalan <[email-masked]>
To: Tony Finch <[email-masked]>
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Cc: [email-masked], [email-masked], [email-masked], Zhenhai Duan <[email-masked]>, Yingfei Dong <[email-masked]>
Sender: [email-masked]

Before replying to your comments specifically, we'd like to stress
again that, unlike  IM2000, DMTP classifies sender MTAs into three
categories: allowed, denied, and unclassified. The receiver pull model
is only used for messages from the unclassified category. Just as
usual, whitelisted senders can send mail using normal SMTP and
blacklisted ones are summarily declined, with no additional overhead.

> The fundamental idea that it shares with IM2000 is based on a mis-targeted
> optimisation. The main cost of spam is the human time it wastes, whereas
> disk space on the recipient servers is very cheap.

DMTP holds the unclassified senders responsible for *managing* their
own outgoing messages. Storage  is just one component of this
management. DMTP strongly discourages the current
"fire-forget-and-disappear" behaviour of  spammers who now need to
wait (potentially indefinitely) for receivers to retrieve their
messages. This goal can hardly be called a mis-targeted optimization.
Now spammers would face the dilemma: They should online longer if they
want more people to read, on the other hand, the longer they stay
online, the more likely that they will be black listed.

> In fact DMTP makes
> dealing with poorly-classified email MORE time-consuming than it is
> already, because a recipient must deal with a content-free notification
> (containing only a forged sender address and a message ID) as well as the
> actual message.

DMTP gives solution to the scenario that none of the currently  used
anti-spam technologies can satisfactorily handle without receiving the
entire message. DMTP intent messages are used ONLY for unclassified
senders that are neither in receivers MTA's whitelists nor blacklists.
 It is only unclassified senders who are treated using the
receiver-pull model. And even to this category you can apply the same
sender-discouragement schemes that are currently being applied -- such
as greylisting, any other challenge-response schemes, etc.

> If you enhance notification messages so that they are sufficiently
> informative for a recipient to be able to decide whether to retrieve the
> bulk message, then spammers will just put the entirety of their payload in
> the notification message. This has already occurred with certain kinds of
> mobile phone spam.

First, this is inevitable in *ANY* form of communication where you
wish to allow untrusted parties to communicate with you (or to express
their intent to communicate). It is just like when your phone rings
and you can't recognize the caller ID, you either ignore it or pick it
up anyway. If its a wrong number, prank call, or a telemarketer, you
simply hang up. So the problem is not specific to DMTP.

Secondly, DMTP requires a configurable upper limit on the notification
size. It is effective to the extent that it limits the content of SPAM
delivered (just as phone caller ID helps in making an initial
decision). If one wishes, one could place additional restrictions like
not permitting HTML tags in the notification to make spammer's life
more difficult.

> When in doubt about the spamminess of a message it is better to receive
> the whole thing. This allows the full gamut of classification technology
> can be applied to it, so that there is a greater chance of it being
> classified before it wastes the time of a person.

One can still apply the whole gamut of classification technologies on
any complete emails in DMTP. Handling intent messages for a small
unclassified category of senders will not be too much of trouble. This
can even be implemented as transparently as retrieving the complete
message when *and only when* the receiver issues the open command on
the intent message at his/her MUA (again simply like deciding whether
to press talk/ignore upon receiving a caller-ID on the phone).
 
> IM2000 and DMTP are also based on an incorrect assumption, that spam
> messages actually cost space on the senders disks. Most spam software is
> stateless, and it can continue to be in IM2000 or DMTP: the spammer just
> encodes enough information in the message ID in order to be able to
> reconstruct the message when it is requested.

As mentioned earlier, the primary goal is to discourage the
"fire-forget-and-disappear" behaviour that the current sender-push
model of SMTP encourages. Storage overhead is only one small part of
the picture. The bigger advantage is that spammer MTA needs to be up
and running for potentially indefinite duration if it wants the
receiver to read the entire message. In any event, storage becomes one
less problem for the receiver to deal with even if the spammer does
the kind of encoding you mention above.

> It fails to use the SMTP extension model correctly. A client indicates
> that it wishes to use an extension by using a command from the extenstion
> or a MAIL or RCPT parameter, NOT by appending a keyword to its EHLO
> command. It shows a misunderstanding of the difference between the SMTP
> envelope and the message header. It has inexplicable colons in its command
> names, in contradiction to SMTP's requirement that commands are
> alphabetic.

The above is more a issue of syntax than of content and can be easily
addressed. We have noticed this issue already and are fixing it in our
next draft. As mentioned in the initial post,  being new to IETF
process we appreciate such feedback.
 
> It makes assumptions about IP routeing which compromise the usability of
> DMTP with highly scaled MTA clusters, which often involve NAT and/or
> multi-homed servers.

There is no assumption about IP routing anywhere in the draft. It is
true if you mean making MTA clusters DMTP-compliant would require
changes depending on nature of the cluster. However these are fairly
simple and straightforward changes. Also note that DMTP-compliant MTAs
can interoperate with non-DMTP-compliant legacy MTAs, whether latter
is a scalable cluster or standalone MTA. If the latter is whitelisted
with the former, the transaction is same as regular SMTP. If the
latter is unclassified, it is subject to sender-discouragement
mechanisms at the same cost as today.

> The attempt at cryptography in section 3.4 is laughable.

There is no attempt at PKI whatsoever, if that is what you mean. The
terminology may be similar and can be easily clarified. If you read
that section carefully, the sole purpose of the related paragraph is
to make the mapping between a message id and a message itself less
guessable, and to speedup the lookup of the message when the message
id is presented. Moreover, as stated in the section, this is just one
of possible design choices. Different schemes can be deployed by
different MTAs, as long as it achieves the above purpose, given that
this is really a local matter at the sending MTAs.

- Kartik

Date: Mon, 9 May 2005 22:19:09 +0100
From: Tony Finch <[email-masked]>
To: Kartik Gopalan <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], Zhenhai Duan <[email-masked]>, Yingfei Dong <[email-masked]>, [email-masked]
Subject: Re: draft-duan-smtp-receiver-driven-00.txt
Sender: [email-masked]

This draft is worthless.

The fundamental idea that it shares with IM2000 is based on a mis-targeted
optimisation. The main cost of spam is the human time it wastes, whereas
disk space on the recipient servers is very cheap. In fact DMTP makes
dealing with poorly-classified email MORE time-consuming than it is
already, because a recipient must deal with a content-free notification
(containing only a forged sender address and a message ID) as well as the
actual message.

If you enhance notification messages so that they are sufficiently
informative for a recipient to be able to decide whether to retrieve the
bulk message, then spammers will just put the entirety of their payload in
the notification message. This has already occurred with certain kinds of
mobile phone spam.

When in doubt about the spamminess of a message it is better to receive
the whole thing. This allows the full gamut of classification technology
can be applied to it, so that there is a greater chance of it being
classified before it wastes the time of a person.

IM2000 and DMTP are also based on an incorrect assumption, that spam
messages actually cost space on the senders disks. Most spam software is
stateless, and it can continue to be in IM2000 or DMTP: the spammer just
encodes enough information in the message ID in order to be able to
reconstruct the message when it is requested.

As well as being based on a fundamentally useless idea, the details of the
specification are incompetent.

It fails to use the SMTP extension model correctly. A client indicates
that it wishes to use an extension by using a command from the extenstion
or a MAIL or RCPT parameter, NOT by appending a keyword to its EHLO
command. It shows a misunderstanding of the difference between the SMTP
envelope and the message header. It has inexplicable colons in its command
names, in contradiction to SMTP's requirement that commands are
alphabetic.

It makes assumptions about IP routeing which compromise the usability of
DMTP with highly scaled MTA clusters, which often involve NAT and/or
multi-homed servers.

The attempt at cryptography in section 3.4 is laughable.

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: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Date: Mon, 9 May 2005 16:11:59 -0400
Cc: [email-masked], "Vaudreuil, Greg M (Greg)" <[email-masked]>
Sender: [email-masked]

On Mon May 9 2005 14:27, [email-masked] wrote:

> The point was that 4.7.1 does a much better job

It can't because (as you noted) it doesn't exist [*].

> of explaining what's 
> going on - so it isn't a case where "the problem cannot be well expressed".

..."with any of the other provided detail codes".  There is no 4.7.1.

> In fact, 4.7.1 expresses perfectly the situation,

In the scenario posited (initial attempt, previous "greylisting" attempt
history not available), 4.7.5 is valid and seems appropriate:
      X.7.5   Cryptographic failure

         A transport system otherwise authorized to validate or decrypt
         a message in transport was unable to do so because necessary
         information such as key was not available or such information
         was invalid.
Validation is denied on the first attempt because a record of a previous
attempt is not available, or the timestamp on such an available record
is invalid (insufficient interval since first attempt).  x.7.1:
      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.  This is useful only as a
         permanent error.
addresses sender/destination combinations based on per-host or per-
recipient filtering.  Not wall clock issues.

> except that 3463 didn't 
> seem to foresee that 4.7.X would be useful for many things....

No:
o there is no 4.7.1, only a 5.7.1.
o x.7.0 is unrestricted; 2.7.0, 4.7.0 and 5.7.0 are valid.  However, x.7.0
  refers to a message being returned, so it's unclear how that would apply
  for 2.7.0 ("success" class).  Moreover, the subject sub-code 7 is defined
  to "report failures involving policies such as per-recipient or per-host
  filtering and cryptographic operations", and "success" and "failures"
  are incompatible.  However, as we're discussing 4 (persistent transient
  failure) and 5 (permanent failure) class sub-codes, that problem doesn't
  enter into our discussion [Greg, please note, though].  One could argue
  that 3464 is too generous in allowing combinations of sub-codes.
o x.7.2, x.7.3, x.7.4 are in the same boat as x.7.1; x = 5 (only).
o x.7.5 and x.7.6 are unrestricted, like x.7.0.  However, they're defined
  as failure indications, so 2.7.[56] makes no sense, as with x.7.0.
o x.7.7 explicitly allows any use, including success, though it's unclear
  how "success" can apply to "Message integrity failure". Same as x.7.[056].

So in "4.7.x", you can choose an appropriate x from 0, 5, 6, 7; those are
the valid choices, and they are in fact "useful for many things".  In your
specific case either 5 or 0 seem suitable.

* One of the problems with un-extended status codes is that some
implementations used undefined codes.  Please don't encourage the same
for extended codes; that will require extended-extended codes to escape
from that interoperability problem.  Note that there is already at least
one case of an incompatibility in the use of extended status codes (
http://www1.ietf.org/mail-archive/web/ietf/current/msg34254.html
) (to be fixed, I believe).

To: SM <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes. 
From: [email-masked]
Date: Mon, 09 May 2005 15:56:12 -0400
Sender: [email-masked]

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

On Mon, 09 May 2005 11:11:35 PDT, SM said:

> Greylisting is a short term fix.  The better question is what to do on a 
> 4.7.1 extended code.  MX hosts may have different filtering 
> policies.  Should the SMTP client use the same MX host on a 4.7.1 to avoid 
> getting around filtering policies and to play nice with greylisting?

If a site sets up multiple MX's with different policies, they're painting the
target on their own foreheads. Sticking to "the same MX host" to play nice
won't work - if you're already talking to a secondary MX, there's 2
possibilities:

1) They are in the same administrative domain and implement the same policy.
It doesn't matter if you try another MX next time, as results are consistent.

2) The backup MX doesn't implement the same policy.  In this case, you *should*
implement a flip-flop to another MX, as that increases the chances you'll hit
a machine implementing the desired policy from zero to something non-zero.

In either case, flipping to a different MX results in at least as good results.

It however *is* true that if the *primary* gives you a 4.7.X, it's probably a
good idea to not retry on a secondary, on the assumption that the secondary never
has more clue about the security stance of the primary than the primary itself
does.  If the *primary* is saying "temp security fail", then any attempt by a
secondary to give a more definitive permanent answer (in *either* the 2.x.y or
5.x.y series) is spurious at best.

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

--==_Exmh_1115668572_6742P--

To: [email-masked]
Cc: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes. 
From: [email-masked]
Date: Mon, 09 May 2005 14:27:31 -0400
Sender: [email-masked]

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

On Mon, 09 May 2005 13:16:22 EDT, Bruce Lilly said:

> IMO, 3463 is fine as it stands.  Temporary failures of the sort
> discussed could be indicated via 4.7.0, which is specifically
> provided for cases where "the problem cannot be well expressed
> with any of the other provided detail codes".

The point was that 4.7.1 does a much better job of explaining what's
going on - so it isn't a case where "the problem cannot be well expressed".
In fact, 4.7.1 expresses perfectly the situation, except that 3463 didn't
seem to foresee that 4.7.X would be useful for many things....

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

--==_Exmh_1115663251_6742P--

Date: Mon, 09 May 2005 11:11:35 -0700
To: [email-masked]
From: SM <[email-masked]>
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Sender: [email-masked]

At 07:58 09-05-2005, John Leslie wrote:
>    What is the _benefit_ of telling a spammer you're greylisting him?

Greylisting does not affect spammers only.  You are also telling your 
correspondent why the email delivery temporarily failed.

>    My thoughts run along the line of keeping a database by IP address
>of sending SMTP client with times of attempts, to check that we're
>delaying long enough for IP addresses to get blacklisted. But it's not
>clear how long that is; nor is it clear how we decide this _particular_
>email has been delayed long enough. I find myself thinking of hashing
>MAIL-FROM and RCPT-TO; and this starts looking _very_ unattractive.

That's how greylisting is generally implemented.  It can however cause 
issues if the subsequent delivery attempts are made from different IP 
addresses.  Greylisting works well with the same client/server pair.

My greylististing implementation targets Windows hosts only and uses IP 
address and helo pairs.  The problem is how to handle connections from 
server farms as they do not always originate from the same /24 for example.

Greylisting is a short term fix.  The better question is what to do on a 
4.7.1 extended code.  MX hosts may have different filtering 
policies.  Should the SMTP client use the same MX host on a 4.7.1 to avoid 
getting around filtering policies and to play nice with greylisting?

Regards,
-sm 

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: RE: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Date: Mon, 9 May 2005 13:16:22 -0400
Cc: "Vaudreuil, Greg M (Greg)" <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon May 9 2005 11:15, Vaudreuil, Greg M (Greg) wrote:
> 
> The author never anticipated a situation where a sender may be not authorized at one time but could be authorized at another.  At the most basic level, that seems like the definition of an unreliable system. 
> 
> Fortunately, imagination does not limit reality.  And UBE certianly challenges the reality of the email architecture.  I have no problem supporting an RFC errata note indicating that this seamingly incorrect prognistication be eliminated.   
> 
> In more broad terms, I like opinions as to whether these predictions of utility have any value, or whether they should be deleted from a future revision.
> 
> Greg V.

IMO, 3463 is fine as it stands.  Temporary failures of the sort
discussed could be indicated via 4.7.0, which is specifically
provided for cases where "the problem cannot be well expressed
with any of the other provided detail codes".

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Date: Mon, 9 May 2005 12:18:36 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

Claus,

A few points:

First, I think a key point about what makes greylisting or any other c/r
(challenge/response) retry logic currently attractive is the current
operational behavior with spammers (professional typically bulk sending
systems)  who do not currently respect or honor the "retry logic."    Only
good legitimate systems follows the rules which is why it does work in this
regard.  The good system will retry. "Bad" systems do not.  That's the
theory behind greylisting.

Second, extended response status codes are optional.  You can't base any
client retry logic on it. It has to remain based on the required response
codes (4xx, 5xx) for backward compatibility.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Claus Assmann" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 09, 2005 11:20 AM
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.

On Mon, May 09, 2005, John Leslie wrote:

>    What is the _benefit_ of telling a spammer you're greylisting him?

How do you know it's a spammer that is subject to greylisting?

As more and more systems deploy greylisting the effect on legitimate
mail clients is getting significant. Especially bad are those domain
which have multiple MX servers. Here's what happened (and which
originally triggered this question that I asked on a different list):

My system sends out mail to a small mailing list. As this happen
infrequently the IP address/sender is usually already "expired"
from the "white lists" of systems that deploy "greylisting".  Hence
almost every time the mail is subject to being delayed by several
servers. At least one of them has 4 MX servers which means that my
MTA tries all of them just to receive:

451 4.7.1 Greylisting in action, please come back in 01:00:00
451 4.7.1 Greylisting in action, please come back in 00:59:56
451 4.7.1 Greylisting in action, please come back in 00:59:53
451 4.7.1 Greylisting in action, please come back in 00:59:51

(or some similar text) in reply. Now the question is: how can I
tell my MTA not to try another MX server[1]? One idea is to have a
specific enhanced status code to do that: that might be either an
existing code (4.7.1 has been suggested) or a new one.

I would prefer a new one because such a code could be used for
different cases (e.g., if the recipient address can currently not
be identified because some name service is down). So if we use
4.10.x for "temporary error: do NOT try another MX" then we don't
have to overload exactly one code to have this effect.

[1] I know that some MTAs do not try another MX server after having
successfully established a connection with one. However, most MTAs
nowadays try another MX server on pretty much any temporary error
during a session/transaction.

From: "Hector Santos" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Date: Mon, 9 May 2005 11:08:59 -0400
Organization: Santronics Software, Inc.
Sender: [email-masked]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 09, 2005 9:57 AM
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 09, 2005 9:57 AM
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.

>  Unfortunately, there's one final line to that description:

>          This is useful only as a  permanent error.

> What's the general consensus here?  Is 4.7.1 in fact useful as a
> temporary error in this case, or do we risk the wrath of the RFC
> wonks if stuff deploys that uses that?

In my view, that should say:

      This type of extended code only make senses for
      permanent errors (i.e., when X is 5).

Why?

Well, first, extended and more importantly "optional" extended response
codes are design to provide a computer coded extended "description" for the
required response code.  If supported, the X must match the x in the
required x5y code.  What will ultimately be used for controlling the client
is the require 4xx or 5xx codes.

In other words,  if you issue

        450 4.7.1  You've been greylisted, try again later
        550 5.7.1 You've been blackkisted, don't bother to try again

You need to be backward compatible and so that client will base the retry
logic on 450/550. Not 4.7.1/5.7.1.  It may not even recognize it.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

Date: Mon, 9 May 2005 08:20:31 -0700
From: Claus Assmann <[email-masked]>
To: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Mail-Followup-To: Claus Assmann <[email-masked]>, [email-masked]
Sender: [email-masked]

On Mon, May 09, 2005, John Leslie wrote:

>    What is the _benefit_ of telling a spammer you're greylisting him?

How do you know it's a spammer that is subject to greylisting?

As more and more systems deploy greylisting the effect on legitimate
mail clients is getting significant. Especially bad are those domain
which have multiple MX servers. Here's what happened (and which
originally triggered this question that I asked on a different list):

My system sends out mail to a small mailing list. As this happen
infrequently the IP address/sender is usually already "expired"
from the "white lists" of systems that deploy "greylisting".  Hence
almost every time the mail is subject to being delayed by several
servers. At least one of them has 4 MX servers which means that my
MTA tries all of them just to receive:

451 4.7.1 Greylisting in action, please come back in 01:00:00
451 4.7.1 Greylisting in action, please come back in 00:59:56
451 4.7.1 Greylisting in action, please come back in 00:59:53
451 4.7.1 Greylisting in action, please come back in 00:59:51

(or some similar text) in reply. Now the question is: how can I
tell my MTA not to try another MX server[1]? One idea is to have a
specific enhanced status code to do that: that might be either an
existing code (4.7.1 has been suggested) or a new one.

I would prefer a new one because such a code could be used for
different cases (e.g., if the recipient address can currently not
be identified because some name service is down). So if we use
4.10.x for "temporary error: do NOT try another MX" then we don't
have to overload exactly one code to have this effect.

[1] I know that some MTAs do not try another MX server after having
successfully established a connection with one. However, most MTAs
nowadays try another MX server on pretty much any temporary error
during a session/transaction.

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Date: Mon, 9 May 2005 10:15:27 -0500 
Sender: [email-masked]

The author never anticipated a situation where a sender may be not authorized at one time but could be authorized at another.  At the most basic level, that seems like the definition of an unreliable system. 

Fortunately, imagination does not limit reality.  And UBE certianly challenges the reality of the email architecture.  I have no problem supporting an RFC errata note indicating that this seamingly incorrect prognistication be eliminated.   

In more broad terms, I like opinions as to whether these predictions of utility have any value, or whether they should be deleted from a future revision.

Greg V.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 09, 2005 9:58 AM
To: [email-masked]
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.

It was suggested to me that an SMTP server implementing greylisting
needs to return a descriptive code, and some variant on

450 4.7.1 You've been greylisted, try again later

is the "best fit" from RFC3463, which says:

      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.

Yep.  Stick a 4 on it to tell the other end that it's not authorized *now*,
but might be later, and we're ready to rock.  Unfortunately, there's one
final line to that description:

                                               This is useful only as a
         permanent error.

What's the general consensus here?  Is 4.7.1 in fact useful as a temporary
error in this case, or do we risk the wrath of the RFC wonks if stuff deploys
that uses that?

To: John Leslie <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes. 
From: [email-masked]
Date: Mon, 09 May 2005 11:10:27 -0400
Sender: [email-masked]

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

On Mon, 09 May 2005 10:58:25 EDT, John Leslie said:

>    It's pretty clear that the final line is merely an opinion: thus nobody
> _should_ get uptight about you using it.
> 
>    Alas, I suspect the opinion may still be correct...
> 
>    What is the _benefit_ of telling a spammer you're greylisting him?

The general opinion is that most spamware is "fire and forget"(*), and that
handing them *any* 4XX is sufficient because they won't retry.  The 4.7.1
is there for the *non-spammer*s benefit, so that they understand that
they've been greylisted.

Of course, one of these days (probably right around the time everybody
starts greylisting), the spamware will actually start listening to the
reply codes....

(*) Most egregious fire-and-forget I've seen stuck all the data onto the
initial SYN (HELO/MAIL FROM/RCPT TO/DATA/./QUIT) and was obviously planning
to take advantage of a MTA that would be helpful when scanning the input
buffer and automagically undo the overambitious pipelining.  The second
packet it sent (in response to the SYN+ACK) was an ACK+FIN.  Gaak. ;)

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

--==_Exmh_1115651426_6742P--

Date: Mon, 9 May 2005 10:58:25 -0400
From: John Leslie <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Sender: [email-masked]

[email-masked] <[email-masked]> wrote:
> 
> It was suggested to me that an SMTP server implementing greylisting
> needs to return a descriptive code, and some variant on
> 
> 450 4.7.1 You've been greylisted, try again later
> 
> is the "best fit" from RFC3463, which says:
> 
>       X.7.1   Delivery not authorized, message refused
> 
>          The sender is not authorized to send to the destination.  This
>          can be the result of per-host or per-recipient filtering.  This
>          memo does not discuss the merits of any such filtering, but
>          provides a mechanism to report such.
> 
> Yep.  Stick a 4 on it to tell the other end that it's not authorized *now*,
> but might be later, and we're ready to rock.  Unfortunately, there's one
> final line to that description:
> 
>          This is useful only as a permanent error.
> 
> What's the general consensus here?  Is 4.7.1 in fact useful as a temporary
> error in this case, or do we risk the wrath of the RFC wonks if stuff
> deploys that uses that?

   It's pretty clear that the final line is merely an opinion: thus nobody
_should_ get uptight about you using it.

   Alas, I suspect the opinion may still be correct...

   What is the _benefit_ of telling a spammer you're greylisting him?

====

   Which brings to mind a related question: has anyone thought through
how to improve greylisting from a simple probability-of-temp-error?

   It's clear to me that simple probability encourages escalation; and
I very much dislike "solutions" which encourage escalation.

   My thoughts run along the line of keeping a database by IP address
of sending SMTP client with times of attempts, to check that we're
delaying long enough for IP addresses to get blacklisted. But it's not
clear how long that is; nor is it clear how we decide this _particular_
email has been delayed long enough. I find myself thinking of hashing
MAIL-FROM and RCPT-TO; and this starts looking _very_ unattractive.

   Ideas?

--
John Leslie <[email-masked]>

Date: Mon, 9 May 2005 16:35:23 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.
Cc: Valdis =?utf-8?q?Kl=C4=93tnieks?= <[email-masked]>
Sender: [email-masked]

Valdis Klētnieks writes:
> Is 4.7.1 in fact useful as a temporary error in this case, or do we 
> risk the wrath of the RFC wonks if stuff deploys that uses that?

There is at least one other perfectly reasonable justification for 
sending 4.7.1:

     450 4.7.1 Authorisation server unreachable, please try again later

So the RFC is wrong - x.7.1 is useful as a temporary error too.

Arnt

Date: Mon, 9 May 2005 16:26:18 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: Arun Sankar <[email-masked]>, [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Organization: NIC France
Sender: [email-masked]

On Wed, May 04, 2005 at 09:45:08PM +0200,
 Markus Stumpf <[email-masked]> wrote 
 a message of 54 lines which said:

>    SMTP servers don't care about mail headers (**)
...
> ** There is one (valid?) exception I know of:
>    some MTAs looks at the number of Received: lines for the sake of loop
>    detection.

May be SMTP servers should not touch the headers. But they do (besides
the obvious of adding a Received header).

* Postfix checks the Delivered-To (loop detection).

* Most MTAs add Date, To and Message-Id if they are missing (may be
they should not, if only message submission and transfer were properly
separated...)

Unfortunately, the separation between 2821 and 2822 in the real world
is not as clear as we would like it to be.

To: [email-masked]
Subject: RFC3463, 450 reply codes, and 4.7.1 extended codes.
From: [email-masked]
Date: Mon, 09 May 2005 09:57:30 -0400
Sender: [email-masked]

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

It was suggested to me that an SMTP server implementing greylisting
needs to return a descriptive code, and some variant on

450 4.7.1 You've been greylisted, try again later

is the "best fit" from RFC3463, which says:

      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.

Yep.  Stick a 4 on it to tell the other end that it's not authorized *now*,
but might be later, and we're ready to rock.  Unfortunately, there's one
final line to that description:

                                               This is useful only as a
         permanent error.

What's the general consensus here?  Is 4.7.1 in fact useful as a temporary
error in this case, or do we risk the wrath of the RFC wonks if stuff deploys
that uses that?

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

--==_Exmh_1115647050_6742P--

Date: Sat, 7 May 2005 18:57:24 -0400 (EDT)
From: Zhenhai Duan <[email-masked]>
To: [email-masked]
Subject:  Re: [Asrg] draft-duan-smtp-receiver-driven-00.txt (DMTP/DiffMail) - 
Sender: [email-masked]

(Forwarded from the ASRG mailing list in case some folks are not on that 
mailing list.)

Matthew,

Your comments on greylisting are interesting.
Personally I think that greylisting is indeed a very clever idea.
At the same time, there is no denying that it does overload the
"TEMPFAIL" semantics of SMTP with a semantics that was probably not
originally intended for use in this manner in the first place. So in the
long term, we'd want to move towards a more systematic mechanism.
One other concern is that spammers will adapt to greylisting as well
sooner than later once it starts affecting their bottomline. Greylisting
is still a purely sender push-based model that leaves the receivers
in a reactive mode.

DMTP differs from greylisting in how receiving MTAs
(RMTAs) react to "unclassified" sending MTAs (SMTAs).
(unclassified = neither in whitelist or blacklist).
In greylisting, unclassified SMTAs are asked to push
the message again later. With DMTP, the RMTA pulls the
message from unclassified SMTA only if and when the receivers
are interested.

In addition to being (1) a systematic receiver-pull
mechanism, as you noted, (2) DMTP reduces the
delivery latency for legitimate senders (a small intent message
can be delivered immediately) and (3) provides a larger time
window for blacklists to be effective.

That said, we did carefully consider using greylisting itself as part of
the incremental deployment phase of DMTP. Specifically,
when a non-DMTP-compliant unclassified SMTA attempts
message delivery to a DMTP-compliant RMTA,  the SMTA can be
discouraged by use of greylisting-like mechanism. We still think
it is a highly feasible alternative to the challenge-response
based mechanism currently described in Section 3.6 of the draft.

- Kartik

On 5/6/05, Matthew Elvey <[email-masked]> wrote:
<snipped>

From: Dave Crocker <[email-masked]>
To: Richard Clayton <[email-masked]>
CC: ietf-smtp <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Sat, 7 May 2005 13:36:38 -0700
Subject: Re: [Asrg] I-D: Email Submission Between Independent Networks
Sender: [email-masked]

Richard,

Since the draft is requesting standardization as a BCP, it calls for public 
discussion to be on the [email-masked] 
<http://www.imc.org/ietf-smtp/mail-archive/> mailing list.

I am taking the liberty of forwarding your note to that list, in an attempt to 
move any discussion about the draft to that venue.

d/

>  In article <[email-masked]>, John R
>  Levine <[email-masked]> writes
>
> >  Here's the latest draft of the proposed BCP from Carl Hutzler et al
> >  about
> >  mail submission.  I think it's pretty good and barring a lot of hate
> >  mail
> >  I'd like to say that the ASRG likes it so I can nudge it down the path
> >  to
> >  BCP-hood.
> >
> >  [ A MIME TEXT / plain part was included here. ]
> >
>  it includes the text
>
>  Best practices are:
>
>  o  MSAs MUST support the SUBMISSION port, for MUAs accessing from
>  outside the MSA's local environment.
>
>  but probably means
>
>  o  MSAs MUST support the SUBMISSION port if MUAs are permitted
>  access from outside the MSA's local environment.
>
>  - --
>  richard                                              Richard Clayton
>
>  They that can give up essential liberty to obtain a little temporary
>  safety deserve neither liberty nor safety.         Benjamin Franklin

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: port 773 vs port 587
Date:  Sat, 07 May 2005 06:36:08 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 8
Sender: [email-masked]

Markus Stumpf wrote:

> what is 773 good for?

Nice puzzle, I couldn't solve it.  It's as old as RfC 1060,
and UDP 773 is "notify".  Adding "print" to the keywords
didn't help, and RfC 773 mentions only port 57.  Bye, Frank

Date: Fri, 06 May 2005 11:44:50 -0700
From: Matthew Elvey <[email-masked]>
To: Kartik Gopalan <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], Yingfei Dong <[email-masked]>
Subject: Re: [Asrg] draft-duan-smtp-receiver-driven-00.txt (DMTP/DiffMail)
Sender: [email-masked]

Given the initial crosspost, I'm doing the same (though they may be 
rejected) and suggesting all follow-up go to one list, only.  I suggest 
asrg.

FEEDBACK:
Yes, this is ~= IM2000, but with an improvement: it's potentially 
sometimes backward-compatible with SMTP.
Generally, this draft (which I'll refer to as DMTP or DiffMail) has 
features (the draft lists 3 advantages*) that, IMO, are better provided 
by other systems.
Addressing them in reverse order:
3)This is better provided by greylisting+.  That forces the sender to 
maintain something like a real mail queue.
2)Standard use of DNSRBLs (and sometimes RHSBLs with CSV or SPF) reduces 
bandwidth and storage costs more effectively and is compatible with all 
senders and most receivers today, with no code changes, and generally 
require just trivial configuration changes.
1)Again, greylisting allows a receiver a window of opportunity to allow 
the sender to get on a BL (or the message to enter a razor2 type DB) 
before receiving the message.  It is true, however, that DMTP does 
provide a potentially larger window, and does so without indroducing a 
significant delay.  The question is, is this worth the cost of requiring 
senders and receivers support new commands and a new reply code?

Confused by acronyms? See
<http://wiki.fastmail.fm/wiki/index.php/ClientSmtpValidation#.23Acronyms.2FGlossary>
for elucidation.

+See <http://greylisting.org>

*Purported Advantages:
   "1. By asking senders (non-regular contacts) to maintain messages on 
their mail servers, spammers are forced to keep their servers up. They 
cannot simply send a large number of spam messages, shut down their 
servers, and switch to another domain (and/or change IP addresses). In 
this way, DiffMail helps to improve the effectiveness of 
IP-address-based filtering schemes.
   2. Since a (complete) message is only retrieved by a receiver at his 
will, less bandwidth and storage resource will be consumed at the 
receiver side if the user does not retrieve the majority of messages 
from non-regular contacts.
   3. Spammers now have more responsibilities to maintain their outgoing 
messages[.]"

On 5/5/05 3:51 PM, Kartik Gopalan sent forth electrons to convey:
<snipped>

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Fri, 6 May 2005 20:15:58 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: port 773 vs port 587
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

I hope this isn't off topic here ...

Port 587 is "submission" (RFC 2476)
Port 773 is "submit"

I couldn't find real information to port 773 or "submit", but it seems to
be elder than submission, as I can find it already in RFC1700 (Assigned
Numbers).

I could also find
http://ftp.belnet.be/pub/mirror/ftp.ietf.org/ietf-mail-archive/ietf/2003-03.mail

   From: Dave Crocker <[email-masked]>
   Date: Fri, 28 Feb 2003 19:37:45 -0600
   Subject: Re: IAB policy on anti-spam mechanisms?

   [ ... ]
   Email standards provide for posting of email to the usual port 25 or to
   port 773 for the newer "submit" service. (Submit is a clone of SMTP that
   operates on a different port and is permitted to evolve independently of
   SMTP, in order to tailor posting by originators, differently from
   server-to-server email relaying.)
   [ ... ]

which sounds exactly like "Message Submission" to me.

As "Message Submission" is a RFC and 587 is referenced in the RFC what
is 773 good for? Is this simply outdated information? Should 773 be
"deallocated" to stop further confusion or is "submit" really existing
and different to submission?
   
	\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"

Date: Thu, 5 May 2005 18:51:50 -0400
From: Kartik Gopalan <[email-masked]>
Reply-To: Kartik Gopalan <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: draft-duan-smtp-receiver-driven-00.txt
Cc: Zhenhai Duan <[email-masked]>, Yingfei Dong <[email-masked]>
Sender: [email-masked]

------=_Part_25505_7975606.1115333510921
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

We'd like to solicit feedback from the SMTP community on=20
our recent IETF draft titled "Receiver-Driven Extensions to SMTP".

http://www.ietf.org/internet-drafts/draft-duan-smtp-receiver-driven-00.txt

The abstract of the draft is attached below.

As we are new to the IETF process, we welcome any suggestions=20
pointing out potential improvements as well as deficiencies in the draft.

The following DiffMail project website and our related paper in SRUTI'05=20
might also be of interest.

http://www.cs.fsu.edu/~duan/projects/diffmail/diffmail.htm

Thanks,
Zhenhai Duan, Kartik Gopalan, Yingfei Dong

Abstract:

The Differentiated Mail Transfer Protocol (DMTP) provides simple=20
extensions to the Simple Mail Transfer Protocol (SMTP) that=20
enable receivers to exercise greater control over the email delivery=20
process. The current SMTP-based email delivery architecture is=20
fundamentally sender-driven and distinctly lacks receiver control over
the message delivery mechanism. This document describes DMTP=20
that enables receivers to classify senders into three categories -- allowed=
,=20

denied, and unclassified -- and process the delivery of messages=20
from each category independently. As is the current practice, receivers=20
may directly accept messages from senders in the allowed
category and decline senders in the denied category. In addition,=20
DMTP receivers require senders in the unclassified category to=20
store messages on the senders' own mail servers. Such messages=20
are retrieved only if and when the end receivers wish to do so.=20
By granting greater control over message delivery to receivers and
imposing greater message storage and maintenance overhead on=20
senders, DMTP provides significant advantages in controlling spam.=20
DMTP also easily operates in conjunction with (but does not require)=20
many currently deployed anti-spam techniques.

------=_Part_25505_7975606.1115333510921
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br>
We'd like to solicit feedback from the SMTP community on <br>
our recent IETF draft titled &quot;Receiver-Driven Extensions to SMTP&quot;=
.<br>
<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-duan-smtp-receiver-dri=
ven-00.txt">http://www.ietf.org/internet-drafts/draft-duan-smtp-receiver-dr=
iven-00.txt</a><br>
<br>
The abstract of the draft is attached below.<br>
<br>
As we are new to the IETF process, we welcome any suggestions <br>
pointing out potential improvements as well as deficiencies in the draft.<b=
r>
<br>
The following DiffMail project website and our related paper in SRUTI'05 <b=
r>
might also be of interest.<br>
<br>
<a href=3D"http://www.cs.fsu.edu/~duan/projects/diffmail/diffmail.htm">http=
://www.cs.fsu.edu/~duan/projects/diffmail/diffmail.htm</a><br>
<br>
Thanks,<br>
Zhenhai Duan, Kartik Gopalan, Yingfei Dong<br>
<br>
<span style=3D"text-decoration: underline;">Abstract:</span><br>
<br>
The Differentiated Mail Transfer Protocol (DMTP) provides simple <br>
extensions to the Simple Mail Transfer Protocol (SMTP) that <br>
enable receivers to exercise greater control over the email delivery <br>
process. The current SMTP-based email delivery architecture is <br>
fundamentally sender-driven and distinctly lacks receiver control over<br>
the message delivery mechanism. This document describes DMTP <br>
that enables receivers to classify senders into three categories -- allowed=
, <br>
denied, and unclassified -- and process the delivery of messages <br>
from each category independently. As is the current practice, receivers <br=
>
may directly accept messages from senders in the allowed<br>
category and decline senders in the denied category. In addition, <br>
DMTP receivers require senders in the unclassified category to <br>
store messages on the senders' own mail servers. Such messages <br>
are retrieved only if and when the end receivers wish to do so. <br>
By granting greater control over message delivery to receivers and<br>
imposing greater message storage and maintenance overhead on <br>
senders, DMTP provides significant advantages in controlling spam. <br>
DMTP also easily operates in conjunction with (but does not require) <br>
many currently deployed anti-spam techniques.<br>
<br>

------=_Part_25505_7975606.1115333510921--

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Wed, 4 May 2005 21:45:08 +0200
From: Markus Stumpf <[email-masked]>
To: Arun Sankar <[email-masked]>
Cc: [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

On Wed, May 04, 2005 at 10:00:34PM +0530, Arun Sankar wrote:
> to apply to it. But it is the same case with a broken MTA who may have 
> the Cc not implemented properly.

Ok, I'll give you a mantra:
   rfc2821 is different from rfc2822.
   SMTP servers don't care about mail headers (**)

If you type in addresses to the 2822.To and 2822.Cc and 2822.Bcc and
2822.From lines in your mail client it is in the scope of the MUA to
"translate" them to correct RFC2821 syntax, i.e. send appropriate
MAIL FROM: and RCPT TO: commands in the SMTP dialogue and remove any
Bcc: lines. A SMTP MTA doesn't even know what those funny characters
are/mean, which it receives during the DATA (Dont Anytime Touch Anything)
phase.

If in real life you write a letter (this is rfc2822) and give it to your
secretary (i.e. your mail client aka MUA) to make copies and send it to
the recipients and add them to your real life post folder s/he has to
put it in envelope(s) and put addresses on them (this is rfc2821).
And it is also in the scope of your secretary (aka the MUA) to write
correctly addressed envelopes taken from the information in your letter
and maybe the post-it [tm] on it saying whom to send a carbon copy (Bcc)
to and to not make copies with the post-it on the letter.
The postal system (this is the MTA) doesn't look at your letter inside
the envelope to see where to send it to. They don't care what is inside
the envelope and it is neither their job nor does anybody want them to
do that and read their letters.

So no MTA cares about the headers you add to your letter or the
information you put into the envelope.

Talking about the SMTP MTA (aka RFC2821) being responsible for recognizing
the contents of the mail headers (aka RFC2822) liek To:, From:, Bcc:,
Cc:, ... is simply bullshit (**).

So, let's repeat our mantra from the beginning:
   rfc2821 is different from rfc2822.
   SMTP servers don't care about mail headers (**)

Ommmm ...

	\Maex

** There is one (valid?) exception I know of:
   some MTAs looks at the number of Received: lines for the sake of loop
   detection.

-- 
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: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Date: Wed, 4 May 2005 14:42:51 -0400
Sender: [email-masked]

On Wed May 4 2005 06:30, [email-masked] wrote:
> 
> I agree with Markus
> This draft  is only good to test your knowledge of the various mail protocols by finding all the errors in this one.
> 
> On a first quick reading I discovered 3 errors
> 
> 1 wrong naming of RFC's
> 2 non existing entities (SMTP headers???)
> 3 (RFC2822?) headers changing by non recognising MDA's?? (that means nothing less than a non backward compatability)
> 
> Who can find more errors ...

4. the formatting is screwed up (no formfeeds between pages)
5. the boilerplate is out of date
6. published this month, but with last year in the copyright lines
7. ABNF rule "display-name" undefined
8. based on a flawed assumption that transport uses message content
   rather than SMTP command arguments
9+:
idnits 1.71 (02 May 2005)

draft-grandhi-pc-smtp-00.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
  * The document seems to lack separate sections for Informative/Normative References.
    Checking conformance with RFC 3978/3979 boilerplate...
  * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement  -- however, there's a paragraph with a matching
    beginning. Boilerplate error?
    (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate.  After 6 May 2005,
    submission of drafts without verbatim RFC 3978 boilerplate is not accepted.)

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

  - It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages

  Miscellaneous warnings:

    None.

    Run idnits with the --verbose option for more detailed information.

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Date: Wed, 4 May 2005 14:02:31 -0400
Cc: Arun Sankar <[email-masked]>
Sender: [email-masked]

On Wed May 4 2005 12:30, Arun Sankar wrote:

> But it is the same case with a broken MTA who may have 
> the Cc not implemented properly.

MTAs don't "implement" Cc.  MTAs (SMTP, see RFCs 821, 2821) have only
RCPT TO.  The distinction between "To" and "Cc" is in (human) user space,
and is not well-defined even there.  Moreover, while delivery
conventionally is consistent with user-level text in the message header,
there is no requirement that that be the case, just as with physical mail
(nothing prevents one from putting a check to a utility company in an
envelope addressed to a family member, or a personal letter intended for
a family member in an envelope addressed to a utility company).  Don't
mess with user-to-user (message header) communications; see
draft-lilly-field-specification-03.txt, section 4.3.1 -- for HTML fans,
try
http://users.erols.com/blilly/Internet-Drafts/draft-lilly-field-specification-03.html#4.3.1

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: deja vu: draft-grandhi-pc-smtp-00.txt
Date:  Wed, 04 May 2005 19:12:30 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Sender: [email-masked]

Arun Sankar wrote:

> ncc and pcc are vastly different utilities

Yes, if you want PCC you'd implement it somehow at your MSA.

All it does is to take a list of addresses, forward one mail
to each recipient, and copy the corresponding RCPT TO to the
2822 To.  Doing it at the MDA is backwards, not allowed, and
won't fly without a "worldwide update" (the FUSSP paradox).

                     Bye, Frank

Date: Wed, 04 May 2005 22:00:34 +0530
From: Arun Sankar <[email-masked]>
To: Markus Stumpf <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Sender: [email-masked]

Hi Mark,

ncc and pcc are vastly different utilities. Similar mail header addition 
is one similarity though. But I guess the kind of application and the 
kind of audience both are looking at are very different.

Ncc is more of a negate that simplifies the users work in typing out a 
whole lot of mail-ids and utilize the availability of aliases which are 
available. We had discussed already of the inability for the whole world 
to apply to it. But it is the same case with a broken MTA who may have 
the Cc not implemented properly. To be more practical it can be 
implemented probably on an org wide scale wherein mandated MTA's and 
MUA's are to be used and this is not seen like a push it down the throat 
feature but a take it if you feel like feature.

Another point that came about is utility of the ncc feature. We do not 
argue the utility of the Cc feature, though it is similar to the To 
field, Cc has its own merits and just because someone does not use the 
To field and the Cc field is very redundant, we do not go ahead and 
think of removing the Cc. Ncc is more of a feature that is helpful to 
all who do a lot of mailing to aliases and I do not mean mailing-lists 
when I say aliases.

I guess branding the both as a deja vu might not be entirely ok just 
because they sound similar.

(a deja vu occurs where there is a change in the Matrix ;))

[email-masked] wrote:

>I agree with Markus
>This draft  is only good to test your knowledge of the various mail protocols by finding all the errors in this one.
>
>On a first quick reading I discovered 3 errors
>
>1 wrong naming of RFC's
>2 non existing entities (SMTP headers???)
>3 (RFC2822?) headers changing by non recognising MDA's?? (that means nothing less than a non backward compatability)
>
>Who can find more errors ...
>
>
>  
>
>>AFAIK the same type and idea of proposal as discussed before in
>>  draft-arun-ncc-smtp-02.txt
>>with the same flaws and even from the same group ... HP India.
>>
>>Now the field is called Pc instead of Ncc.
>>
>>The author agains completely mixes 2821 and 2822.
>>
>>Reminds me of some broken handheld (psion?) software in the end 90s.
>>They sent the Bcc field along for the SMTP server to take care of it.
>>
>>\Maex
>>    
>>
>
>
>
>  
>

-- 
Arun

Invention is the mother of necessity.
            -- Thorstein Veblen

To: Markus Stumpf <[email-masked]>
Cc: [email-masked]
From: [email-masked]
Subject: Re: deja vu: draft-grandhi-pc-smtp-00.txt
Date: Wed, 4 May 2005 11:30:15 +0100
Sender: [email-masked]

I agree with Markus
This draft  is only good to test your knowledge of the various mail protocols by finding all the errors in this one.

On a first quick reading I discovered 3 errors

1 wrong naming of RFC's
2 non existing entities (SMTP headers???)
3 (RFC2822?) headers changing by non recognising MDA's?? (that means nothing less than a non backward compatability)

Who can find more errors ...

> 
> AFAIK the same type and idea of proposal as discussed before in
>   draft-arun-ncc-smtp-02.txt
> with the same flaws and even from the same group ... HP India.
> 
> Now the field is called Pc instead of Ncc.
> 
> The author agains completely mixes 2821 and 2822.
> 
> Reminds me of some broken handheld (psion?) software in the end 90s.
> They sent the Bcc field along for the SMTP server to take care of it.
> 
> \Maex

Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Date: Wed, 4 May 2005 00:50:34 +0200
From: Markus Stumpf <[email-masked]>
To: [email-masked]
Subject: deja vu: draft-grandhi-pc-smtp-00.txt
Organization: SpaceNet AG, Muenchen, Germany
Sender: [email-masked]

AFAIK the same type and idea of proposal as discussed before in
    draft-arun-ncc-smtp-02.txt
with the same flaws and even from the same group ... HP India.

Now the field is called Pc instead of Ncc.

The author agains completely mixes 2821 and 2822.

Reminds me of some broken handheld (psion?) software in the end 90s.
They sent the Bcc field along for the SMTP server to take care of it.

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