This is the latest description of the tentative solution I assembled in my
mind after browsing old posts about TENBOX and more recent discussions.
Re-reading it, I see that it is not tightly coupled with SPF. However, it
fixes forwarding also for SPF concerns. Thus, it's not off topic for this
list. Actually, it may play a nice stereo effect with the latest TENBOX
draft. If we are still alive, that is.
The tentative solution provides for a local forwarding policy. It relies
upon a database keyed on <forwarder, envelope recipient> pairs; where
"forwarder" is either the IP address or its FQDN, provided it got an SPF
"pass". When a message is being forwarded (i.e. it already has a
Return-Path), a mailer should look up the policy in order to determine
what envelope sender replacement, if any, it should use.
Not replacing the envelope sender is fine if the mailer can be
authenticated and/or whitelisted by the target MTA. Such whitelisting is
granted on a per-recipient basis. The forwarder might use existing
extensions to authenticate, e.g. the AUTH parameter idea. Either the
mailer or the local policy interface implementation should be able to
determine if the target MTA supports this kind of authorization, even if
the current recipient has not been authorized yet. In the latter case the
current message should remain in the queue (or be rejected with a 4xx
response) until the required authorization is granted. If the target MTA
does not support this solution, messages may still be forwarded using an
SPF-compliant sender replacement, as ruled by the local policy. For
example, a sender replacement is needed anyway when the final recipient's
addresses are not to be disclosed to the message originator.
A forwarder may advertise some capabilities, such as querying some DNSBLs,
performing SPF checks, signing some headers, and similar. Zero or more of
the available capabilities may be enabled for each specific recipient.
After it has been whitelisted, a forwarder will not be deemed responsible
for relayed spam. If both hosts support spam reporting, that activity may
be coordinated by sending spam reports back to the forwarder when they
belong there.
In return for a forwarding authorization, a forwarder grants the final
recipient permissions to directly inquiry, update, and delete the relevant
record of its local forwarding policy. To delete here means to not forward
any further message, possibly responding "551 user not local". That way a
recipient can control and recurse through a chain of forwarders, e.g. via
web services. Update and delete actions should be handled differently
according to the kind of alias to alias-expansion relationship (1-1 or
1-many). This feature is not usually available, thus users currently need
a special page in their address books, maybe a sticky note on their
computer, whatever. Since it provides direct access to user's data on
remote system, it might increase the sexyness of this solution.
Authorizations should be granted automatically by target MTAs. Different
sites may implement different strategies in order to check a specific
relay is trustworthy. For example, it may consist of a three-way handshake
where a target MTA (i) grants a pre-auth and wants an https url to get
capabilities from, (ii) checks the forwarder's certificate against a list
of trusted CAs, and (iii) grants full auth or redirects the forwarder
toward a different protocol which may imply manual operations. This step
is important, as after a forwarder has been registered, it will be able to
obtain authorizations for forwarding to each new user in a fully automated
fashion.
A target MTA must keep track of the authorizations it granted. For each
authorization, some properties may be relevant, e.g. if the forwarding
happens after subscribing to a list, if the address has been
double-checked, what was the requesting IP, if an alias is meant for
concealing its expansion rather than as an address update, etcetera. The
access credentials gained from forwarders are also stored, providing an
opportunity for verifying opt-in data and to enable end users to maintain
their forwarding chains.
More or less, that's it. Comments will be highly appreciated.
-------------------------------------------
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=1311532&id_secret=92171479-00257b
Powered by Listbox: http://www.listbox.com
mind after browsing old posts about TENBOX and more recent discussions.
Re-reading it, I see that it is not tightly coupled with SPF. However, it
fixes forwarding also for SPF concerns. Thus, it's not off topic for this
list. Actually, it may play a nice stereo effect with the latest TENBOX
draft. If we are still alive, that is.
The tentative solution provides for a local forwarding policy. It relies
upon a database keyed on <forwarder, envelope recipient> pairs; where
"forwarder" is either the IP address or its FQDN, provided it got an SPF
"pass". When a message is being forwarded (i.e. it already has a
Return-Path), a mailer should look up the policy in order to determine
what envelope sender replacement, if any, it should use.
Not replacing the envelope sender is fine if the mailer can be
authenticated and/or whitelisted by the target MTA. Such whitelisting is
granted on a per-recipient basis. The forwarder might use existing
extensions to authenticate, e.g. the AUTH parameter idea. Either the
mailer or the local policy interface implementation should be able to
determine if the target MTA supports this kind of authorization, even if
the current recipient has not been authorized yet. In the latter case the
current message should remain in the queue (or be rejected with a 4xx
response) until the required authorization is granted. If the target MTA
does not support this solution, messages may still be forwarded using an
SPF-compliant sender replacement, as ruled by the local policy. For
example, a sender replacement is needed anyway when the final recipient's
addresses are not to be disclosed to the message originator.
A forwarder may advertise some capabilities, such as querying some DNSBLs,
performing SPF checks, signing some headers, and similar. Zero or more of
the available capabilities may be enabled for each specific recipient.
After it has been whitelisted, a forwarder will not be deemed responsible
for relayed spam. If both hosts support spam reporting, that activity may
be coordinated by sending spam reports back to the forwarder when they
belong there.
In return for a forwarding authorization, a forwarder grants the final
recipient permissions to directly inquiry, update, and delete the relevant
record of its local forwarding policy. To delete here means to not forward
any further message, possibly responding "551 user not local". That way a
recipient can control and recurse through a chain of forwarders, e.g. via
web services. Update and delete actions should be handled differently
according to the kind of alias to alias-expansion relationship (1-1 or
1-many). This feature is not usually available, thus users currently need
a special page in their address books, maybe a sticky note on their
computer, whatever. Since it provides direct access to user's data on
remote system, it might increase the sexyness of this solution.
Authorizations should be granted automatically by target MTAs. Different
sites may implement different strategies in order to check a specific
relay is trustworthy. For example, it may consist of a three-way handshake
where a target MTA (i) grants a pre-auth and wants an https url to get
capabilities from, (ii) checks the forwarder's certificate against a list
of trusted CAs, and (iii) grants full auth or redirects the forwarder
toward a different protocol which may imply manual operations. This step
is important, as after a forwarder has been registered, it will be able to
obtain authorizations for forwarding to each new user in a fully automated
fashion.
A target MTA must keep track of the authorizations it granted. For each
authorization, some properties may be relevant, e.g. if the forwarding
happens after subscribing to a list, if the address has been
double-checked, what was the requesting IP, if an alias is meant for
concealing its expansion rather than as an address update, etcetera. The
access credentials gained from forwarders are also stored, providing an
opportunity for verifying opt-in data and to enable end users to maintain
their forwarding chains.
More or less, that's it. Comments will be highly appreciated.
-------------------------------------------
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=1311532&id_secret=92171479-00257b
Powered by Listbox: http://www.listbox.com