inline ...
On Aug 25, 2007, at 9:37 AM, Alexey Melnikov wrote:
Cullen Jennings wrote:
> I don't think that is really implementable advice - it basically
> wishes the problem away.
It is implementable, it applies to UIs and admin tools and many
implementations already follow it.
So the topic I was questioning the implementability of is a program
that can look a series of sieve scripts across one or more email
servers and decide if the sieve scripts are capable of creating large
scale message amplification attacks. The draft clearly does not
contain enough information to tell someone how to implement this and
personally I seriously doubt that it is possible due to the halting
problem. Of course I suspect it is not possible because I am also
very incredulous of the WG's claim that sieve coupled with common
email systems is not turing complete. Luckily I think that an
acceptable solution can be found without having a debate about basic
CS theory.
> More inline ...
> On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote:
>
>> Cullen, does the following address your DISCUSS?
>>
>> =============================
>> In section 4.2, last paragraph:
>>
>> OLD:
>> Implementations SHOULD take measures to implement loop control,
>> possibly including adding headers to the message or counting
Received
>> headers. If an implementation detects a loop, it causes an error.
>> NEW:
>> Implementations SHOULD take measures to implement loop control,
>> possibly including adding headers to the message or counting
Received
>> headers as specified in section 6.2 of [SMTP]. If an
>> implementation detects a loop, it causes an error.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> Add to the end of section 4.2 two new paragraphs:
>>
>> Implementations SHOULD provide means of limiting the number of
>> redirects a
>> Sieve script can perform.
>
> Well if it was the number of redirects SHOULD be limited to one it
> would do it but as it is - not sure I see how it helps.
Cullen, I told you before, there is very strong WG consensus to allow
implementations to use more than one.
Please see
<http://www.imc.org/ietf-mta-filters/mail-archive/msg03601.html> and
<http://www.imc.org/ietf-mta-filters/mail-archive/msg03599.html>.
Now, if you have another suggestion how to address your issue, I would
like to hear it.
I have given a simple and easy way to address it that seemed to also
work for the use cases that people told me about (I certainly admit I
don't know all the case). However, let me be very clear - it is not
my job to find a solution that the WG likes to this. I believe that
the IETF has clear consensus that it does not want to deploy
technology that could trivially be used for large scale DOS and
message amplification attacks with very little safeguards or
traceable ways of dealing with this. Now my current judgement call is
that this is in that category and could cause harm to the internet.
You can convince me I am wrong about that - or you could find a way
of mitigating and reducing this risk - I can think of several and I
have suggested the one that I think is most likely to be acceptable
to the WG but I make no presumption that I would know what is the
best solution for this WG on this problem. I have made it clear what
the issues is, why I think a change is needed, this should not be hard.