[Asrg] Yet another attempt to fix forwarding

[Alessandro Vesely]

Douglas Otis wrote:
> SPF's use of macros represents a serious security issue in itself.  This 
> allows traffic to be generated from cached records triggered by changes 
> in a sender's email-address found within spam campaigns.  Processing SPF 
> against unknown domains increases the magnitude of this threat.

Still, from the limited point of view of running my own MTA, I find SPF 
checks cheaper than content filtering and verifying signatures, as the 
latter can only be done after the message body has been received. DNSBLs 
work much like it, but are one order of magnitude more efficient, for the 
time being.

>> 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.
> 
> This reminds me of the Monty Python movie Jabberwocky central character 
> Dennis Cooper's suggestion "It would increase your efficiency if you 
> moved your box to here."  It resulted in chaos.  A chain of hashed 
> local-parts translated locally into an original return-path address 
> would need to include other elements of the message to prevent abuse.

That looks exactly like the kind of criticism I have been looking for, 
thanks! However, I don't think I've got it quite rightly (perhaps because 
I missed the movie.) I imagine a local forwarding policy as a database 
keyed on <forwarder, envelope recipient> pairs; where "forwarder" is 
either the IP address or its FQDN, provided it got an SPF "pass".

The receiving MTA already has a database of recipients, and deploying this 
technique is going to multiply that by a number of forwarders. Likewise, 
the sending MTA must have a similar database, and a forwarding directive 
attached to the address that triggered the relay. That looks manageable to 
me, if not flooded by spammers.

A spammer can pretend to forward a message. If the receiving MTA does not 
limit which hosts can receive an authorization for being whitelisted, the 
spammer can succeed. That is not much different than directly sending the 
spam, except that it adds one record to the local policy. If the receiving 
MTA can determine that the spammer is spamming directly rather than 
relying spam, then it may put a blacklist flag on that record, thereby 
nullifying the spammer's attempt to set up an acknowledged relay. However, 
  it is not easy for the receiving MTA to make that determination. Is that 
the abuse problem you mean?

> Another solution using this concept and not depending upon a dangerous 
> and unmanageable SPF path registration can be found here:
> http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-02.txt
> 
> This allows the RFC 2821 MAIL FROM (return-path) to reference a 
> Third-Party Authorization against a specific domain in question.

The spammer probably won't sign its return-path. A forwarder advertising 
the ability to sign its return-paths could get authorizations more easily, 
though.

> It seems rather ironic SPF's intended purpose was to direct culpability 
> to the provider's customer (the email-address owner).

I don't want to delve into the discussion you had with Frank while I was 
sleeping. I just want to note that provider and customer must trust each 
other.

> Fatigue and "market" forces rather than accomplishment might be an 
> epitaph for waning interest in ASRG.

We'll never have a better world if we don't try and design it...

>  At least John Levine's 
> contributions to this noble cause can still be found elsewhere.

Any specific pointer? I just read some of his posts on the CircleId.