Re: Operations requirement: no hop-by-hop

On 16-feb-04, at 2:02, Paul Hoffman / IMC wrote:

>> Why would you transport something that you don't want to have in the 
>> first place?

> Wrong question. The correct question is "is putting the policy 
> mechanism in the transport a better idea than putting it at the 
> endpoints?". You say yes; I say no.

I'm not sure if we can afford to select just one place.

>>  I don't think we can assume that policy validation is more expensive 
>> than transport as a general rule so transporting anyway would be 
>> preferable.

> I agree: we can't assume either way. What we can assume is that 
> putting policy in the middle is more dangerous than putting it at the 
> edge. The danger might be worth the value of lower transmissions, but 
> I don't think so.

So then the protocol must optionally support it.

>>> Of course. The cost is that you will refuse some messages that you 
>>> might have actually wanted

>> That's ok as long as this situation is communicated back to the 
>> sender so the sender can take appropriate action.

> You may find that OK; others may not.

Nobody is forcing anyone else to reject spam.  :-)

>> But I think the mistake we've both been making in this discussion is 
>> to treat every message as an independent event. It would be good to 
>> consider having to set up a relationship between the sender and 
>> recipient first (which could be relatively complex and time 
>> consuming) and then be able to check whether the sender is authorized 
>> to send messages of a certain type by looking if there is a valid 
>> reference to a valid relationship. This check could be relatively 
>> fast and simple.

> If your requirement is that there be full authentication before 
> communication, fine. My requirement is that I can communicate with 
> people who I cannot authenticate ahead of time.

Full authentication doesn't necessarily follow here. A simple return 
routability check would also go a long way.

I'm thinking about a layered policy mechanism that would work something 
like this:

- apply personal white list
- apply system-wide blacklist
- apply personal blacklist
- allow all strongly authenticatable sources (ie others who can present 
a certificate that we can authenticate directly or using a trusted CA)
- reject everything that looks too much like spam
- reject/defer attachments that are too big
- allow everything else if the return address works

In a setup like this the MTA would need to know personal white and 
black lists, spamcheck yes/no and attachment limits for known/unknown 
sources. I currently have about 300 people in my address book. 
Whitelisting all of them would easily fit in 100k, which is nothing 
compared to the actual mail that the server must store for me. And only 
the ones that wouldn't make it through the system wide blacklist would 
have to be in my personal whitelist.