spf-discuss
[Top] [All Lists]

Re: Re: Email Forwarder's Protocol ( EFP )

2005-03-01 01:35:04
  Indulge me which I take this in simple steps...

simple steps are good.  i might even be able to follow things, if taken slowly 
enough.


  RFC2821.MailFrom  specifies the address of the entity who is to be held
  responsible and accountable for inserting the message into the SMTP system.

Alas, no, though yes, that is what many folks use as their reference.

this is understandable since rfc2821 says 

   "contains the source mailbox"

However the question of how to *use* the address is more helpful than this sort 
of descriptive bit.  

Hence: 

   "used to report errors"

   "to designate the address to
   which messages indicating non-delivery or other mail system failures
   are to be sent"

Even better is that RFC2822 has explicit language with the word "responsible":


   "agent responsible for the actual transmission of the
   message"

  That entity is responsible and accountable for:

  a) The content

RFC2822.From is considered to have primary responsibility.



  b) The list of RFC21 RcptTo recipients.

Well, yeah. rfc2822.Sender is presumably responsible for creating the RcptT0 
list.



  This is the entity to which DSNs of whatever nature are to be sent.

No.  That is defined to be the RFC2821.MailFrom address, which can be different 
from the RFC2822.Sender address.


  I, personally, define the action of inserting a message using a MailFrom
  entity
  address _without the authority of that entity_ as forgery.  It's the lack of
  authority which is the key concept.

Actually, your view fits the language I have in email-arch just fine.


  What SPF does is ask whether the inserting host (identified by its IP
  address)
  is authorised by the MailFrom entity to insert messages on its behalf, i.e.
  to
  insert messages having that MailFrom address.

There is a difference between saying that having a different Mailfrom from 
Sender is authorized by the Sender, versus saying that identity in the MailFrom 
does the authorizing.

A very big difference.


  But now that mail box has a mechanism which takes the original content (I'm
  chosing my words very carefully here) and initiates a new message-sending
  process using a _new_ RcptTo address; the forwarding address. It initiates a
  new
  SMTP sending request.

  Suppose that the mechanism uses the _original_  MailFrom address.

  What is happening is that an intermediary which has no authority from the
  mailFrom entity is sending a message to a recipient address which is unknown
  to
  the mailFrom entity. The mailFrom entity cannot be held accountable for
  sending
  the message (<i>any</i> message - see below) to that new address.

Not quite.

For example, there can be a big difference between the entity identified by the 
entire MailFrom address, versus the entity responsible for administering the 
domain name records for the domain referenced in MailFrom.

A very big difference.

And that's interesting only if one ignores the big difference between saying 
that the rfc2822.Sender does the authorizing and saying that the 
rfc2821.mailfrom does the authorizing.


  Does anyone wish to argue that :

  1) Anybody should be free to use a mailFrom address without the authority of
  the
  entity which 'owns' (leases?) that address?

  or

  2) Any valid recipient is implicitly authorised by the original mailFrom
  sender
  to send any message content it wishes to any third party citing the original
  mailFrom (and if so argued, please explain the distinction from 1),

I just did.  See above.


  3) Any valid recipient is implicitly authorised by the original mailFrom
  sender
  to resend the original, unaltered message content to any third party citing
  the
  original mailFrom,

you might want to review assorted literature about situations involved 
expectations of privacy or confidentiality.  mere receipt does not 
automatically impart authority to retransmit arbitrarily.



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