spf-discuss
[Top] [All Lists]

RE: Reputation Services and HELO/EHLO Checking For Unified SPF

2004-07-02 13:23:46
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Meng 
Weng Wong
Sent: Friday, July 02, 2004 3:54 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Reputation Services and HELO/EHLO Checking
For Unified SPF


On Fri, Jul 02, 2004 at 02:47:42PM -0400, spf(_at_)kitterman(_dot_)com wrote:
|
| It might be easier to convert everyone to SMTP Auth and limited
addresses.
| It might not.  Who is going to write and sponsor the RFC's that would
| describe this new set of requirements?  I think that the answer
is no one.
|

http://www.ietf.org/internet-drafts/draft-hutzler-spamops-00.txt

That answers half of the question, I think.  Here are the best practices
that are listed in the draft:

Page 4:

 Best practices are:

   o  Operators of MSAs MUST perform authentication during mail
      submission, based on an existing relationship with the submitting
      entity. This requirement applies to all mail submission
      mechanisms.

   o  For email being received from outside their local operational
      environment, email service operators MUST distinguish between mail
      that will be delivered inside that environment, from mail that is
      to be relayed back out to the Internet.  This prevents the problem
      embodied by "open" relays.

   o  Mail coming from outside an email operator's local environment,
      and having a RCPT-TO address that resolves to a destination
      outside the local environment, MUST be treated as mail submission,
      rather than mail relaying.

Page 5:

Best practices are:

   o  MSAs MUST support the SUBMISSION port, for MUAs accessing from
      outside the MSA's local environment.

   o  MSAs MUST perform authentication during all mail transactions on
      the SUBMISSION port, even for a message having a RCPT TO address
      that would not cause the message to be relayed.

   o  Access Providers SHALL NOT block users from accessing the external
      Internet using the SUBMISSION port.

   o  MUAs SHOULD use the SUBMISSION port for message submission.

   Note that the requirement for authentication, on the part of the MSA,
   thereby makes that MSA responsible for the ensuing traffic it
   generates.

I read this as saying that Mail Submission Agents (MSAs) must support mail
submission via port 587 and that access providers must not block port 587.
Further it says that MSAs must only take mail from MUAs with which they have
a previous relationship.  That takes care of the the is the MUA authorized
to use the MSA part of the problem.  It is silent about the message
addresses that can be used.

As I read this draft, Verizon (to continue to pick them as an example since
I am familiar with how they work) is currently compliant with this draft.
Assuming I hit the right buttons when I send (no guarantee there), this
message will come to the list via a Verizon SMTP server even though I am not
currently connected to the internet via their network.  But still the domain
that the message is "From" has nothing to do with Verizon.  They have no
knowledge of what domains I own and make no attempt to decide what addresses
I use.  You could certainly argue that is a poor practice.  I won't debate
you on that.  I merely notice that it is a common one.

I also like the the note, "...thereby makes that MSA responsible for the
ensuing traffic it generates".  I think this draft supports my contention
that a RHSBL should first point it's finger at the domain of the MSA/MTA
before it whacks an end user.

I do believe that by using HELO/EHLO to aim the RHSBLs at the entity that
allowed the message to be injected into the messaging stream, we will do
more good faster with less risk of collateral damage.

Scott