spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Misuse of Return Address

2006-12-07 13:56:52
David MacQuigg wrote on Thursday, December 07, 2006 2:03 AM -0600:

Whoa!! We're getting way too broad with the definition of "inject".  I
guess it now includes allowing a forwarder to use box67.com in a
Return Address.

SMTP unfortunately does not differentiate between originators and
forwarders.  If you connect as SMTP client to a SMTP server over the
internet, you are injecting mail.  The SMTP server cannot distinguish
between messages the client originate and messages it forwards.  The
SMTP server holds the SMTP client responsible for all of it.


"Allowing" includes not publishing an SPF record at all
(same as ?all).  So is box67.com responsible for the mail it
"injects" if there is no SPF record?

Responsibility for what you send predates SPF.  If you transfer spam
and/or forgeries to hosts via the internet, it is reasonable to expect
that your IP will end up on local or public blacklists.  If you inject
spam from more than one IP, you may find your netblock or ASN
blacklisted.  This was the case before SPF and there is no reason to
expect that will change.  We can say that senders are responsible for
their outflow only because recipients hold them accountable.


How about a domain that has only a website, and is not even
involved in email.  Is it responsible for the mail it "injects"?

If it transfers no mail to another SMTP server (sends or injects no
mail), then there is nothing to be responsible for.  The only thing SPF
adds in this case is the ability for that domain to publish the fact
that it sends no mail.  Recipients will then know that anything claiming
that domain in the return-path is a forgery.  If the domain wants to
assist recipients rejecting forgeries, a domain can publish the fact
that it sends no mail with the SPF record, "v=spf1 -all".


I prefer the terms transmit and forward.  The parties responsible (in
our system) are the operators of those transmitters, and the owners of
domains in the HELO name that specifically authorize those actions.
We
don't take ?all as an authorization for HELO, but any transmitters
that
are specifically listed in an SPF record are authorized.  We ask our
clients with SPF records to limit their creativity, and just use a:,
mx:,
and ip4: terms for their own transmitters, and include: for any
forwarders.

You are trying to differentiate between originating MTA's and
forwarders, which are the same in SMTP.  Many people on this list have
made excellent arguments as to why they _should_ operate differently,
but we are stuck with 821/2821 as they are.

From your previous messages, it sounds like you ask your customers to
set their return-path to box67.com.  If so, they don't need to publish
anything in their domain SPF records.  The mail goes out from their MTA
but claims your domain, so that only involves your SPF record.  This is
why I suggested having your customers submit mail to your MSA directly
using SMTP AUTH.  You then take responsibility only for traffic leaving
MTA's under your control that you list in your SPF record.  This is the
most secure arrangement you can offer your customers.  If I've
misunderstood your setup, please explain further.


It is my understanding that ?all has the same effect on unauthorized
transmitters as not publishing an SPF record at all.  If it ends up
somehow counting against us, then we'll drop the SPF record entirely.
I'll try -all, but I can't promise I'll stick with it.

The SPF specification requires recipients to treat a neutral result the
same as the case of no SPF record.  Recipients are free to do anything
they wish, but there is no advantage for them to treat these two
differently.  In both cases, the recipient can't tell whether the
message actually comes from that domain or is a forgery, so they can't
sensibly apply the domain's reputation, good or bad.  The only sender
reputation it makes sense to apply is that of the sending IP.

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