From: Bill IconSystemsNetwork.com
[mailto:bill(_at_)iconsystemsnetwork(_dot_)com]
Sent: Monday, August 22, 2005 9:21 AM
<...>
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.
Well, the outgoing mail has to go through someone's MTA to get into the SMTP
transport environment. My assumption is that they are using your MTA(s).
The other thing that's not clear to me is if you provide incoming mailboxes
to which portal users can direct bounces, or if they have to direct bounces
to mailboxes outside your system. Since this makes a great deal of
difference, I will lay out both cases below.
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.
Here's how I interpret your case and what I propose we should recommend to
people in similar circumstances. If I understand Bill's description
correctly, he has created a web portal for the use of the church that has
some special functionality beyond email. He makes a database available to
portal users (some subset of church members), and they can in turn send
emails via the portal to groups of other church members, whose addresses are
contained in the database. The bounces for each bulk mailing are directed
to a party specific to that mailing. Bill did not specify whether or not
these bounce addresses all use the church's domain name (or equivalently, a
sub-domain he created for them) or are foreign domains, so let's talk about
both cases.
From the email perspective, this appears to operate just like a webmail
application. The emails are authored and sent by portal users with no
involvement from Bill's service. Bill's only involvement is to provide them
with an application framework accessible via the web to do this. The
message author submits the message to Bill's application framework, which
just like webmail, functions as a straight MSA. It should therefore behave
exactly as a webmail interface, which I suggest means the following:
1) Each return-path obviously has to be the role account or individual who
deals with bounces for that message. From the standpoint of SPF, this is
the identity we validate so this is our main concern. It can operate in
several ways, depending on the nature of the bounce addresses. Here are
some options.
a) All the return-path addresses use the church domain name, or a sub-domain
that Bill sets up on their behalf (church.BillsAsp.com). To make all
outgoing portal mail SPF compliant, the church adds Bill's outgoing MTA(s)
to their domain SPF record, or if a sub-domain belonging to Bill, he adds it
to his SPF record. There are two sub-cases of this.
i) The church already has an email system for their domain elsewhere. In
this case, any bounces would bypass Bill's MTA(s) and go directly to the
church's MX.
ii) The church does not have an email system for their domain. In this
case, if he hasn't already, Bill could provide full webmail functionality
and be the MX for the church domain (or his sub-domain) email. Each portal
user gets an account where the domain of their mailbox address is the church
domain. Like any other webmail system, individual users could set up
forwarding to suit their needs. Bill then has to decide how to do the
forwards. He can do "normal" 822 (relay) forwarding (no change to
return-path or originator headers) or use SRS (rewrite the return-path on
outgoing forwards - IMHO, RFC non-complaint behavior).
b) Some or all of the return-paths use domains other than the church's.
Assuming the bulk mailings use Bill's MTA(s), in order to make messages
leaving the portal SPF compliant, each of these foreign domains would have
to add Bill's MTA(s) to their SPF record. IF they wish, they can use macros
to limit this use to specific local-parts. For any foreign domain that is
an ISP domain, this is impractical. Even if none of the foreign domains
were an ISP, it would be a minor miracle (of course, this is the church) to
get twenty separate domain owners to add Bill's MTA(s) to their SPF records
for the benefit of one user in each domain. It therefore appears
impractical to allow multiple foreign domains as return-paths and expect
that all outgoing mail will pass SPF at the recipient. Like any other
webmail system, it works best if the return-paths all use a common domain
that either Bill or the church has control over, as in a) above.
2) The From: field on outgoing mail should be the message author(s), or the
party or parties on whose behalf the content is provided.
3) If there is more than one author, there MUST be a Sender: header. If a
party not listed in From: submits the message, there SHOULD be a Sender:
header. In both cases, Sender: is the mailbox of the party who submits the
message. It is arguably a best practice to always do this, even though it
is just a SHOULD in one case, and I suggest we recommend it as such.
[As an aside, it appears that 2822 only mentions Sender: in connection with
an original submission. I wish they would state that categorically, if
that's the intent. Remailing by a user, as opposed to encapsulation
forwarding (creating a new message), exclusively uses the Resent-*: fields
in this newer proposed standard. This is at odds with what has become a
defacto standard for mailing lists to put the list owner in Sender:, even
though 821/2821 clearly define mailing lists as operating on a
redistribution model. One important failing of 2822, IMHO, is that while
2821 carefully specifies how mailing lists set return-paths and retains
From:, 2822 is silent on how to set the other headers. One may infer that
since this is re-injection of a received message, mailing lists should use
Resent-from: instead of Sender:. However, 2822 does not explicitly say that
and we are left to guess. Neither does it deal with the fact that using
Sender: for this has become very common nor does it declare if this practice
is recommended or not recommended in the future. We may each have our own
opinions on the matter, but the document does not express one that I can
find. I hope they tie this up before it becomes a full standard and
formally replaces the others. It is too important a use case to leave
dangling. They should, IMHO, either deprecate the current practice, which
will take a long time, or standardize it as an exception to the other uses
of Sender:.]
4) Bill's domain only appears in Received: headers, as he is neither
involved with message submission nor resending.
5) If Bill wants to be a particularly good system administrator/netizen, and
also help maintain a good reputation for the church's domain, he will
enforce submission rights. That is, a user logs into the portal and
authenticates them self. Bill's application framework does not allow that
user to claim to be another portal user (for 2822 addresses), nor use any
other address not previously registered in the system for that user.
The simplest local policy, and the one that avoids any possibility of abuse,
is to set the return-path to the user's authenticated address. If Bill
wants to be slightly more permissive, and the church agrees, he can allow
any authenticated user to use any other valid mailbox in the church domain
as return-path. While this is not a suitable policy for an ISP, where the
domain name is used by lots of people who have no relationship with each
other, it _may_ make sense for a small organization. If the church wants it
that way, it's their domain.
As a separate issue, if Bill is forced (by his customer) to allow foreign
domains as return-paths, he can still easily perform some "due diligence"
without maintaining a database of who can use what foreign address. Bill
can do this with an SPF check before accepting a submitted message. He
checks the claimed return-path against any of his MTA's. If it generates an
SPF pass, he accepts the submission. If it generates an SPF fail, he
rejects the submission. For other SPF results, he has a difficult choice,
but he puts the reputation of his MTA(s) at risk if he accepts anything
other than a pass. Even if he only accepts submissions claiming foreign
domains that give an SPF pass, there is still potential for abuse. However,
one can argue this is permissible since it conforms to the published sender
policy of the claimed domain. I don't like that assertion, but reasonable
people can disagree on this. My suggestion is KISS, and force the
return-path to be the user's authenticated address. Simplest
implementation, no grey areas and zero possibility for abuse. That sounds
like a best practice recommendation to me.
--
Seth Goodman