[spf-discuss] Yet another attempt to fix forwarding

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=2183229&id_secret=92154152-42a932
Powered by Listbox: http://www.listbox.com