ietf-asrg
[Top] [All Lists]

RE: RE: [Asrg] 3. Requirements - Non Spam must go through

2003-07-08 14:00:59
From: asrg-admin(_at_)ietf(_dot_)org [mailto:asrg-admin(_at_)ietf(_dot_)org] 
On 
Behalf Of Barry Shein
Sent: Tuesday, July 08, 2003 4:07 PM

On July 8, 2003 at 20:23 jrk(_at_)merseymail(_dot_)com (Jon Kyme) wrote:
You mean not accepting connections from some host drives 
them to  > hammer on your firewall?  > I think that this is a 
truly exceptional situation.

The term of art is "requeue & retry", which would be the 
standard behavior of every MTA I've ever worked with upon 
connection failure.

Put 10,000 spam msgs headed for your host on some server and 
even 30 minute retry times don't help much, they get to the 
end of the list and they're ready to start again with the 
first one which failed.

Presume for a moment that a consent policy is adaptive so that it can
adjust it's "rejection policy" when abuse is detected. Abuse = a failure
to go away when told to (loosely).

I had recommended that the most aggressive level of rejection would be
to reject the connection.

Based on your comments perhaps the highest level (after that) is to
accept and silently eat messages from that SENDER or SENDERs.

Assuming that a standard consent policy framework allows systems within
a COT (Circle Of Trust) to adopt the policy decisions of their peers
under some conditions, then we might presume that a wide collection of
systems would adopt the same rejection policy.

I think this is not the final solution though - rather it is a safety
valve - a "cry for help" when a system elects this rejection policy.
What is needed at that point (or perhaps before) is DSQP (Dynamic
Squelch Propagation) where the decision to reject packets from the
offending source can be propogated as close as possible to that source -
essentially shutting it down. (DSQP is a mechanism needed for any kind
of abuse... consent policies are simply a good way to pull the trigger.)

DSQP (or some other name for the same thing) seems to be beyond the
scope of this group and ultimately would be a high-level network tuning
mechanism that effects routers. However this group should consider
making the recommendation for such a protocol and should implement the
structures needed in the consent framework to interface with protocols
like DSQP in response to abuse.

_M


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>