On Thu, 2004-10-28 at 16:38 +0200, David wrote:
yes, but it needs big changes to dns server software and the
configuration of that software must be in sync with the mta
configuration. Altough this is feasible it adds extra complexity
No it doesn't. I finished the validation server and client earlier this
week to an alpha stage. I've got to finish integrating it into qmail
and Sendmail hopefully tomorrow or this weekend.
The validation server speaks both TCP and UDP and has all the right
hooks to make cryptographic conversation possible if such a thing proved
worthwhile.
The validation server can also run standalone, and anywhere on or off
your network it doesn't matter as long as its able to communicate with
the MTA.
The idea behind the DNS mods (which are the wrong way of going about it,
but I concede that there are those out there who don't mind the required
changes and are happy with that) is one based on logic that proof of
concept might result in official patches perhaps. Either way, the
validation server is exceptionally tight and small, easy to debug, move
around, and point the finger at. Adding code to a DNS server is a party
I'm not all that interested in attending but I salute the efforts of
Roger, Stuart and Tony (I think he's had something to do with the dns
related works too?). They've got the vision necessary to not only
recognize what we think is a great idea, but they've donated their time
to prove it.
I think this is false, addresses could be verified by other means, i.e
trying to deliver mail to that address (more mta's can use this callout
technique to verify the existence of an address). Callouts waste
more bandwidth than VRFY, so disabling VRFY you only force other
people to use callouts, which wastes more bandwith and more resources.
The SMTP callback is a fallback position which given the scope of any
migration operation as I'm sure you can see with SPF is pretty large,
and can be slow moving (SPF's deployment is the fastest moving new
technology I have EVER witnessed, its been an incredible ride).
You have to provide an option to deal not only with ignorant MTA's but
also those MTA's who can't or won't make use of SES until such time as
doing so is a necessity for them for one reason or another. The idea is
that its a last resort, and its expensive, but so what? It results in a
decreased volume of Spam. The cost of doing so in the worst case
scenario probably does better then break even (through the decrease in
spam, said cycles and BW can be attributed to the callbacks resulting in
no additional cost).
In any case there is a lot of people doing callout verifications for
every incoming email (we also do that) , and with some caching this
does not represent a great inconvenient.
We're open to input, and yours is appreciated. I think it is prudent
however that further discussion be taken to where it belongs, which is
on the SES list. Information is available @ http://ses.codeshare.ca
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
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part