----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, June 22, 2005 9:12 PM
Subject: Re: [spf-discuss] Problem with SID
In other words, a SPF compliant server should not be using a smart host
or
routing outbound mail that is not part of the sender's SPF network. He
needs to make sure that when it finally reaches the final destination
that
it is still part of the SPF network.
No. A sender is only responsible for the message until it leaves the
border MTA for the sending domain. After that, it is the receivers
responsibility.
Semantics. It implies the same thing; 6 of 1, half dozen of the other. :-)
MUA ---> MSA/MTA ---> MDA
There is responsibility for the sender (MTA which is part of the "sending
domain") to make sure the transaction would be correct for the final
destination would be compliant with the SPF network.
In other words, the transistion from MSA to MTA must maintain the IP::DOMAIN
SPF association for the network.
This is what I call transition points. All transition points (hops) in
a
SPF network must maintain the IP::DOMAIN SPF association.
There is only 1 transition point between 2 domains.
And 2 transition points between 3 domains....
If the receiver (or
sender) wishes to add another transition point (perhaps because they don't
have
administrative control or influence over some MTA which is using them for
an
MX but incorrectly checking SPF anyway), then they have to use something
like
SRS.
Or white list.
Have you considered heterogeneous systems?
The reality is that in this new era, during the initial period, there will
be companies who will explore a new system promising new "email protection"
and they will try to explore it by plugging into an existing network they
have already have an investment in. So throwing away the old system may not
be a desirable opton.
That is what happen to us when companies using other software switched over
to our software with it "great new sender authentication protocol" stuff.
We had one company using the Barracuda system as a one or more MX hosts and
used our WCSMTP/WCSAP system on other MX hosts.
Mail coming into a wcSMTP host was protected and they were really surprise
by the results.
So they began to route Barracuda inbound mail to WCSMTP and soon enough they
encountered the "forwarding problem" for incoming email domains with SPF
policies.
I told them basically this is like investing in an expensive home security
system with alarms and motion detection at each window, etc, but you still
leave the front door key under the porch potted plant.
They had to either put wcSMTP on all MX host, get Barracuda to support SPF
or accept the mail with white listing or use some other solutions we
suggested.
Anyway this will happen as people first explore SPF. Hopefully, they won't
get the wrong first impression but realize it is an all or nothing concept
in getting their network in order.
But all of the "forwarding problem" sob stories in spf-discuss I can
recall have been about attempting to check SPF for mail from your own
MX servers - an obvious misconfiguration. It is a case of "Doctor!
Doctor! It hurts when I do this!" Just say no to checking SPF on
your own MXes, and you won't need SRS.
I agree that the "forwarding problem" has been lumped as one issue to
address other issues too.
For example, the authorized ISP user usage of aliases addresses on a SPF
ready ISP system. Once the SPF ready MDA is reached, there is a
IP::DOMAIN mismatch with the 2821:MFROM check.
This is one of the example problems the SUBMITTER and PRA proposals are
suppose to address.
So its not just transition points, but ISP users using aliases addresses.
The same thing can happen when a MDA "RCPT TO" forwarding takes place. The
MDA receives a message for a specific user and the MDA host has a specific
setup for the user to forward or redirect the message to somewhere else.
Otherwise we have a forwarding problem.
If your MTA network is too complex to figure out how to configure SPF
(either
sending or receiving), then punt until it is cleaned up.
I agree. In my view, until a system is ready to support SPF with a hard
PASS or FAIL, it should not bother. I can understand and accept a temporary
relaxed policy (softfail, neutral) but it has to be a limted timeframe until
the network is SPF ready.
I had proposed in the pass that SPF include a expiration concept that a
receiver can use against a SPF domain that has been using ?ALL or ~all for
an extended period to the point that it finally being abused by SPF domain
spoofers.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com