applications cannot be expected to deal with filters in any way
other than to report that the communication is prohibited. the
"well known" flag exists and is called ICMP.
Well, that is emphatically *NOT* what application developers do. They
do not just observe that it does not work, they try to work around,
e.g. routing messages to a different address, at a different time,
through a third party, or through a different protocol.
that's because (a) customers demand that apps work even in the presence
of NAT, no matter how unreasonable this is, and (b) the way most
filters are implemented, there's no good way for an app to tell whether
a communications failure is due to a network or host failure or to a
prohibition. ICMP is the only mechanism we have to do this, and it's
not widely used.
Silently dropping packets is certainly not the right way to get an
application to stop trying. ICMP messages won't achieve that either:
since ICMP is insecure, it is routinely ignored.
ICMP may be routinely ignored, but on false premises. ICMP is no
less secure than anything else in TCP or IP that is routinely trusted.
Which actually poses an interesting question: when should an
application just give up? IMHO, there is only one clear-cut case, i.e.
when the application actually contacted the peer and obtained an
explicit statement that the planned exchange should not take place --
the equivalent of a 4XX or 5XX error in SMTP or HTTP.
I'd claim that ICMP prohibited is another case for giving up.
note that a 4xx error is an explicit "it's okay to retry" indication.
Keith