> Hi !!
>
> > I read the SPF proposal, and the first question I had for implementation
was,
> > how to handle classless IP blocks (e.g. /29), other than the painful
method of
> > an entry for each IP. I imagine there is some clever way, similar to how
> > delegation of such blocks is *supposed* to be done... (*small strangled
noises
> > suppressing off-topic rant*).
>
> No idea, at the end you only have to publish one ip for every outgoing
> smtp server you have, publishing all your ip addresses is not a good
> idea.
Nope, as I read it, I would be required to publish data for EVERY IP I
CONTROL, even if just to specify "deny" for all but one or two of them.
Perhaps the draft needs tweaking?
> > (2) It is a bit of work to implement.
>
> have you make a checklistof thing to be done to have spf running at
> your site ? how many minutes is a bit of work ? I thing I'm not wrong
> if I say that it will take you less time than the time you have spent
> writing this messages.
I am not talking about the time required to add DNS entries to publish SPF
data. I am talking about the time required to develop/test/implement/maintain
any filtering based on SPF data, made particularly difficult in the near term
by the non-global, time-varying, and unpredicatable nature of SPF data
availability.
>
> > (3) It's essentially useless until it becomes
> > globally implemented.
>
> well, it will not hurt. Now supose that hotmail starts using it, if
> you do SPF checks you will be able to detect LOTS of spams that use
> hotmail forged addresses (I have a ACL that does something similar
> and it catches lots of spam).
But Hotmail has NOT started using it, have they? And they are not likely to
before the SPF concept has been accepted as an approved RFC.
>
> > But seriously, the real problem is convincing admins to do the extra work,
>
> did you received anytime LOTS of bounces due to somebody using your
> email address ? did you received LOTS of wirus warnings due to some
> virus using your email address ?
Nope. Although I understand the problem for larger outfits.
> how many spam do you receive comming
> from forged email addresses ?
Probably 99% of the spam I receive, although I have not actually checked.
> which is the cost of all of them both
> in bandwith and resources ?
Not much, but only because I am a small outfit. ;)
> How many time will take you to implement
> SPF onyour site if you have an easy way to add support for it to
> your smtp server ?
Ah, there's the rub, eh? Just how easy is it, right now? Even though Exim
has nifty ACL's and such, I would still have to spend time to establish
policies for exactly how to use SPF data, translate those policies into
software rules, and those policies would necessarily have to change over time
during the expansion phase of SPF acceptance. I would be signing on for an
unknown amount of maintenance. eeek!
> It's very easy to find lots of reasons
> to use SPF ...
Sure it is. I'm not saying it's a bad idea, I am simply pointing out how
difficult it will be to get to a useful level of implementation.
>
> > long before any actual value is added as a result. Sure, I could publish
SPF
> > data fairly easily; but, I can't *use* SPF data until almost *everyone*
does.
>
> I'm sure adoption of spf, dmp or similar solutions it's only a matter
> of time, little time. Big isp's have big problems due to bounces
> generated
> by the use of forged addresses, so they are the first interested on
> having a solution to this problem. There are also a lot of companies
> who don't like the posibility that anybody could use their email
> addresses to send faked email.
Oh, I agree that something is probably going to happen. I am not convinced
(yet) it will be SPF. Why publish extra data that few will use, in a format
that is likely to change before the community agrees on the solution... ? At
the very least, I need to wait until the final RFC is approved.
>
> > It's a bit like asking people to contribute time or money
> > to a "good cause."
>
> It's a good cause, but it's a cause that costs little time and
> money and could save you bandwith, resources, time and money.
It costs more than zero, and saves me ZERO until it is widely accepted. I am
not saying I would never do it. I am saying, I am not going to do it *now*.
> Protecting
> your users it's also your work and having a way to prevent unathorized
> use of their email addresses is a thing they will be pleased to have.
I agree whole-heartedly. And when the community agrees on the solution, I
will be happy to implement it.
>
> > You might get a fair number of participants, but you won't get everyone.
You
> > probably won't even get a majority.
>
> well, maybe, but there is no way to known it without trying first.
> By now you will have spf support in SpamAssassin 2.70 , this will make
> things easier to admins.
That's cool. Please understand, I am not trying to kill the idea. I LIKE the
idea. I just can't justify jumping on the bandwagon yet.
To put it simply, I am not going to publish SPF data until it is a confirmed,
published, accepted RFC, not just a draft; and then, not until some big
players have signed on, making it actually useful to me, and indicating that
SPF has been selected as the "best practice solution" to the problem. I don't
think that's at all unreasonable for a small outfit like mine.
Kind Regards,
Jim Roberts
Punster Productions, Inc.
