ietf-mxcomp
[Top] [All Lists]

Re: plan for april 5th xmpp conference...

2004-03-27 19:10:23

In 
<20040326111604(_dot_)6e01bb96(_dot_)mrose+internet(_dot_)ietf(_dot_)mxcomp(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
 Marshall Rose 
<mrose+internet(_dot_)ietf(_dot_)mxcomp(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>
 writes:

    by friday, april 2nd, please send an email to the mailing list
    explaining which identity you think the working group should address
    along with a short list of bullet points as to the trade-offs
    associated with using this identity.

This message triggered a lot of traffic.

I am a little confused by it though.  According to the list of
milestones posted by Ted Hardie on Mar 15th, we are supposed to be
having a *last call* for this on the 4th.  Why have a conference to
discuss something that should have already been decided.


As far as posting post said information, I already did back on the
18th.  I'll repost here, just in case it was overlooked.




In <p06020403bc7be6e71cf3(_at_)[205(_dot_)214(_dot_)163(_dot_)2]> Ted Hardie 
<hardie(_at_)qualcomm(_dot_)com> writes:

Working Group Goals and Milestones:

March 04       Discuss identities with which MTA authorization
              should be associated

    April     04      Working Group last call on which identities
    will be
              used for MTA authorization

Ok, we are supposed to be discussing the identities with which MTA
authorization should be associated with.


I've thought about this for well over a year now, and my opinions
haven't changed, despite all rehashing of stuff that was discussed on
ASRG many moons ago.

So, I might a well state my opinions and be done with it


*** I think the identities that we should consider are the RFC2821
*** MAIL FROM and HELO domains names.


My reasons for this are more pragmatic than technical.


Why I think we should work first on the RFC2821 MAIL FROM and HELO domains.

* The MAIL FROM is where bounces go to and a lot of the spam that
  makes it past SpamAssassin and into my inbox are bogus bounces/virus
  notifications.

* Both the HELO domain and the MAIL FROM show up in email headers.
  When non-email-gurus look for the source of the spam, they are often
  mislead into believing that the spoofed domains are the real source.
  This causes bogus abuse desk complaints.

* A very large percentage of the email being sent now-a-days is spam
  with forged MAIL FROM addresses.  As a result, it is no longer safe
  to accept email and then send bounces to the MAIL FROM address
  without causing problems for innocent third parties.  No other
  header/identity is acceptable to send bounces to either.  As a
  result, we have effectively lost the ability to safely send bounces.
  the best we can do is use a 5xx rejection code during the SMTP
  session, and even that can cause innocent third parties to receive
  bogus bounces.

  The MAIL FROM address has basically lost all of its historical
  usefulness.  While we can not restore all of the functionality it
  once had, we can restore a great deal of it.
  
* I believe that the this is an easier problem to solve than the
  RFC2822 header spoofing problems.  The RFC2821 data is handled
  almost entirely by programs and thus lends itself to verification
  via programs.
  
* There are positive incentive for domain owners to publish
  designated sender records and for email receivers to check them.

  Besides the reduced number of bogus bounces and bogus complaints, by
  publishing designated sender records, domain owners are making a
  public notice to protect their brand names and their good good
  reputations.  This is kind of like putting up "No trespassing"
  signs.  Publishing records is a very low cost thing to do, even if
  initially there isn't a huge payback.

  For email receivers, the benefits for checking is pretty clear: it
  catches spam, joe-jobs and phishing.  It will never catch all of it,
  but again, this is a fairly low cost thing to check.  Even at this
  early stage, SPF checks are stopping about 1% of the spam that
  reaches my machine.

* With SPF having been in field testing for months, the problem space
  is (comparatively) well understood.
  
* I believe that rolling out a system that validates the RFC2821 data
  can play an important part in the process of validating the RFC2822
  data.  I don't think we need to get into bogged down in exactly how
  this will work right now.  Let's pick the low hanging fruit first.



Why not the IP address via MTA-MARK/SS

* Receivers can already largely solve this problem today via DUL
  lists.

* Senders can already largely solve this problem today via port 25
  blocking. 

* I see little reason why owners of IP space who don't publish DUL
  lists or do port 25 blocking would do MTA mark.  There is no
  incentive for them, this is something that they will have to spend a
  great deal of time doing in order to help out other people.

* The rDNS space is a mess.



Why not the RFC2822 headers:

* To be really effective at protecting the RFC2822 headers from
  phishing and such, you need to changes to MUAs.

  * There are several decimal orders of magnitude (hi Ted) more
    installed MUAs than installed MTAs.
    
  * We have far less influence in the MUA market.

* Solving the RFC2822 data spoofing is a much harder problem

  * There are too many different headers created by too many different
    programs and that creates too many different cases to analyze.

  * The RFC2822 headers allow comment string, so if you really want to
    tackle phishing and spoofing, you have to figure out how to block
    email claiming to be from things like this:

         From: "Paypal Security Desk" <abuse(_at_)paypalsecurity(_dot_)com>

* I don't believe the RFC2822 spoofing problem space is as well
  understood as the RFC2821 problem space.


Even though this is a fairly long post, it really only covers the
surface of why I am convinced that the RFC2821 data is the thing to
tackle first.  While I'm certain that, for each point mentioned above,
there are people who disagree with me.  I'm certain that there are
people who disagree with all of this.  However, to change my mind
after studying this problem for as long as I have, you would need to
come up with some pretty strong arguments.  If such arguments
existed, I would likely have heard them before now.


So, with two weeks to go before a "last call" on this issue is needed,
I'm ready to put my two cents in.


-wayne