On Wed, 2004-09-29 at 18:09, Carl Hutzler wrote:
On 9/29/04 5:52 PM, "James Couzens" <jcouzens(_at_)6o4(_dot_)ca> wrote:
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
How does AOL plan on acting upon messages based on HELO checks?
P.S. I wrote that functionality into qmail in about 10 minutes... I'm
curious just what AOL is doing differently that requires the 30 day
window given the trivial nature of such a check? Can you go into any
more detail?
Cheers,
James
I have proprietary MTAs, Development cycles, QA and installation that must
work well for about 90 million mailboxes.
It takes a little while longer :-)
I understand all of these things. I believe given my limited exposure
to conversation from you I took the 30 days to mean "30 days until we
have a working alpha or beta" whereas I can see it appears you mean
something worthy of production in which case 30 days is a rather noble
offering ;)
I'm still curious however if you can go into any detail as to how your
HELO checks will factor into the grand scheme of AOL filtering policies
as far as how much weight will be attributed to the result of such a
check given the vast number of clients which provide inaccurate,
invalid, or simply false HELO information.
For what its worth I am 100% in favour of AOL proceeding forward in this
direction, it would be fabulous if we could take a few more things
(*cough* PTR publishing *cough*) in place so as to facilitate superior
filtering technologies PRE-2822 style.
Cheers,
James
--
James Couzens,
Programmer
( ( (
((__)) __\|/__ __|-|__ '. ___ .'
(00) (o o) (0~0) ' (> <) '
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :
http://mipassoc.org/pipermail/ietf-clear/attachments/20041003/0bf879c2/attachment.bin