"Za'mbori, Zolta'n" <zamboriz(_at_)axelero(_dot_)hu> wrote:
For example it is predictable by everybody based on the port address of
a running service that the service software will read a specific
protocol data unit or not; will accept the content for processing or
not.
No. I can run HTTP servers on any port. When used in conjunction
with something like RPC, you have *no* way to use TCP ports to
classify a packet on your network as RPC or HTTP. The TCP ports don't
tell you. The *only* thing you can do is to examine the application
data, compare it to RPC and HTTP, to see which one it matches.
The problem is that the intersection of RPC and HTTP isn't empty.
So there are some packets which you can't classify just by looking at
the packet. You've got to go poke the port yourself, to see what
application server is running.
The result of this unpredictability (lack of 'rules' assigned to email
addresses): spammers will send spam to any email address what they have
because they dont have informations how to do self-filtering.
No. Spammers already have sufficient information to do
self-filtering. There are domains which didn't have an MX for years,
and when one was put into DNS, it was immediately spammed. There are
systems which reject traffic to all SMTP destinations, and spammers
still try those destinations years later.
Spammers have plenty of negative feedback, as information. But
simply NACK'ing a message is insufficient. What is needed is negative
feedback as *punishment*. e.g. Greylisting is network-based negative
feedback that works by slowing down the rate at which spam is sent.
Recipient MTA's often do *nothing* when they're attacked by
spammers. This creates a de-facto positive feedback system, giving
the spammers every incentive to increase their rates.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg