spf-discuss
[Top] [All Lists]

Re: The problems with SPF

2005-08-26 12:19:16
On Fri, 26 Aug 2005, Hector Santos wrote:

How will a SPF ready ISP/MSA handle an authorized USER using an alias name
(non-ISP related domain)?

You don't mention whether you are talking about sender or receiver, so
I'll address both.

Receiver:

Easy, just don't check SPF for the forwarder.  Easy, provided said authorized
user tells you about it, that is.  To be ready to reject on SPF, an ISP
must:

  1) provide a way for users to list aliases (forwarders)
  2) make reject on SPF opt-in, so users who won't or can't do that
     don't get their mail rejected.

Sender:

It is a receiver issue, and the sender shouldn't (and indeed cannot)
do anything about aliases potential receivers may or may not have created.

The only proposed solution I've seen for this is SUBMITTER and hence, both
the SENDER, the MIDDLE WARE, and the RECEIVER must be compliant.

There are several proposals (e.g. SRS) to make listing forwarders
easier for receivers.  They all, in effect, make the forwarder say,
"I am a forwarder" so that the receiver doesn't need to explicity list
them.  None of the solutions addresses the problem of unauthorized forwarding,
so you might as well just list the authorized ones and be done with it.
SRS is useful for blocking forged bounces.  I thought SUBMITTER was
for Sender ID?  For introducing an RFC2822 header at SMTP time?

So if SPF has forwarding and alias problems, it is because the SPF protocol
failed to address it properly. 

The SPF protocol addresses a way to publish the sender policy.  Forwarding and
alias problems are part of a receiver policy.  If anything tried to
standardize it, it would be an independent proposal.  Methods
for SPF receivers to handle forwarders and aliases do not need to
be published - and hence there is no need for a "protocol".

An example of a receiver policy "protocol" might be some kind of
"no soliciting" policy published via DNS.  But to be useful, a
receiver policy needs to be able to "punish" senders that violate
their policy - hence the need for sender forgery prevention.

-- 
              Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


<Prev in Thread] Current Thread [Next in Thread>