Re: What to do about redirect= and NXDOMAIN?

Commerco WebMaster wrote:

> Bill,
>
> At 06:35 PM 5/20/2005, you wrote:
>
> > Commerco WebMaster wrote:
> >
> > > [...]
> > >
> > > While the above is how we tend to implement here, I am fairly sure 
> > > that the spec is a bit more flexible, in that the redirect could be 
> > > pointed outside one's domain zone, however, I don't immediately see 
> > > cases where that should be done.
> > > [...]
> > >
> > > The other case I can think of is when a domain publisher has a local 
> > > SMTP MTA they wish to authorize for their domain (their local SPF 
> > > record covers this), and also uses their upline ISP's server as a 
> > > "smarthost" or fail over server (their include covers this through 
> > > their ISP's SPF record).
> >
> >
> > Actually, I do this now for hosted domains on a single MTA. I publish 
> > one SPF record on the server's domain and then redirect to that 
> > domain from all the hosted ones. For me, this also keeps the 
> > relationship clear regarding who owns the actual permission to send 
> > from that MTA, rather than distribute that amongst all the hosted 
> > domain SPF records.
>
> Interesting.  May I ask why you chose redirect as opposed to include 
> for the above scenario?
> [...]
>
> If I am understanding properly, as a domain holder, a customer in your 
> network might wish to use a primary and backup MTA which could be on 
> two domain networks (possibly both operated by your company).  Thus, 
> in your environment, I would think that include would allow more 
> flexibility for your customers.
> As always, I reserve the right to be completely wrong and to learn 
> from my errors.

Oh, my environment isn't that complex. I'm not a hosting company. I 
simply host multiple domains from my environment. Given that, I *know*  
that they will all use the same MTA, DNS, etc, etc and therefore felt 
redirect was a simpler and effective approach in my case.
For the situation that you describe, where a given customer might choose 
to leverage MTA's from different domains, I would wholeheartedly agree 
that include, or even a mixture of include and redirect, might be 
appropriate. I see this flexibility of SPF as an advantage, because it 
doesn't itself suggest one way of doing these kinds of implementations.
I will say that one thing that bothered me about using include in my own 
environment was how wishy-washy it seemed about reporting results when 
an error occurred. It seemed to say "well, this *might* be OK" even if a 
domain resolution problem occurred. But in this case I would rather get 
a TempError and have stuff show up in my logs as a problem. So while the 
basic semantics of include and redirect might have been equivalent in my 
case, I preferred redirect because I wanted something a little less 
wiggly when it came to catching real problems that might occur.
Bill