----- Original Message -----
From: "Jim Hill" <spf-0408(_at_)mx(_dot_)rdns(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, October 06, 2004 8:32 PM
Subject: Re: [spf-discuss] [SPF Classic] Privacy and disclosure of 2821 MAIL
FROM
Stephane in
<20041006205749(_dot_)GA3749(_at_)laperouse(_dot_)internatif(_dot_)org>:
The whole purpose of SPF is to check the "real" email address used for
the last introduction of the message. This can conflict with privacy
expectations, for instance for a roaming user.
I'm not clear what you're getting at. What privacy expectations
do roaming users have in the context of spf?
SPF or LMAP protocols in general core problems are:
- mail forwarding/routing issue, and
- The ISP user using an alias non-isp domain address.
The SPF2 usage or more specifically, the Microsoft SUBMITTER, PRA/SENDERID
logic is to expose the "real account" or responsible account when the
transaction domain no longer applies as a SPF domain.
So what you run against is the privacy issues with the exposure of
information such as the user's real ISP email account used for SUBMITTER in
the network transaction when in reality, it is not the user desires or
intent to expose this information. The two words "user intent" are very
powerful in the US ECPA privacy provisions.
One of the problems you have now with the suggested SPF deployment
recommendations is telling ISP's to create SPF records even if the ISP mail
server is not SPF ready.
The ISP users, legitimate and all, not spammers, are allowed to use alias
addresses. As long as the user machine is a ISP networked machine or the ISP
offers SMTP AUTH to login, the user is allowed to submit mail for relay
operations.
If it just so happens the user is sending mail to a target machine which
does have SPF server support, then the user's mail will be blocked because
the user's alias domain is not associated with the ISP MTA sender machine IP
address.
The User gets a bounce message and talks to ISP low or first level support
personnel. The user says this was working for the past 3-4 years! Never
had a problem. Since low level support has not been made aware the ISP
network engineer has added an SPF record, he doesn't know what happen or
what to tell the user.
The unsatisfied user request higher level support, maybe as high as 3-4
levels with no resolution because there is no ISP support guideline to talk
to the network engineer.
So unless someone is aware that SPF is the reason, the user is hosed now.
The above is a real event with Bellsouth and myself when Bellsouth added SPF
a few months ago. I was aware but the support levels did not anything about
it and didn't understand the reasons it was being rejected. I finally got
to a manager to explain the situation who finally talked to the network
engineer. I was called back and basically told:
"You can't use aliases anymore."
at which point, I tried to explain to them that they need to either add a
relaxed provision or upgrade their server to support SPF SUBMITTER or some
kind of mail from rearrange or whatever.
Response? "With the current spam situation, maybe aliases can't be used
anymore."
It went no where from there.
In any case, if they did have SUBMITTER or SENDERID support, then the SMTP
AUTH login account will be used and exposed in the transaction when the user
uses an alias.
How much of a problem that is? We really won't know until people realize
what's going to happen.
I personally believe that SUBMITTER should only be exposing the DOMAIN, not
the full address.
So it would look like this:
MAIL FROM: user(_at_)alias-domain(_dot_)com SUBMITTER=isp-domain.com
that is all that is technically needed for SPF ready downlinks. No need to
expose the user's ISP account.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office