Re: [Exim] Re: Bagle, unqualified HELO, time delays

> 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.

I wouldn't myself notice it too much, but there can be a problem. This
seems like the duct tape approach to the problem. I would not want to have
to wait if I'm using telnet to test a server though.

> 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. ;)

I don't do any spam scanning at work (neither at home). At work there's
about a 1-2 second delay for a 1mb email to be unpacked and scanned.
(just remember work provides email for about 250 addresses)

> 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!

I don't see this. Spammers and virii catch up to tricks like this. This
would only be a temporary solution. Unfortunately most if not all are
temporary solutions to the problem. Some seem to work better than others.

--
Lab tests show that use of micro$oft causes cancer in lab animals