[Asrg] Yet another attempt to fix forwarding

[Alessandro Vesely]

Hi all,
it is well known how SPF breaks forwarding. SPF is not itself an anti-spam 
mechanism, but it would help cleaning up the mail transport system by 
limiting domain abuse. If it were widely employed, that is. Thus, this 
post is not off topic, although not directly aimed at countering spam.


My tentative solution provides for a local forwarding policy. When a 
message is being forwarded (i.e. it already has a Return-Path), the 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 
should be granted with per-recipient granularity: the target MTA 
whitelists only messages destined to specific recipients. The forwarder 
might use existing extensions to authenticate, e.g. the AUTH parameter of 
the MAIL FROM command. Either the mailer or the local policy 
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. A sender replacement is needed 
anyway when the final recipient's addresses are not to be disclosed to the 
message originator.

Authorizations should be granted automatically by targets MTAs. Different 
sites may implement different strategies in order to check a specific 
relay is trustworthy, which may imply manual operations. After a relay has 
been registered, in case it needs to, it should be able to obtain 
authorizations for forwarding to each new user in a fully automated fashion.

A forwarder may provide some capabilities, such as querying some DNSBLs, 
performing SPF checks 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).

The target MTA also keeps 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, et cetera. The 
  access credentials gained from forwarders are also stored, keyed on both 
ip or helo name of the forwarder, and recipient address. That would 
provide an opportunity for verifying opt-in data and to enable end users 
to maintain their forwarding chains.


More or less, that's it. I've proposed the above description to a 
postmasters' mailing list, seeking for practical advice. I got almost no 
response. Why? Perhaps this solution is too simple, or too complicated, or 
there are obvious reasons why it won't fly. Would anyone on this list be 
able to spot them, please?

TIA
Ale