Re: [Asrg] Ban the bounce; improved challenge-response systems

On Monday, April 7, 2003, at 01:54  AM, Claus Färber wrote:
> > Consider AOL's case for starters.  From what I can tell they have a
> > three-level setup, with a first line of simple receivers, a middle 
> > area
> > of message routers and analysers (eg where the silent discards 
> > happen),
> > and then a set of back end storage servers handling the LDA business.
> Even this system should not receive mail faster than the analysers can
> handle it and storage servers can tuck it away. Each level can start to
> temporarily reject messages (or connection) until the next level can
> handle the mail.
Doesn't work under many situations. I have a machine specifically set 
up as a incoming "sponge", to accept mail as fast as possible and hold 
it until it can be sent to a series of processing machines or scripts 
or mailboxes or other things.
To do what you want, I'd have to, among other things, move my 
processing machines from inside the firewall to a DMZ, where they 
connect directly to the net, which would make them much more vulnerable 
to cracking, and it would force me to move data that's currently behind 
the firewall system into a location where it's potentially accessible. 
To me, that's a non-starter. Sorry.
I think it also makes these systems more accessible to a dictionary 
attack, since now a spammer can directly query the account status via 
probing bounces -- and it's much more difficult to track that probe and 
stop it, since you've moved it out to the periphery, where a spammer 
who's poking at 8-10 incoming relays in sequence to do the dictionary 
attack would be very difficult to recognize and intercept on a real 
time basis.
Since since a lot of my incoming mail is very bursty (lots of short, 
intense peaks), I use the sponges to accept them as quickly as 
possible, and then process it in non-real time. this proposal would 
require my outgoing servers to accept and process the failures, and the 
requirement that I have to accept email in real time is not acceptable, 
some of my processing cycles can be delayed 10 days. Leaving mail on 
someone else's server until I get around to accepting it is a ban 
neighbor policy, I try to avoid that. Leaving email on someone else's 
server because I can't accept it until I'm ready to process it is a 
really bad idea.
This whole proposal doesn't seem to understand how and why large 
corporate e-mail systems work, and I'm not sure it buys anything useful 
on top of it. it asks companies to move their data into vulnerable 
situations, exactly the opposite of what we ought to be asking. Those 
stupid incoming relays are there for very good reasons: one is to 
accept mail to reduce the need for secondary MXes and other fallback 
situations, and to cut the need for mail retries and delivery delays 
(If my system is overloaded, currently, I can accept the mail into a 
sponge, and then retry every 10 minutes to speed delivery. If I have to 
push it back to someone else's system, their retry might by four hours, 
or six, or worse, causing that email to be horribly delayed. Bad 
thing). Second, those relays allow us to DMZ our mail systems, so that 
even if they are penetrated, no significant data is released. By 
forcing those systems to make these bounce decisions, you also force 
the data needed to make those decisions out from behind the firewall 
where it's vulnerable to attack or penetration, and that alone will 
make this proposal a non-starter for most large email installations.

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