Subject: TECH-OMISSION: leave open other authentication methods in -core

From: Daniel Quinlan <[email-masked]>
Date: Mon, 23 Aug 2004 16:11:09 -0700

In section 5.2, the paragraph defining the result for pass should be
changed to

   An SMTP server receiving this result SHOULD treat the message as
   authentic.  However, it MAY treat the message as authentic or not
   authentic based on other authentication methods.  It MAY accept
   or reject the message depending on other policies.

in order to allow for other authentication methods such as POP before
SMTP, SMTP AUTH, etc.  It may be possible to find a better phrasing to
address this omission.

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2004 11:59:34 -0700

Protocol & Core

There is no security advice for using random source ports for DNS
queries reaching the Internet.

There is no advice regarding the potential presence of transparent
inception of outbound SMTP traffic by ISPs.

There is no advice waring against the use of "?all" in the case of
shared outbound SMTP servers.

There is no advice for the use of "+all".  Jim Lyon explained this will
lead to bad reputations.  This implies the mailbox domain, used to
resolve the MTA address, is also being used to establish reputations,
even when the MTA is not authorized!

There should be advice warning against establishing reputation
information when the MTA address has not been authenticated, or when the
SPF2 record uses "?all".  It must not be presumed all MTAs check for the
SPF2 permissions, or that the outbound MTA is not shared, nor can this
checking and sharing be verified. 

There should be a caution that prohibits reputations based upon
non-authorized MTAs.

There should also be a warning for "?all" when the outbound path is
shared.  This sharing will "promote" mail from other domains as being
fully validated and may lead to false assumptions with respect to the
recipient, when the Mailbox domain is used to either obtain or record
this information.

There should be advice that only the IP address should be used to check
reputations and to base complaints, as the Mailbox domain has not been
adequately authenticated while it can not be presumed all MTA servers in
the path of the message performed the requisite mail channel checks and
that the MTA is not shared with other disparately administered domains.

Don't limit the scope of the SPF record to just PRA plus others.  Leave
the record open to any scope that may exclude PRA.

The use of exists and ptr record types adds a burden the recipient may
not wish to endure.  There should be a warning that this type of record
may be rejected.

-Doug

---

From: <[email-masked]>
Date: Mon, 30 Aug 2004 16:51:18 -0400

> not wish to endure.  There should be a warning that this type of record

If you are going to do this, you should treat exists and ptr
separately.  ptr record types almost certainly don't add a burden to
the recipient.  The reason is that pretty much all MTAs do a reverse
lookup on the client's IP address anyway for inclusion in the
Received: header.  The ptr check can therefore be implemented without
an additional DNS lookup.

The exists header can, of course, lead to extra DNS lookups.  Note
also that if you are worried about extra DNS lookups, the include
directive can definitely be responsible for more DNS traffic.  I think
that the flexibility offered by exists and include is very useful in a
number of situations, and so would rather not see "reasonable" use of
the mechanisms deprecated, though clearly we would also like clients
not to feel compelled to go through with "unreasonable" checks. 
Recursion limits are a step in the right direction; whether or not
they suffice will be seen when we deploy this stuff...

[I also believe that a few changes, like allowing the negation of
operators, would significantly reduce (but not eliminate) the need for
include and exists.  However, I recognize such discussion is no longer
in scope, and don't want to distract from the topic at hand...]

David

---

From: <[email-masked]>
Date: Mon, 30 Aug 2004 16:51:18 -0400

David

---

From: Douglas Otis <[email-masked]>
Date: Mon, 30 Aug 2004 11:59:34 -0700

Protocol & Core

-Doug