Hello all,
I am totally new to SPF (as of yesterday). And it really looks like a
great idea.
I agree about (not) examining things after DATA. I have been tinkering
with a mail server that likes to 500 SMTP connections before it gets
DATA - if it doesn't like it. I started this project back in February
and at that time put my own SMTP server together. It ran through 70,000
emails with promising results, but it was rather clunky and not
production quality. So I dumped it for a while. Anyhow, I found this
SMTP server written in PERL (qpsmtpd) over the weekend and added a
plugin to do the checks I was using before. Not only is it much better
it is much more reliable ;-)
Anyhow, one of the qpsmtpd people pointed me over to the SPF group
yesterday. I added SPF checks to my little plugin. Right now it is just
collecting data and I am looking at the stats. It has only done just
over 4,000 emails since it was born, and only 1,000 of those have the
extra SPF check data (since yesterday). It looks like only 10% of email
coming in has SPF available. Hopefully this will increase exponentially
with time.
I have some stats at http://emkwebdesign.com/mailstats.php if you are
interested. Basically it looks like some of the SPF - Fail get through
my checks. But the SPF - Pass are all good. I am seeing that a good
number of SPF - Pass are from bulk mailers. But I am thinking that SPF
is much more beneficial to protect domain usage than to block unwanted
email. But I guess these two are kind of hand-in-hand.
By the way, my XML vote (of course i am a newbie so it could easily be
discounted).
My opinion is that XML adds overhead and bloat in exchange for a
standard data storage/transmission. It is forgiving of "mismatched"
records, for example one day a new field/piece of data is introduced -
but it doesn't necessarily break the old client implementations. BUT I
think that the whole DNS standard will need to change (at least to a TCP
model, favor rsync over masters/slaves) before there is much benefit
realized. At that point the whole kit and kaboodle should probably be XML.
So my vote is not XML until DNS changes. But then you have some sys
admins that perceive DNS as a worrying puzzle that is easily broken when
things change. So that might be a rough ordeal.
Best Regards
Waitman Gobble
EMK Design
714 522 2528
Lou Katz wrote:
Opposed to XML.
Also, much more interested in tools to make decisions based on envelope
information and disinclined to examine anything after DATA.