Re: A new SMTP "3821" [Re: FTC stuff...........]

Awesome! you must have a better source than me ;)


----- Original Message ----- 
From: "Hector Santos" <[email protected]>
To: "MXCOMP" <[email protected]>
Sent: Tuesday, November 23, 2004 7:22 AM
Subject: A new SMTP "3821" [Re: FTC stuff...........]


>
>
> ----- Original Message -----
> From: "Dave Crocker" <[email protected]>
> To: "Alan DeKok" <[email protected]>; "MXCOMP" <[email protected]>
> Sent: Sunday, November 21, 2004 2:18 AM
> Subject: Re: FTC stuff 0) Lies 1)Yahoo & DK. 2)GoDaddy DNS & SPF & CSV.
> 3)Dean & FUSSP. 4)Testing 5)EFF, Anonymity.
>
>
>
>> > For three, my statement was talking about failures of a model, not
>
>> When you referred to SMTP you said nothing about a "model",
>> nevermind a security model.  To the extent that you really
>> meant to refer to a particular security model, then by all means
>> please state that, rather than broadly describing that a long-standing,
>> well-functioning protocol as a "failure".
>
> We all know that SMTP has not been a failure.
>
> What Alan is suggesting, for which I strongly agree, is that the focus in
> solving the "problem" needs a revisiting of the SMTP model or more
> specifically, the functional specification.   We have tried to "plug in"
> ideas that simply fail to account for the entire MODEL for not only 
> maximum
> compliancy but for productive and maximum adaptability.  In some cases, we
> attempted to plug in concepts that simply doesn't fit or is out of place.
>
> Just consider this one very simple realistic fact:
>
> A system that employs stronger SMTP compliancy enjoys a higher SMTP level
> protection against abuse.
>
> We have more than 1 year of steady on-going Anti-Spoof technology in place
> with a consistent result on a
> day to day, month to month basis.   A simple emphasis on compliancy will
> provide you atleast a 60-90%
> solution.   I can't dispute these.  These are the hard core empirical 
> facts.
>
> The point?
>
> The majority of the problem is solved by concentrating at enforcing a new
> level of "proper" operations.
>
> We need to get over the "silly" arguments about what "MAIL FROM:" means.
>
> We know what it means because its been operating in a consistent DEFINED 
> way
> for decades.
>
> We need to be consistent.
>
> If we discuss functional SMTP design flows for system notifications which 
> is
> based on the expectation that the return path is "usable"  then we need to
> stop with idiotic suggestions that the return path is only "usable" at the
> point is it required - a system notification, and not before then.     We
> need to make sure the specifications makes it very CLEAR that the RETURN
> PATH is expected to be valid, regardless of who it points too when it is
> initially issued.   The idea of how a particular system may which to
> implement that is an independent idea.  It has nothing to do with the
> validity of it.
>
> Now, can we improve SMTP to better describe what the RETURN PATH is? 
> user,
> system, some list or whatever?  Sure, but what is common in all, is that 
> its
> a valid address.
>
> Can we add new commands to help a "new process?"
>
> I think so.  But we need to first look at what are the "holes" or factors
> that are "missing" to help define what these commands should be.
>
> Do we need to consider future payload transaction protocol methods?
>
> Sure, I strongly think so.  This is one area I felt very strongly that
> didn't not help Sender-ID, it failed to 100% recognize the payload issue 
> and
> how important that is.    But I personally see the payload issue in a 
> bigger
> concept than just for security, but for efficiency.
>
> This is the kind of SMTP R&D WG discussion that needs to take place.  I
> doubt this can happen in IETF-SMTP.  The type of people and attitude is 
> just
> wrong for it.  We need new open minded people who can think out of the
> "box", and also understand the issues, and then with the help of the
> 'experts" like yourself,  help bring it all back together.   What we don't
> need is are show stoppers who nix everything right at the start.
>
> Once we get a consistent understanding of the issues with SMTP at each 
> step,
> removing the ambiguities, adding/merging BCP concepts/RFCs for "today"
> operations, then we have a basis, an baseline, a framework to begin
> implementing "Security Plug-ins" that will not only work better, but make
> sense.
>
> This may all sound simplistic to you, but that is what we need; getting 
> back
> to basics, taking a step back in the balcony.
>
> The #1 improvement we can make or the IETF can make is a major cleanup of
> the 2821 and related specifications as one new document.
>
> Sincerely,
>
> Hector Santos, CTO
> Santronics Software, Inc.
> http://www.santronics.com
> 305-431-2846 Cell
> 305-248-3204 Office
>
>
>
>
>
>
>
>
>