Stuart D. Gathman wrote:
It is worth taking note of what big ESP customers expect (at least
from my conversations). They expect their ESP account to act like a
mail store ("where I check my mail"). They expect to be to register/purchase
email addresses that end up in their "mail store" when sent to.
They do *not* expect to have to keep track of all their email addresses
(i.e. forwarders in most cases). Computers are supposed to keep track of stuff
for them.
That's exactly what FF provides. In return for being whitelisted, a
forwarder gives the recipient credentials for accessing the relevant
record in its local forwarding database. Accessing the database through a
web service delivers any relevant information about the forwarding recipe.
In addition, it recursively delivers a list of credentials for any
forwarders one hop apart along that reverse path.
By credentials, I mean both the user/password pair and the url where they
may be applied.
A forwarding recipe may contain any data and flags. Any privacy concern is
assumed to concern hiding info to upstream senders: downstream recipients
are regarded as the owners of that data.
When I try to explain "forwarding", they want to know where
they can see the list of all their email addresses. The suggestion
that they should have to keep track of the list in order for email to work
properly is met with disbelief. This is a pretty reasonable set of end-user
expectations, actually.
I agree, and consider those expectations a chance to fix forwarding.
Especially if forwarders publish SPF records for the forwarded domains
(receivers can validate an alias forwarder by comparing the IP against the SPF
records of valid forwarded domains for that recipient - a technique I've
called checking the "pretend domain").
While that is a possible solution, I don't 100% agree that changing the
envelope sender perfectly suits all cases. If a forwarder can be
whitelisted, in many cases the original envelope sender can be fine.
I'm not sure how such a "list of all my email addresses" would get
transferred when a customer decides to switch ESPs.
If both ESPs support FF, writing a recipe to forward from the older to the
newer ESP is the first occasion for the older to ask the newer for an
authorization to be whitelisted. An additional occasion will be presented
whenever an actual message is being forwarded. If that authorization is
eventually granted, accessing the older ESP's list will be possible by
means of the exchanged credentials.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=93720238-6223c8
Powered by Listbox: http://www.listbox.com