[Asrg] Yet another attempt to fix forwarding

[Douglas Otis]

On Jan 31, 2008, at 3:00 AM, Alessandro Vesely wrote:

> 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.

DDoS attack damages may run into the millions per event.  The concept  
of "cheaper" should be weight against this _very_ serious risk.   
Content filter is doomed, as bad actors always have the advantage.   
Something like CSV is far safer and likely just as effective.   
Adopting RFC 3464 would help with DSN as well, especially where  
original message content is redacted.

> 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".

Expecting a pass will be problematic.  A translation process will need  
to qualify DSNs, not the message being forwarded.  BATV is an example  
of how this might be done, but this imposes a requirement that the  
domain's email uses a common Return Path protection strategy.  That,  
in it self, can be a problem.

>> 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.

The concept was to improve the integrity of email's delivery process  
that is currently suffering due to a high loss of DSNs.  DKIM in  
conjunction with TPA-SSP would allow signatures to be associated with  
the desired RFC 2821 MailFrom.  TPA-SSP allows this association to be  
made autonomously by just email-domain owner.  DKIM key exchanges  
would be far more complex, costly, and risky.

>> 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.

Agreed.  But trusted implies specific expectations as well.

Using DKIM, a provider might sign email with a domain of  
"authenicated.provider.com" where any of their  
"authenticated" (control of the associated mailbox has been verified  
for example), could then autonomously use TPA-SSP to specifically  
authorize "authenicated.provider.com".  The provider could sign all  
their customers using a common signature, and apply the same criteria  
for all those permitted to access that specific domain.  The  
provider's own domain might authorize both  
"authenticated.provider.com" "not-authenticated.provider.com" and  
select the signing domain based upon the "authentication" status of  
the message.

>> 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...

Agreed.  But there are also market forces that stand in the way of a  
good design.

>> 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.

Here is one.

http://mipassoc.org/batv/draft-levine-batv-03.txt

-Doug