Re: Re: SPF Filter Questions

Hello All,

I think I should clarify a few things about what I am doing. We
provide a web-based database that the church uses to enter all their
information. I don't do anything other than provide them with
the service. The church enters all the names, addresses and
email information etc... The church will then create groups of people
that they will want to email and writes the email using our system
and then presses send. At no point do I have any interaction with
this entire process. The ASP model bypasses the MTA and the ISP.

The church might have 20 different users that can access the
database and each user might want the replies to an email to be
sent to a different address. I would say very few emails are done
this way right now. However, I think most applications are going
to move to an ASP style and are going to allow Emails to be sent
in a similar way. Since I'm not an expert on email I won't even
try to propose a solution.

I appreciate all the input everyone has offered on this topic.

Thanks,

Bill G

Seth Goodman wrote:

From: Frank Ellermann [mailto:nobody(_at_)xyzzy(_dot_)claranet(_dot_)de]
Sent: Friday, August 19, 2005 12:55 AM


<...>

   From: user(_at_)church(_dot_)example, bishop(_at_)church(_dot_)example
   Return-Path: verify(_at_)bills(_dot_)service(_dot_)example

...then I'm lost what Bill is supposed to do.  With more than
one From-address he MUST supply a single Sender, because the
Internet standards say so.  The obvious solution would be...

   From: user(_at_)church(_dot_)example, bishop(_at_)church(_dot_)example
   Return-Path: verify(_at_)bills(_dot_)service(_dot_)example
   Sender: user(_at_)church(_dot_)example

...if both user@ and bishop@ are interested in replies.  But
maybe bishop@ is a busy woman, resultig in...

   From: user(_at_)church(_dot_)example, bishop(_at_)church(_dot_)example
   Return-Path: verify(_at_)bills(_dot_)service(_dot_)example
   Sender: user(_at_)church(_dot_)example
   Reply-To: user(_at_)church(_dot_)example

That is what the Internet standards say, TTBOMK.  But those
misguided entities want to force non-voluntary users, here
bishop@ and user@, to partcipate in an IESG mail experiment,
where the only solution is...

   From: user(_at_)church(_dot_)example, bishop(_at_)church(_dot_)example
   Return-Path: verify(_at_)bills(_dot_)service(_dot_)example
   Sender: verify(_at_)bills(_dot_)service(_dot_)example
   Reply-To: user(_at_)church(_dot_)example

The Reply-To is optional.  The Sender is incorrect as far as
mail standards are concerned, the real Sender was user(_at_)church


Well, I don't agree with the last statement.  See below.  As for the
apparent conflict between multiple From: identities and the message
originator not being one of them, it is no different from the secretary case
with multiple original authors listed.

   Return-path: secretary(_at_)example(_dot_)com
   From: boss1(_at_)example(_dot_)com, boss2(_at_)example(_dot_)com
   Sender: secretary(_at_)example(_dot_)com

This is what I believe the standards say to do, and it's no different from
Bill's case.

The mail standards are independent of SMTP, and it's nobody's
business (in the SMTP-world) how Bill's service got this
mail, UUCP, avian carrier, Fido, SMS, IM, or what else.  The
real sender is user(_at_)church(_dot_)


The real author certainly is user(_at_)church, but in this case, they did not
send the message.  As I understand it, they hired Bill to distribute it to
multiple copies on their behalf.

Bill only injected it into SMTP, because in a strict sense
his service is a church-to-smtp gateway.  He's not the sender
of the mail, he's only responsible for the SMTP injection.


Calling Bill a gateway is not correct, as user(_at_)church did not submit a
specific message to Bill for relay to another transport system.  If all Bill
runs is a church to SMTP relay, then it is inappropriate to list Bill in
anything but a Received: header.  If he were just a gateway, whoever
submitted the message to Bill should be the return-path.  From what I can
tell, Bill injected the message into the internet message stream on behalf
of someone else at their request.  That makes him the originator and he
properly identifies the actual authors.

I don't see how Bill's role is any different from the secretary case.
Someone said to Bill, "Draft a memo saying <blah blah blah> and send it out
to <recipient list> on my behalf".  That's neither gatewaying nor relaying,
it is message origination on behalf of another party.  In this sense, it
matters a great deal how Bill got the message.  Otherwise, how do you
determine what is a relay vs. the secretary case?  The secretary is actually
performing as a relay, but the relay is verbal!

As we discussed before, and I thought we were in agreement on, the
return-path has two concurrent meanings: 1) the address to send messages
concerning delivery problems ("bounces-to"), and 2) the party who originates
the message ("originator").  I think we have to accept both roles, as the
collection of citations from standards and proposed standards that we both
produced seemed to use both when describing return-path.

Originator does not mean author, just as the mailing list is the originator,
but not author, and the secretary is originator, but not author.  When
Sender: is described, apart from the requirement to use it when there are
multiple From: addresses, it appears to be consistent with the "originator"
role of return-path.  This was the basis of my argument that when From: is
different than return-path, Sender: should be set to return-path.  I assumed
that return-path is the real originator, as the standards say it is, and
therefore should be listed in Sender: when it is not in From:.  You appear
to be arguing that return-path only means "bounces-to" and not "originator".
I can't buy that, given how many places the standards refer to return-path
in the "originator" context.

If an openspf Web page says something else it is incorrect.


I have a lot of respect for your opinion, though I disagree.

If an IESG experiment says something else it is unethical.


Better to avoid this kind of statement.


--

Seth Goodman