RE: [spf-discuss] Setting up a forwarding service

At 03:57 PM 12/5/2006 -0600, Seth Goodman wrote:

> David MacQuigg wrote on Tuesday, December 05, 2006 2:29 PM -0600:
>
> > I'll try not to use the word "send" where precision matters.
> > box67.com transmits no mail, and it doesn't authorize anyone
> > to transmit on its behalf.
>
> The SPF records, from your earlier post,
>
> > Here are two of my domains:
> > open-mail.org.          86400   IN      TXT
> >     "v=spf1 +a include:controlledmail.com -all"
> > box67.com.              1800    IN      TXT
> >     "v=spf1 include:open-mail.org ?all"
>
>
> along with the SPF record for controlledmail.com,
>
>   "v=spf1 redirect=_spf.controlledmail.com"
>
>
> and the SPF record for _spf.controlledmail.com,
>
>   "v=spf1 ip4:72.81.252.18 ip4:72.81.252.19 ip4:70.91.79.100 -all"
>
>
> say that box67.com authorizes the host named open-mail.org, and all the
> hosts listed by IP in _spf.controlledmail.com, as permitted to send mail
> using the return-path domain box67.com.  The domain box67.com may not
> actually inject any mail into the internet mail stream, but the SPF
> record lists hosts it authorizes to do so.
The word "inject" is a little vague, but from this context I assume it 
would include both an original transmission and a forwarding.  For this 
discussion, we need a distinction between those two actions.
If any transmitter says 'HELO this is box67.com', REJECT that connection 
immediately!  Box67.com cannot express that policy in an SPF record without 
blocking use of the name in a Return Address, and we are not sure yet if we 
can enforce -all on the Return Address, although I'm starting to lean in 
that direction after hearing more about how rare the Eudora Reply/Return 
problem is.
See the thread Misuse of Return Address for further discussion of this topic.

> > I use the word "transmit" to mean sending across the Internet to
> > unrelated parties, not internal delivery within an Administrative
> > Domain.  For the purpose of forwarding mail to our clients'
> > designated private mail storage addresses, we become part of an
> > Administrative Domain set up by the recipient. The recipient
> > should have his mail storage agent whitelist his forwarded mail.
>
> I am still confused on this.  Does that administrative domain have an MX
> that accepts mail from the internet?  If not, and all mail forwards are
> via trusted internal transfer, why do they have to whitelist you?
*** Administrative Domain ***
This is a term in Dave Crocker's Internet Mail Architecture document.  It 
is not associated with any particular domain name.  When tdonovan(_at_)box67(_dot_)com 
sets up forwarding to her private mailstore address at pobox.com, the 
Administrative Domain includes all servers on the path from the box67.com 
Border MTA to the final mailstore at pobox.com.  In theory, they are all 
agents of Ms. Donovan.
*** Whitelisting at the destination should be the Recipient's call, but 
unfortunately communications aren't that good within some Administrative 
Domains, particularly those involving a large ISP that doesn't support 
SPF.  The two ISPs where we have had some difficulty ensuring delivery are 
pushing different methods, which we have not yet implemented.  We currently 
provide CSV and SPF, SID and DKIM are on our ToDo list.
Even with those ISPs that don't support SPF, it may be helpful to list our 
own transmitters in our SPF record.  They probably quietly take a peek when 
they are deciding if they should include us in their private database of 
reputable senders.
I could have left out the include:open-mail.org from the record above, but 
at least it is a harmless positive statement about our own 
transmitters.  We will accept responsibility if anything does get sent from 
those transmitters under our name.
*** Notes on experiences in dealing with uncooperative ISPs ***
If one of our recipients has a completely uncooperative ISP, we recommend 
that they set up a mailstore account at any one of many other widely 
available ESPs (Email Service Providers).  Most have accepted our mail 
without question.  Yahoo.com made us jump through some hoops, but we 
finally got our mail accepted.  I have a recent report of missing mail from 
one of our hotmail.com recipients, but have not yet tracked that down.
As a last resort, if an ISP is uncooperative and our Recipient doesn't want 
to move his mailstore, we could relay his mail through another ESP with 
more "clout".  Mail to tdonovan(_at_)box67(_dot_)com could go to pobox.com, and from 
there be forwarded to hotmail.com.
-- Dave

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?list_id=735