Subject: Re: [Asrg] Greylisting BCP

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 21:27:38 -0800

> -----Original Message-----
> From: Jose-Marcio Martins da Cruz [mailto:[email-masked]]
> Sent: Wednesday, October 26, 2011 2:47 AM
> To: Anti-Spam Research Group - IRTF
> Cc: Murray S. Kucherawy
> Subject: Re: [Asrg] Greylisting BCP
> 
> You should take some care with this. Ressource usage varies a lot with different implementations :
> you'll find in memory chained lists, some RDBMS (e.g. MySQL) or ISAM/B-Tree/HASH (e.g. BerkeleyDB).
> Some implementations are smarter than others about ressources needes :
> e.g. how to expire old entries or how to aggregate them. And this makes
> a big difference on how expensive the filter is.
> 
> Put simply, when talking about greylisting, expensive or not is more
> related to the implementation and to some tuning (e.g. delays) than to
> the method itself. I'm not even talking about poor programming
> practices...

The point is that there is a range of expenses based on the implementation, the cost is rarely zero or even close to it.  I don't think it's necessary to run up a full bill of materials for each possible implementation in the BCP, but merely to make it clear that the benefits have a definite cost associated with them in terms of resources.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 21:28:33 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Smith
> Sent: Wednesday, October 26, 2011 2:51 AM
> On the other hand, if it stops a reasonable amount of spam, it reduces
> bandwidth, processing time and storage requirements, as well as human
> time & annoyance handling the spam.
> 
> It's up to the implementer to decide whether the cost of implementing
> greylisting is more or less than the cost of not implementing it.

Right.  Enumerating such tradeoff considerations is ideal material for a document such as this one.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 12 Nov 2011 21:51:06 -0800

> Sent: Saturday, October 29, 2011 2:16 AM
> Subject: Re: [Asrg] Microsoft takes over British Telecom
> 
> I've been thinking about forwarding
> 
> If you have A -> B, then server B forwards to server C, C can't do any
> authentication based on A, because A doesn't know about the forwarding
> (or it would, presumably, just send to C directly).
> 
> So, all sender domain authentication fails (without return path
> rewriting)

There's an alternative proposal under development.  The idea is that B evaluates the message from A (be that with SPF or DKIM, or something else), and then applies an Authentication-Results (RFC5451) field with its findings.  When it relays toward C, it DKIM-signs the augmented message first.  When C gets it, it verifies B's signature, and then it can use the contents of the Authentication-Results field that B added to determine whether use of A's domain was authorized, even if A's signature no longer validates (and presumable A's SPF policy is guaranteed to fail at this point).  There must, of course, be an out-of-band arrangement that C trusts what B claims already in place for this to work.

That's the theory.  The specific mechanics and abuse defenses are still evolving.  The term "transitive trust" is being batted around as a label for the concept.  It's actually in production at a couple of large mailbox providers already.

I've spoken to people at IETF about the DANE idea, and it's universally considered a dead end, mostly because it simply doesn't scale and is ineffective against infected machines that otherwise can get authorization in the first place.  DANE is really designed to authorize use of domain names with respect to web pages, I believe, and not to authenticate clients.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 14 Nov 2011 11:22:10 +0100

On 13/Nov/11 06:51, Murray S. Kucherawy wrote:
>> From: irtf.org On Behalf Of Paul Smith
>> 
> There's an alternative proposal under development.

Is participation open?

> B [...] applies an Authentication-Results (RFC5451) field.  When it
> relays toward C, it DKIM-signs the augmented message first.  When C
> gets it, it can use the contents of the Authentication-Results field
> that B added [...] There must, of course, be an out-of-band
> arrangement that C trusts what B claims already in place for this
> to work.

The out-of-band arrangement should be standardized so as to require
the final recipient's as the sole human intervention.  Does this suit
that idea? http://fixforwarding.org/wiki/forwarding_agreement

> That's the theory.  The specific mechanics and abuse defenses are
> still evolving.  The term "transitive trust" is being batted around
> as a label for the concept.  It's actually in production at a
> couple of large mailbox providers already.

A couple?  I thought transitivity implied at least three :-/