[ietf-clear] Kickoff encouragement - CSV quotes.

[Carl Hutzler]

On 9/29/04 4:16 PM, "Ryan Ordway" <ryan at nwgeeks.com> wrote:

> 
>   Interesting. Can you elaborate what would
> be done based upon the results of the check?

Nothing until there is a spec on what we should do. Just saying my MTA is
going to have the ability to look up DNS records and compare them to HELO
domains and do something.



> 
> On Wed, 2004-09-29 at 04:07, Carl Hutzler wrote:
>> How about this one....
>> 
>> "AOL is already coding a capability to check the HELO against a DNS record.
>> We hope that a real standard can be agreed upon so we do not have 100
>> different ways (record formats) to do this. We hope to have our rough
>> capability available in the next 30 days".
>> 
>> BTW, all true :-)
>> 
>> -Carl
>> 
>> 
>> 
>> On 9/29/04 2:08 AM, "Matthew Elvey" <matthew at elvey.com> wrote:
>> 
>>> I collected a number of quotes from the MARID list, which temporarily
>>> are here:
>>> http://wiki.fastmail.fm/wiki/index.php/MrElveyScratchSpace#CSV (feel
>>> free to edit)
>>> It shows a helluva lot of support.
>>> 
>>> 
>>>     Advocacy of CSV on the MARID mailing list:
>>> 
>>> "We ... see a lot of benefit to the "newer" CSV idea." "This is a VERY
>>> interesting approach." "This sounds really cool." - Carl Hutzler (in
>>> charge of _AntiSpam_?
>>> <http://wiki.fastmail.fm/wiki/index.php/AntiSpam?action=create>
>>> Operations at AOL)
>>> 
>>>   http://www.imc.org/ietf-mxcomp/mail-archive/msg02057.html : CSV is
>>>   based on broadly deployed working code. - Doug Otis (who made many
>>>   other supporting arguments)
>>> 
>>> Who also said: The great thing about rehabilitating the EHLO name, is
>>> that this name is provided early in every SMTP session. The EHLO name is
>>> captured within the message headers to allow tracing. There is no need
>>> for submitter or to invent new mail headers to discern where the message
>>> is originating with the use of CSV applying the post-mark so to speak.
>>> 
>>>   http://www.imc.org/ietf-mxcomp/mail-archive/msg01175.html : "CSV is
>>>   orders of magnitude easier to deploy than SPF." - Matthew Elvey
>>> 
>>> http://article.gmane.org/gmane.ietf.mxcomp/5180 : Why everyone sending
>>> legit mail will publish CSV records.
>>> 
>>>   "... I support something simple and lightweight, that protects HELO
>>>   or MAIL FROM instead of body headers. If the recipient has a domain
>>>   that will put its reputation on the line to vouch for a message, it
>>>   doesn't need to be the one that appears in the body. We need to
>>>   create the smallest possible system that can authenticate one
>>>   protocol field in an SMTP transaction. From that, this or another
>>>   group can develop stronger mechanisms for combating forgery and
>>>   spam, but not until after basic authentication has been deployed." -
>>>   Philip Miller
>>> 
>>> "The original intent ... was to verify the parameters of the SMTP
>>> transaction. _W_e can still do that with ability to check ... EHLO if
>>> CSV is integrated into the main record format. " - Yakov Shafranovich
>>> 
>>> <Let's abandon MAIL FROM/PRA.> "I also think that in this scenario the
>>> mechanism should be CSV rather than SPF, because CSV is vastly more
>>> efficient and less abusive of the DNS." - Tony Finch (dot @ dot at . at)
>>> "And less abusive of the forwarders." - Rand Wacker (of sendmail),
>>> concurring
>>> 
>>> With CSV, "the number of domain names to support is some orders of
>>> magnitude smaller than for SPF or Sender-ID." and other *important*
>>> arguments here 
>>> <http://www.imc.org/ietf-mxcomp/mail-archive/msg05012.html> - Dave
>>> Crocker, author of the seminal RFC 822, which in large part defined SMTP.
>>> 
>>> "_Let's_ reexamine previous decisions (such as the one against CSV,
>>> which could be reintegrated with a HELO scope)." - Stephane Bortzmeyer
>>> 
>>> CSV is a "promising proposal" - William Leibzon
>>> 
>>>   "Lets proceed with SPF Classic and/or Unified SPF." - Terry Fielder
>>> 
>>> "Sender ID and CSV ... may in fact turn out to be complementary." - Roy
>>> Badami
>>> 
>>> <SPF isn't more useful.> "When you add SRS in to the equation, SPF
>>> Classic essentially "degrades" in to CSV-like functionality. - Rand
>>> Wacker (Sendmail.com)
>>> 
>>> http://www.google.com/search?q=gmane+%22do+CSV+and+BATV%22 - John Levine
>>> (agree: David Woodhouse)
>>> 
>>> "I fully expect ESPs and ISPs to do CSV on their MTAs." "I am
>>> implementing ... CSV" " "I now agree that checking HELO can be very
>>> useful, as it satisfies the ESP->ISP whitelisting requirement nicely,
>>> and also has the benefit of making life easier for forwarders who would
>>> then be able to skip SRS." - Meng Weng Wong (!)
>>> 
>>> Let's "move forwards now with a unified syntax and storage" supporting
>>> HELO - Matt Sergeant (who writes spam filters for a living) here
>>> <http://www.imc.org/ietf-mxcomp/mail-archive/msg04512.html>
>>> 
>>> Oh, yes.... First Post! :)
>>> 
>>> 
>>> _______________________________________________
>>> ietf-clear mailing list
>>> ietf-clear at mipassoc.org
>>> http://mipassoc.org/mailman/listinfo/ietf-clear
>>> 
>> 
>> 





-- 
Carl Hutzler
Director, AntiSpam Operations
America Online Mail Operations
cdhutzler at aol.com
703.265.5521 work
703.915.6862 cell