Subject: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd)

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 10 Sep 2004 14:41:31 -0700 (PDT)

This is very usefull draft for this WG.
We should consider sponsoring it further.

---------- Forwarded message ----------
Date: Fri, 10 Sep 2004 15:55:32 -0400
From: [email-masked]
To: [email-masked]
Subject: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Message Header for Indicating Sender Authentication Status
	Author(s)	: M. Kucherawy
	Filename	: draft-kucherawy-sender-auth-header-00.txt
	Pages		: 15
	Date		: 2004-9-10
	
This memo defines a new message header for use with [MAIL] messages
   to indicate the results of sender authentication efforts to mail user
   agents (MUAs) in order to equip them to relay that information in a
   convenient way to users.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kucherawy-sender-auth-header-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-kucherawy-sender-auth-header-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Sep 2004 04:05:10 +0200

> We should consider sponsoring it further.

Yes, it could replace the "Received-SPF:" header in the SPF
classic draft.  I'm a bit lost with one of the examples (9.4),
it has auth=, spf=, and sender-id=, but AUTH is done by the
MSA, while spf resp. sender-id tests are done by the MX / MDA.

                     Bye, Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Sep 2004 17:46:38 -0700 (PDT)

On Sat, 11 Sep 2004, Frank Ellermann wrote:
> Yes, it could replace the "Received-SPF:" header in the SPF classic
> draft.  I'm a bit lost with one of the examples (9.4), it has auth=,
> spf=, and sender-id=, but AUTH is done by the MSA, while spf resp.
> sender-id tests are done by the MX / MDA.

I included any authentication information that might be useful to an MUA
or LDA when evaluating how trustworthy the sender data is.  If for example
there are multiple layers of transport within an organization, and
sender-id, SPF and DomainKeys are only done at the border inbound but an
internal message was injected for which the client authenticated using
SMTP AUTH, I felt that fact should be relayed should the MUA or LDA wish
to make a decision based on it.

I also used it as the only available already-standard sender
authentication scheme on the books; everything else is only a draft thus
far.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 17 Sep 2004 02:06:53 +0200

Murray S. Kucherawy wrote:

> sender-id, SPF and DomainKeys are only done at the border
> inbound but an internal message was injected for which the
> client authenticated using SMTP AUTH, I felt that fact
> should be relayed should the MUA or LDA wish to make a
> decision based on it.

Sure, I was only confused because in your example the very
same host did both (MSA auth stuff + MX SPF tests).  Maybe
split it in two headers.  That would also demonstrate cases
where spammers could send forged Authentication-Results.

Out of curiosity, I use an MSA enforcing a valid MAIL FROM.
This MSA uses SMTP-after-POP (and before you laugh, that's
not much worse than insecure PLAIN or LOGIN).  What are the
corresponding Authentication-Results ?  Here's my guess:

| Authentication-Results: mail2.hamburg.example
|   return-path=[email-masked]; auth=pass (pop3)

Is that the idea ?  Or should the MSA match the POP3 mechanism
to a corresponding SMTP AUTH, (login) in my example.  But IIRC
"login" isn't documented in any RfC.  And officially "plain"
isn't allowed without TLS.  SMTP-after-APOP would be better
than "login" or "plain", so maybe you need some additional
keywords like "tls", "login" or "apop" for auth.

Actually you don't need the "pass" for auth, let alone any
other weird SPF results, auth=apop or auth=cram-md5 should
be good enough.

For SPF the tested header at the moment implicitly defines
the tested scope.  Return-path is always spf2.0/mailfrom,
helo is always spf2.0/helo.  Anything else (from, sender,
resent-*) is always spf2.0/pra.

Therefore you could simply use header=mailbox spf=result
for spf2.0/helo, spf2.0/mailfrom, and spf2.0/pra.  "Helo"
is no header, but it fits in your "headerspec" syntax, if
you define "headerspec" in the next draft ;-)

This simplification won't work for Wayne's spf2.0/from,
because then a tested "from" either corresponds to a PRA
or to Wayne's draft.

IMHO you don't need a list of SPF results, that's defined
in protocol-03, and rather useless for "auth".  You could
add a section how MUAs can try to auto-detect the support
of this header by their MDAs (Outlook uses test messages
for similar purposes).
                        Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 17 Sep 2004 00:17:47 -0400

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 16, 2004 8:06 PM
Subject: Re: I-D ACTION:draft-kucherawy-sender-auth-header-00.txt (fwd)

> corresponding Authentication-Results ?  Here's my guess:

I don't understand this reason for this.

The problem is :Final Destination mail from Anonymous Senders."

Local ISP users who are "malicious" and/or "abusive" is an administrative
problem.  You can probably add technical logic such as limits, but overall
the authenticated ISP user is not the problem the world is facing with
abusive final destination anonymous senders.

Remember what the standard mode of SMTP is:

  1) Authenticated or IP allowed clients can send local and remote mail.
  2) No authentication is required for final destination mail (local).

In other words, anonymous senders can not send remote mail.

So the anti-spam technological pressure point is at #2.  Not #1.

This is a key factor most people seem to forget.  RFC 2821 has provided us a
DOOR to help solve the problem and also run in a more optimized mode with a
method that none of the MARID proposals use or consider.  See RFC 2821
section "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.

What it says is this:  You have 3 states points in SMTP:

    EHLO/HELO
    MAIL FROM
    RCPT TO:

Everyone is worry about the first two states before RCPT TO is known.   They
are proposing changes to SMTP receivers where overhead is added to check the
first two states.  A blind check with total disregard to establishing the
critical information of final destination or remote mail.

The section 3.3 suggestion is to simply delay the "overhead"
authentication/validation logic for EHLO/HELO and MAIL FROM until RCPT TO is
known. In practice, it works wonderfully.  You can save a tremendous amount
of your ANTI-SPAM overhead using this key method.

Remember again, if RCPT TO is not a local user, then the transaction becomes
a RELAY, thus the client IP and/or MAIL FROM must be authenticated using
standard SMTP technology already in place.

However, if RCPT TO is a local user, then SMTP says that you must accept the
mail regardless of the sender. That is the golden rule and also the reason
for the SPAM problem.

So in short,  this is a Final Destination Anonymous Sender issue.  I don't
see a need for MARID or anti-spoof overhead if the client is authenticated.

Thanks

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office