> You need to publish one allow record for every ip that you authorize to
> send mail for your domain and ONE wilcard deny record that deny ANY ip
> on internet (not all of your ip's):
>
> 80.226.100.212.in-addr._smtp_client.mydomain.com TXT "spf=allow"
> *.in-addr._smtp_client.mydomain.com TXT "spf=deny"
If that's all, then very cool.
> > 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.
>
> right, spf is just a draft, from my point of view it needs to solve some
> problems in a better way, but the idea looks good, it's not perfect but
> could be easly implemented. Nevertheless, at the end some solution will
> become a RFC and enough data will start to become available.
I agree. I await the community's blessing of the method of choice.
>
> > 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
>
> when a ready to use solution will be available you don't need to stablish
> complex policies, spf will tell you when to reject or accept a message,
Oh good, someone else doing my thinking for me! ;)
> and
> the best thing about it is that it will be the senders domain administrator
> who will tell you from which hosts you can receive his email.
I like that part.
>
> > and those policies would necessarily have to change over time
> > during the expansion phase of SPF acceptance.
>
> no need to change.
I still have to decide what to do with "non-participants." Which would be an
ever-changing population...
>
> > I would be signing on for an
> > unknown amount of maintenance. eeek!
>
> well, it's your job, you are suposed to be paid for doing it and you are
> suposed to do your best to protect your users (just in the case it really
> take you some considerably amount of time, but that's not the case)
Oh, if only my employer (i.e. me) could afford to pay me what I'm worth! LOL
>
> > 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.
>
> well, when aol or microsoft or some big provider say 'we will only accept
> emails from spf protected systems' it will be quickly implemented.
Absolutely true. I await this event.
> Do you belive this will never happen ?
I don't not believe it could not never happen. (Sorry, you set me up for a
multiple-negative response, and I couldn't resist!) ;)
> > Oh, I agree that something is probably going to happen. I am not
convinced
> > (yet) it will be SPF.
>
> me too. maybe teos wins as it could give some economical bennefit to the
> companies that issue certificates, but i prefer dmp or 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.
>
> True, i'm not trying to convince anybody to adopt or publish spf right now.
> I just write an exim acl and publish spf data for my domains to start
testing
> spf, I take it like an exercise and give anybody else the choice to try it.
Very reasonable. It sure sounded like you were pushing us to implement it
right away. Sorry I mis-interpreted you.
>
> > 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*.
>
> nobody is asking to do it right now, i'm just giving some reasons to adopt
> spf (i should add - when it becomes a standard). In the meantime you could
do
> whatever you like.
If only that last statement were really true! (Pictures self on Caribbean
island with pina colada in hand...) ;)
Regards,
Jim Roberts
Punster Productions, Inc.
