Andrzej Filip <anfi(_at_)Box43(_dot_)pl> wrote:
You can make secondary mail server know valid addresses in the domain
and reject the remaining.
Even better. Have 3-4 "secondaries" hosted at the same site, and
have others off-site.
It's fairly straightforward to classify mail into different "bins",
by abusing the interpretation of MX priority records. This proposal
requires some additional local administration over current methods,
but I'll propose it here as a "straw man".
The idea is to locally interpret (or abuse) MX priority records.
The following table illustrates the network setup:
Priority MTA Activities
-------- --------------
1 source IP filtering, accepting email only
from a set of whitelisted IP's.
2 what (1) does, plus ident/RMX
3 (2), plus spam filtering
. ... even more graduated filtering
The idea is that the other end *already* walks down the list of MX's
by priority, if there's a delivery error. We can abuse this behaviour
to allow the people we know (whitelisted) to connect with no cost.
People we don't know suffer a small penalty for delivering mail at
the STMP level (users shouldn't see this), and will fall back to using
a lower-priority MX. The more spammers try MX 1, the more they get
punished, as their connections are rejected or silently dropped.
This method also allows the incoming email to be trivially
classified with little local work. "Gold" email comes from IP's on a
whitelist, and any anti-spam content filtering can err on the side of
caution. "Silver" email comes from people who are traceable, and who
have publicly declared their identity. "Bronze" email comes from
everyone else.
No email is dropped from anyone, unless the "bronze" content filters
decide to do that. No one outside of the mail system even knows that
this is happening.
I haven't spent a lot of time thinking about this, but the general
approach is similar to that used by Physicists in particle
accelerators. They have terabit streams of data, which are passed
through successive "sieves", to filter and classify the information
into multiple pre-digested sub-streams.
Comments?
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg