Re: SPF I-D for review: draft-schlitt-spf-classic-00.txt

On Fri March 4 2005 10:50, wayne wrote:
> 
> In <[email protected]> Bruce Lilly <[email protected]> writes:

> > From my perspective (as a mobile
> > user (i.e. connecting via an unpredictable IP address) with need
> > to use only a few domain names) I'd phrase the issue as "being
> > able to use any IP address"; and that's where SPF utterly fails.
> 
> I don't believe that SPF utterly fails for roaming users.  There are
> many options for you to use.
> 
> For example, you can use SMTP AUTH over the SMTP submission port to
> always submit your email to an acceptable MSA instead of using your
> ISP's MTA.

Which MSA? operated by whom? Using AUTH based on what prearranged
information?

> Another option is to give neutral results on other IP addresses.  You
> can even do something like:
> 
>         v=spf1 mx -exists:%{ir}.xbl.spamhaus.org ?all

No, I can't, because I don't own my ISP's domain name (which
appears as the domain of my mailbox).
 
> you can use pretty aggressive DNSBLs with out fear of
> the domain's MTA being listed on the DNSBLs.

No, same reason as above.

> With more work, you can create specialized DNS servers and use the
> exists: mechanism to do some fancy things.  About a year ago, someone
> created a "rate limiting" DNS server, so you could do something like:

Again no and no; same reason.

> Similar techniques can be used check for a special token in the return
> path and allow email using it.

Most UAs set the SMTP return path using the sender's mailbox;
there's no "special token" there.

> One person was working on creating 
> something similar to SMTP-after-POP, which would authorize an IP
> address via a specialized DNS server after a POP.

Sending and retrieving are separate operations; many ISPs
provide separate servers.  Moreover, it is sometimes necessary
to send mail w/o using the ISP's SMTP relay, for example to
work around temporary DNS botches [which is why blocking port
25 is unreasonable].
 
> All of these techniques have been known/discussed for well over a
> year.  

And (as has also been discussed/is well known) none of them
are applicable in the vast majority of cases (i.e. in general).