At 8:56 am -0500 2004/03/05, James P. Roberts wrote:
>My original point stands. I don't believe there would be significant impact
>to receiving or legitimate sending hosts. A given email would suffer a short
>delay, yes, but the resource cost is minimal to both ends (see previous
>arguments). Most users suffer several minute delays anyway, simply because
>their MUA only checks for new mail at intervals. A 30 second-ish delay would
>generally not be noticed.
>
>It would be philosophically similar to the time delay imposed by an antivirus
>or spam scanner; just longer, but much cheaper. It would demand a small cost
>of the sender, but probably less than, say, a callout. ;)
>
>Also consider the bandwidth saved by every host on the route between sender
>and receiver, who no longer have to carry the entire bogus email content.
>
>Because RFC's ask for senders to accept up to a 300 second delay, it is well
>within existing norms. The only ones significantly affected would be
>"viruses" (spelling nod to MBM), and spammers that don't conform to RFC
>standards of MTA behavior.
>
>I am beginning to think it would make more sense to impose the delay by
>default, and then test for special cases to avoid the delay, rather than the
>other way around!
>
well, I am sorry to say that it does not stand at all, at least as
exposed here, because the purpose would be immediately defeated, once
deployed on a large scale, as virus writers would simply increase the
timeout in their code! The only effect would then be a generalised
delay in email, not important, and an extra resource required for
servers.
I apply delays based on spam scoring, and if delays were a default,
the effect of my delay would clearly be lessened, unless, of course,
I increased their duration.
Besides, I do not see why you think Fred position to be in contrast
with yours. It looks more like a half empty/half full glass
question... only that a default delay seems the wrong approach for
the reasons detailed above.
Giuliano
--
H U M P H
|| |||
software
Java & C++ Server/Client/Human Interface applications on MacOS - MacOS X
http://www.humph.com/
