Re: Re: SPF Filter Questions2005-08-22 07:21:15
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.
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_)churchWell, 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