[Meng Weng Wong]
| Do our new server must keep retrying all 550 delivery errors ?
| How we can separate valid 550 from SPF 550 ? Will be "Local Policy"
error
| message search okey (nothing about this in "Fail" error) ?
Interesting point. We can talk about allocating a new DSN
codepoint for SPF failures.
Additional problem - is it legal SPF 550 or becouse of cached outdated TXT
SPF, MX, A or "exists" record ?
How to determine ?
Do all MTAs must return SPF record (and all included sub-records !!) they
used in machine readable format ?
Is there any way to get version or last modification date/time of SPF record
in use that blocked us ?
| Or we must take such a change burden on ourself ?
It rather depends on the situation. If you have enough
warning of what will occur, you can lower TTLs yourself, and
add the new servers to the record ahead of time.
IMHO, It's will be hard to keep SPF records updated if our ISP will make any
changes.
It will requere us to update our records ASAP as information from ISP will
come or allow ISP to manage them for us.
Currently I see solution for this only by using "includes" on ISP SPF data
or something like "+a:Mail-Out.Odessa.Net/24" addresses.
BTW, This kind of "+a:address/mask" will requere our ISP to make
SPF-compatible changes in their zones :-(
Once they will change Mail-Out.Odessa.Net record - you can start to recieve
550 errors becouse of old subnet still used by you.
Wrong. Wrong :-(
| Can you document all requered steps how to change SPF records data for
| situations described above ?
The necessary adjustments should be self-evident to any
experienced DNS administrator.
Nice to have a HOWTO on spf.pobox.com for newbies or non-experienced DNS
administrators.
Or possibly recomend short TTL for SPF records.
| AFAIK, Nothing like this will happen for DomainKeys. Cached DNS values
will
| only benefit them - do not hurt in such a situations.
You can set up an analogous situation with "what if an
employee steals the private key and we need to change the
published public key in DNS, what is the best TTL for
employees who steal our private key?"
This is non-critical problem. Support for "550" retry requere changes in
server software.
While leaked private DomainKey will result in _short_ (a few TTLs = 3-4
days, at most 1-1,5 weeks as recomeded by RFC 1035 section 7.3) period of
forgery from a _few_ domains/emails.
Even more - DomainKeys are not entire domain keys, it can be possible (not
yet!!, only if regex will be allowed as granularity) to use different keys
for
a*(_at_)domain(_dot_)com , b*(_at_)domain(_dot_)com, c*(_at_)domain(_dot_)com
... etc
The same kind of forgery can occur if your employees (just one day before
retire (becouse of little salary :-)) will change all your DNS records to
"+all" (or even better "-all" :-)
They can contact a lot of servers and force this query data to be cached
with 1 week (or even more) TTL !
Nice additional security consideration ;-)
Summary for SPF - We can not rely on "unknown" and "fail" errors generated.
As well keeping SPF records updated for little ISPs or ISP clients result in
big administrative burden.
Spam is big administrative and time burden too - but all admins are lazy.
Also they annually use two weeks Hawaiian Vacation :-)
--
Andriy G. Tereshchenko
TAG Software
Odessa, Ukraine
http://www.24.odessa.ua