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

Page principale
Supprimer ce message
Répondre à ce message
Auteur: James P. Roberts
Date:  
À: exim-users, Giuliano Gavazzi
Sujet: Re: [Exim] Re: Bagle, unqualified HELO, time delays
----- Original Message -----
From: "Giuliano Gavazzi" <eximlists@???>
To: <exim-users@???>
Sent: Friday, March 05, 2004 6:52 AM
Subject: Re: [Exim] Re: Bagle, unqualified HELO, time delays


> At 11:23 am +0000 2004/03/05, Matthew Byng-Maddick wrote:
> >On Thu, Mar 04, 2004 at 10:05:02AM -0800, Fred Viles wrote:
> >>  On 4 Mar 2004 at 9:52, James P. Roberts wrote about
> >>  | Would it make sense to apply a 30 second-ish delay to every incoming
> >>  | connection, simply to weed out the virii?  Since any legit MTA
> >>should accept
> >                                        ^^^^^ viruses
> >>  | such a delay without incident, and most virii engines would give up.
> >                                             ^^^^^ virus
> >>  No, I think that would be very anti-social behavior.  Imagine if
> >>  everyone did it - what would happen to the Internet's email
> >>  infrastructure?

> >
> >I think you misunderstand the fundamental point of SMTP and unreliable
> >connections.
> >
> >I don't believe it to be anti-social behaviour, and believe in causing
> >deliberate command-response penalties based on host-history and current
> >behaviour. I am quite happy for others to do the same to hosts that I
> >run.
>
> You have cut out the rest of his though that went like:
>
> At 10:05 am -0800 2004/03/04, Fred Viles wrote:
> >IMO, artificial delays should be introduced into the SMTP session
> >*only* if there is already good reason to suspect that the sender is
> >not legitimate. Then the benefit outweighs the infrastructure cost
> >(IMHO).
>
> so he appears to agree with your last paragraph above.
>
> you also wrote:
>
> >The point is that the people it seriously impacts are those hosts who are
> >sending out large amounts of mail to hosts which implement this kind of
> >policy, not the average mail.
>
> his point was against a generalised application of such a delay, that
> clearly would affect the average mail. I think his point is valid if
> we can consider as anti-social any behaviour that would cause
> inconvenience if generalised.
>
> Giuliano
>


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!

Jim