spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Misuse of Return Address

2006-12-07 18:03:00
David MacQuigg wrote on Thursday, December 07, 2006 1:20 AM -0600:

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.

Inject mail means you connect as SMTP client to an SMTP server and
attempt to transfer a message to them.  Message originating and
forwarding are different from the system operator's perspective, but not
to SMTP and not to recipients.  The SMTP server you offer a message to
only knows that you want to hand them a message.  They neither know nor
care the origin of that message.  SPF arose from the desire to change
that in a way that SMTP servers could do lightweight validation of
sender domain prior to entering the DATA phase of SMTP.


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.

Recipients are recommended to check SPF against the HELO domain but not
required to do so.  You are correct that SPF v1 records do not have
scope, so anything you publish pertains to both HELO and MAIL FROM.
This works as desired in practice, as any host that you authorize to
send mail claiming your return-path will already have a hostname in your
domain, or a hostname in another domain and thus would not use your
domain in HELO.  The case it doesn't cover is the foreign MTA that you
permit to send mail with your return-path but not to use your HELO name.
That's not of great practical interest because if you trust an MTA
enough to emit mail with your return-path, you usually trust it not to
claim your HELO name and send forgeries.


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.

OK, these "transmitters" are ordinary outbound relays, and they do send
mail.  It doesn't matter whether these relays forward messages they
received from other MTA's or internal MSA's.  If you wish to help
recipient MTA's reject forgeries, you should publish an SPF record that
lists the hosts you authorize to emit mail with your domain in the
return-path.

In your example, the MTA's involved are Donovan's agents when they are
transferring her messages, but they transfer messages for many other
parties at the same time.  Though when receiving messages for Donovan,
the final destination MTA _should_ know who Donovan's forwarders are,
most mail systems do not allow end users to whitelist particular
senders, because that would require various methods depending on who it
is.  SPF makes it practical for end-users to whitelist their forwarder
by domain, but it remains to be seen if the big mail providers will
bother.


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

That is why many people regard the current practice of forwarding as
faulty.  A mailbox owner requests forwarding and the forwarding MTA
resends the message with a new RCPT TO address.  The new address can
either be the final destination mailbox or the beginning of another
forward.  If the message is ultimately undeliverable, the MTA that
accepted the message and is unable to make delivery sends a DSN to the
return-path address, who is properly confused because they successfully
delivered that message to a different address.  The present system
depends on senders who receive DSN's to figure out what went wrong with
their recipients private forwarding arrangements, and the recipients not
to mind if the DSN's disclose their private addresses or other
forwarding recipients.

This was a great convenience to forwarders and a problem for everyone
else.  As long as there are no malicious parties and no expectation of
recipient privacy, it works well enough.  In the present environment,
where there are more forgeries than legitimate messages, including
forged DSN's, the practice of one domain using the return-path of
another when forwarding frustrates recipients' desire for sender
authentication before DATA.


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.

If those MTA's send mail with your return-path, you need to list them as
"+" or "?".  If you trust them to not use your domain in forgeries, you
can designate them as "+" and SPF checking recipients should apply your
domain reputation in addition to that of the sending IP.  If you have a
good reputation and some of the recipient MTA's check SPF, you may be
able to convince them to whitelist you based on return-path domain when
they see SPF PASS.

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