注）クライアントユーザーに対する DeleGate（元サーバーまたはプロキシー）
による通常のアクセス制御下の
SSI によるリソースが含まれます。
それは含まれるリソースのアクセスが拒否されます。
SSI-include 経由でも拒否されます。
virtual=http://exserver/dir/fileX のような DeleGate サーバーの管轄外リソースを含むことを許可するのは
SHTML 書込みのようにユーザーによるセキュリティーホールを作ります。
元サーバーのとき、SSI-includeプロキシーとしての転送は
RELAY=no によって拒否される必要がありますが、
他のサーバーからでも SSI-include で拒否されます。
バージョン9での簡単な方法は
RELAY="proxy:http:exserver:*"
のように制限した
RELAY を追加することで、
exserver のみへのリレーを許可します。
他の安全な方法は、
MOUNT="/ex/* http://exserver/dir/*" の後に
virtual="/ex/fileX" のような SSL-include を書きます。
しかしながら、双方とも
exserver の意図された仮想
URL 外のリソースに
アクセスすることをクライアントユーザーに許可します。
バージョン10 において上記問題の対処するため、RELAY=no とともに使う RELAY=ssi が追加されました。
RELAY=ssi は SHTML を書く者に他のサーバーからの物を追加でき、
クライアントユーザーの許可は変化しません（RELAY=no と同じ）。
RELAY=ssi 無しで言えば、あなた（DeleGate 管理者としての）は SHTML を書く者が
他のサーバーを含めるのを防げます。
RELAY=ssi:protocolList:serverList:clientList
のような DeleGate の汎用表記で追加可能な対象サーバー（プロトコル、クライアントも）
を制限することもできます。
バージョン10 での他の（そしてもっと重要かもしれない）拡張は、SSI-include 経由の
サーバーとクライアント間前後の要求・応答メッセージヘッダ（Cookie や User-Agent）をリレーすることです。
注）多分、プラットフォームや言語によらない方法で任意のサーバーにアクセスする CGI を禁止することは不可能です。
ですが、少なくとも、
REMITTABLE="+,-cgi".
で CGI 自体を禁止することができます。