We all know how SPF breaks forwarding. Some even say that forwarding has been broken since rfc1123 deprecated source routing in the envelope return path, in 1989. Anyway, it is broken now. That's why I'm asking to this list for any comments, thoughts, and insights that may lead to fix forwarding.
A 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. An hypothesis is that such whitelisting should be granted with per-recipient granularity, i.e. whitelisting only for a specific recipient, e.g. using 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 is able to support this kind of authorization, even if the current recipient has not been authorized yet. In the latter case the message at hands should stay 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. 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 the local forwarding policy. To delete here means to not forward any further message, possibly responding "551 user not local". That way a recipient can be able to 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). 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. To retrieve those properties, a target host may store access credentials gained from forwarders, keyed on both recipient address and ip or helo name of the forwarder. Thus, that may imply an additional database, besides the local policy one. However, it would also provide an opportunity for verifying opt-in data. More or less, that's it. The Anti-Spam Research Group might have been a more suitable list for this topic, but I'd rather seek practical advice. Any? ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
