Re: [spf-discuss] Useful SPF results

At 12:44 PM 12/5/2006 -0500, you wrote:

> On Tue, 5 Dec 2006, David MacQuigg wrote:
>
> > The problem as I see it is that SPF is not applicable in situations where
> > the Return Address is legitimately unrelated to the Transmitter's IP
> > Address, and senders must use the Return Address because their stupid 
> email
> > programs don't make a distinction between the Reply Address and the Return
> > Address.
>
> You are perhaps thinking of roaming users?
No, these are stationary users with email accounts at their own companies, 
or at aol.com, cox.net, hotmail.com, msn.com, or yahoo.com to name the top 5.
> > Box67.com is a recipient's forwarding service.  It sends no mail at
> > all.  Our clients have public addresses like tdonovan(_at_)box67(_dot_)com, 
> (Go for
> > it, you spam harvesters!!)  Whatever mail comes to that address is
> > authenticated, rated, tagged and forwarded to the recipient's private
> > address at their *existing* email service.  The public address must appear
> > in either the Reply-To: header, or the envelope Return Address.  Email
> > programs like Eudora do not allow setting a Reply-To: address.
>
> box67.com *does* send mail.  It sends all the mail you are forwarding.
> You need to use SRS so that the final recipient can check SPF - *and*
> so that their *private* address (your words) doesn't leak in case of
> delivery error.
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.  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.  They are welcome to check the SPF record on 
our HELO name, whitelist our IP, whitelist mail to a specific recipient 
address, or use whatever method they find helpful.  We haven't gotten any 
requests for SRS, SID, or DKIM.
I don't understand the leakage worry.  Do you mean bounces to a fake Return 
Address?  How would you discover my private mail storage address?
> > As I understand it, the Reply-To address was introduced only recently, and
> > that is why everyone uses the Return Address for this function.  Also, the
> > relationship between the Reply-To Address and the Return Address is not
> > well defined.  We could insist that our clients use the Reply-To address,
> > and leave their Return Address as is, but I fear it will be a long time
> > before we see this flexibility universally available in all email programs.
>
> You are thinking of the Sender address.  Reply-To has been there since rfc822.
>
> Back to the roaming user.  They need to do one of two things:
>
> 1) (Preferred) Submit mail to their home server on port 587 using SMTP AUTH.
>    This requires configuring the mail client, and works well with carrying
>    a laptop or email capable PDA.  SSH, VPN, and webmail are other solutions
>    for submitting through the home system.
Good advice, but box67.com is not involved in that part of the 
process.  Tom at raytheon.com has to work with his mail admin, setting up 
whatever authentication is appropriate for their company.  When he puts 
box67.com in his Return Address (because his mail program offers no 
separate Reply-To), we can't be publishing an SPF record authorizing 
Raytheon's transmitters, and we certainly can't take responsibility for any 
spam from those transmitters.  The best we can do is ?all.
> 2) (The case you are thinking of.)  Being forced to use someone elses
>    email client, they need to set the Sender to the someone else whose
>    domain they are sending from.
I don't see a Sender field in either Eudora or Outlook.  Why is there a 
need for Sender, if we already have From, Reply-To, and the Return 
Address?  RFC-2822 says it is useful for secretaries, but this seems 
frivolous.  I think the boss could simply use a different Reply-To address, 
if he wants replies routed to his secretary.
>  2a) But the email client they are forced to use doesn't support Sender!
>      So they set From to the someone else, and set Reply-To to their
>      own domain.
In Eudora the From address is copied directly from the Return Address, and 
there is no Reply-To.  I don't see any way to set up different addresses 
for the Reply and the Return (bounce).
>  2b) But the email client they are forced to use copies Reply-To to the
>      return-path instead of From.  So they turn it around and put
>      someone elses domain in Reply-To and their own domain in From.
As long as there are two independent addresses we can play around with, 
this might work, but it is getting complicated, and we'll have to work with 
each recipient setting up their email program.
>  2c) ... At some point you just have to realize that Someone Else doesn't
>      have a functioning email client.  If you are a geek, you can always
>      use telnet (I've resorted to that on many occasions - fortunately
>      Windoze still includes telnet).
Ah, if only the world were all geeks.  Damn those customers!  How can they 
be so ignorant as to think Eudora is a functioning email program.  How can 
they be so stubborn as to not dump Eudora just so they can use our service!
The only time I needed to use telnet in the last three years was sending 
via a strange mail service in South Florida. :>)
-- 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