Re: Problems with SPF, solutions, and a timeline.

I don't see the point in and use of such a rewriting scheme
in context of smtp-verify.




What's that all about what we're doing here?

  We are looking for any method to find and locate 
  a domain owner who takes over responsibility for that
  particular mail and for it's sender.

It actually does not matter how exactly we try to figure out this
particular domain. All we need is to *locate* it in order to *query* 
it. Introducing wild rewriting schemes does not make this job any
easier. On the contrary, it will break many existing mail
installations, because it's not compatible with plain MUAs. 


Whatever way we choose for rewriting, labelling, tagging, ...
the Spammer can always have a throwaway domain and build the 
mail exactly that way that it is authorized by that domain. 

So which benefit do we have from indroducing weird rewriting schemes? 
None. That's just marketing blah-blah. Nice web design for the
proposal, but where's the substantiation?

You don't even give a precise statement about the problem 
you're trying to solve, and no explanation why this is needed.



So let's define the problem:

- If we receive a plain message directly, we can usually take 
  the sender's address for locating the domain which takes over
  responsibility. Good. No problem here.


- If the message was forwarded, bounced, mailing-listed,...
  the given sender address will not help us in locating the 
  domain taking responsibility. Bad. We need a different way 
  to locate. That's the problem we 
  need to solve.



  There are three ways to give the information where to look for 
  authorization: In the HELO command, in the  envelope or in the header.

  The first way (HELO) has been discussed extensively.


  The second way is to give it already in the envelope. But if you
  agree to modify the envelope and rewrite the sender's address, then
  what's the point in building such artifical addresses which actually
  do not exist? What if a mail is forwarded five times? No size limit?
  Sender address of 300 characters?

  And what if the original sender's address is admin+web. 
  How would you parse admin+web+ann correctly? Is this
  (admin+web)+ann or admin+(web+ann) ?

  If you agree to rewrite the envelope sender, then simply use
  the correct e-mail address of the responsible forwarder. Like
  proposed in the RMX drafts.





  The third way is to give the information in the header. 

  The best proposal so far to cope with this problem is Microsoft's
  CallerID proposal. They're analyzing the header for different 
  entries to find the domain where to fetch authorization records
  from. Nice work. But what do they actually do? It is simply digging
  through the header and test whether any of the mentioned domains 
  is taking over responsibility. 

  The solution is much more simple. All these proposals, including 
  Microsoft's and SRS do one thing: Somewhere, *Anywhere* in the 
  mail header must the domain taking over resposibility be mentioned. 
  This has no real semantics, it is just to find any domain which's 
  authorization record covers the IP address where the mail was 
  sent from in the last transport step.

  We don't need to confuse users and their MUAs to get this.
  Keep it smart and simple. 

  If you don't want to rewrite the envelope, then all we need to do
  this much more easier is to just add a header line like


    RMX: somedomain.com


  which can be used to locate the domain where to look for the 
  authorization record. Or you could even take the topmost 
  Received Entry to look for a host name (by...) which to use for
  locating the domain with the authorization record covering the 
  SMTP IP address.

  That's the problem to solve, after all. Isn't it?





If I am correct and the given security problem is to just locate
the domain which is willing to take over responsibility, then please
explain why we need to use such a complicated and error-prone
rewriting scheme, requiring changes in all MTAs. 

If I am not correct and the problem is a different one, then please
state the problem you're trying to solve. 



Writing perl modules and designing web pages is fun, but a precise 
statement of the problem to solve and an explanation why to solve it
this way is more important.



Hadmut