Let me modify and reposition my previous suggestion: I would suggest
that whitelists are a better solution to handling forwarding than SRS.
As a user, I would like to be able to have a ~/.trusted-forwarders file
such as:
user(_at_)forwarder(_dot_)com
@my_employer.com
include:trusted-forwarders.org
include:good_friend(_at_)isp(_dot_)com
include:~myfriend/group-trusted-forwarder-list
options:-all
Let's assume that every machine can magically know whether any
particular domain fully supports ORCPT in incoming and outgoing emails.
Let's also assume that we've figured out a really great way for domains
to publish the information alluded to in the "include:" lines above, so
that people could include other domains' or email addresses' published
trusted-forwarder lists.
With those assumptions, then my machine can know for each line whether:
o It can accept forwards from "user(_at_)forwarder(_dot_)com" just
as I requested. (This would be possible if both
forwarder.com uses ORCPT all the time and so do we), or whether
o It must instead accept forwards from anyone @forwarder.com
instead of "user(_at_)forwarder(_dot_)com", because either forwarder.com
doesn't use ORCPT all the time or we don't use ORCPT all the time.
If this were an ISP, it could obviously set up a spiffy web interface
showing for each line, which was the case, so users would know how
closely their settings could be implemented. (They would also know
which forwarders of theirs supported ORCPT, and could put some pressure
on them to change.)
So with this information from a ~/.trusted-forwarders file, (or the
equivalent from a spiffy web page), a domain testing incoming emails for
against SPF and recipient-forwarding preferences could:
1. First test the message according to the MAIL FROM value.
2. Then test the message according to:
1. Either the ORCPT value if one exists, or
2. Every SPF record of every domain listed in the expanded
~/.trusted-forwarders file, from which connections
won't use ORCPT.
3. The action we take (accept-or-reject the email), is based
on the most optimistic of all the answers.
To me this would still seem to be a better system than SRS.
On some related issues:
1. One way to see whether various systems support ORCPT is to
add an SPF flag modifier in which they can claim such, such
as "flags", or perhaps just "f".
"flags=abABa2A2" Could mean that this machine
supports a, b, A, B, a2, and A2, (whatever this means.)
We could have flags that specify ORCPT support.
2. An option like "-all" in the trusted-forwarders file could
specify that you want to rewrite any ending "*all" as "-all"
for the purpose of the forward whitelist tests.
I imagine people would tend to want to specify this.
For instance, even though pobox.com's spf record currently
ends in "?all", I personally would feel safe in evaluating
that as if it ended in "-all" for my forwards through pobox,
because if I had a pobox account, well, I would know that
all mail forwarded through my pobox account would have gone
through pobox itself.
3. I recognize that some MTAs may never support DSN, and thus
may never support ORCPT, (which is only a small part of the DSN
standard.
So is it possible to get MTAs to support ORCPT without them having
to commit to supporting all of DSN? (Be prepared for an audacious
suggestion here...)
I also recognize that usually suggesting an SMTP extension
can take quite a while--to get to full RFC status.
But what about a very limited extension, say an extension
"ORCPT" that overlaps with RFC3461's ORCPT? This could
probably even be a one-page RFC.
Then MTAs whose authors who don't want to support the full DSN
can still support ORCPT, which is already well defined elsewhere.
In the meantime nothing really technically limits MTA's from
implementing an unofficial "XORCPT" extension that also provides
"ORCPT" functionality. (Having an X-extension provide a non-X thing
is not technically kosher, but given that the non-X thing is
already defined elsewhere, I doubt that there would be too much
outcry.)
Use of ORCPT only improves this sort of whitelisting, and without
ORCPT, we're still no worse off than SRS, so I don't see why it
would be too bad if it really took a couple years to get a one-page
and limited RFC like this through.
Any comments?
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com