spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Useful SPF results

2006-12-05 15:00:31
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.


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?


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?

When you do a forward, you resend the message using the same MAIL FROM:
but a different RCPT TO:.  If the MTA that accepts the mail is unable to
make final delivery, it sends a DSN back to the MAIL FROM: address.  The
DSN will likely include the address you forwarded to, which the original
sender didn't previously know.


[Stuart Gathman]
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.

Tom is currently sends mail from one MTA claiming the return-path of
another because of perceived limitations in some of his recipients
MUA's.  It is a security oversight, though not an uncommon one, that
Raytheon even allows him to do that, but one that box67.com doesn't
mind.  At the same time, box67.com wants to control forgeries, so it
publishes SPF with a list of designated hosts.  box67.com can choose
between designating Raytheon's mail hosts as permitted or neutral to
permit box67 customers who want to send mail from Raytheon to do so.
Since raytheon.com has a SPF record, so you can either add
?include:raytheon.com or +include:raytheon.com to the box67.com SPF
record, which can then end in "-all".

The second way for box67.com to get the desired functionality is to
provide SMTP AUTH services over port 587.  If the network at Raytheon
permits this, users inside the network connects with the box67.com MSA
over port 587 and gives it their login credentials in order to submit a
message.  Since mail submissions over port 587 require login, most
networks don't bother to block outgoing connections, but they might.
For cases where the foreign network allows this, it is preferable
because you don't have to list the foreign MTA's in your SPF record and
there is no risk of the foreign domain forging your return-path.


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.

It seems pointless today, but remember this was published in 1982 when
many of us had secretaries who typed up and distributed our memos.
There are other uses for this field, even though MUA's generally don't
expose them for use.  You are allowed to have a list of people claim
authorship in the From: address, and if so, the single party who sends
the message puts their address in Sender:.  Some mailing lists use
Sender: to show they are sending the current message, which was authored
by the party in the From: address.  When there is a Sender: address,
Outlook displays it as:  From: <sender address> on behalf of <from
address>.  There are also Resent-From: and Resent-Sender: headers,
though most users and MUA's are unaware of them.



 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).

Eudora may well have that limitation, I don't know.  The real problem is
that return-path forgery is now a serious problem.  In order to curtail
it, organizations may have to explicitly list MTA's that can
legitimately use their return-path.  Not a free lunch, though it's
pretty cheap.


 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.

This is why setting up SMTP AUTH over port 587 is attractive.  The
remote user submits mail directly to your MSA, and they can have MAIL
FROM: and From: be the same.  You decide which users have submission
rights and you verify their login credentials on each submission (it's
also a good way to prevent one customer from claiming the email address
of another).  If you do this, there is no need to include foreign MTA's
in your SPF record.

--
Seth Goodman

-------
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