one-to-many messaging

[Matthew Pemble]

------=_Part_19419_17098297.1207124111420
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 01/04/2008, PeteM <otcbn@callnetuk.com> wrote:
>
>
>
> Be that as it may, what is clearly not lawful is the presentation of
> forged 404s to people trying to access pages on the blocked list.


Surely the strictly RFC correct response would be a 403 code - you did
everything technically correct but I am still not serving you the page?
However the RFC text makes it clear that a 404 is a technically legitimate
(I'll leave the lawyering to somebody else) response:

10.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request SHOULD NOT be repeated.
   If the request method was not HEAD and the server wishes to make
   public why the request has not been fulfilled, it SHOULD describe the
   reason for the refusal in the entity.  If the server does not wish to
   make this information available to the client, the status code 404
   (Not Found) can be used instead.



Another reasonable response would be to produce a simple page providing
details of what has happened and why, and, who to complain to if you think
the block has been correctly applied.  I appreciate that the architecture is
different but corporate filters such as Websense provide this functionality.

Matthew

------=_Part_19419_17098297.1207124111420
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br><br><div><span class="gmail_quote">On 01/04/2008, <b class="gmail_sendername">PeteM</b> &lt;<a href="mailto:otcbn@callnetuk.com">otcbn@callnetuk.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q"><br><br></span>
Be that as it may, what is clearly not lawful is the presentation of forged 404s to people trying to access pages on the blocked list.</blockquote><div><br>Surely the strictly RFC correct response would be a 403 code - you did everything technically correct but I am still not serving you the page?&nbsp; However the RFC text makes it clear that a 404 is a technically legitimate (I&#39;ll leave the lawyering to somebody else) response:<br>
<br><pre><span class="h4"><h4><a name="section-10.4.4">10.4.4</a> 403 Forbidden</h4></span><br><br>   The server understood the request, but is refusing to fulfill it.<br>   Authorization will not help and the request SHOULD NOT be repeated.<br>
   If the request method was not HEAD and the server wishes to make<br>   public why the request has not been fulfilled, it SHOULD describe the<br>   reason for the refusal in the entity.  If the server does not wish to<br>
   make this information available to the client, the status code 404<br>   (Not Found) can be used instead.</pre><br><br>Another reasonable response would be to produce a simple page providing details of what has happened and why, and, who to complain to if you think the block has been correctly applied.&nbsp; I appreciate that the architecture is different but corporate filters such as Websense provide this functionality.<br>
<br>Matthew<br></div><br></div><br>

------=_Part_19419_17098297.1207124111420--