From owner-freebsd-stable@FreeBSD.ORG Sat Jan 27 15:50:40 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5CD216A400 for ; Sat, 27 Jan 2007 15:50:40 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.freebsd.org (Postfix) with ESMTP id 4B83913C4A3 for ; Sat, 27 Jan 2007 15:50:40 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from anc ([200.152.88.34]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id l0RFoclO068328; Sat, 27 Jan 2007 13:50:39 -0200 (BRST) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: Roland Smith Date: Sat, 27 Jan 2007 13:50:26 -0200 User-Agent: KMail/1.9.4 References: <8a20e5000701240903q35b89e14k1ab977df62411784@mail.gmail.com> <200701271304.29216.joao@matik.com.br> <20070127153953.GC96846@slackbox.xs4all.nl> In-Reply-To: <20070127153953.GC96846@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200701271350.26787.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Loosing spam fight X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jan 2007 15:50:40 -0000 On Saturday 27 January 2007 13:39, Roland Smith wrote: > On Sat, Jan 27, 2007 at 01:04:28PM -0200, JoaoBR wrote: > > > Greylisting is a decent idea, but it seems to me that it's just anoth= er > > > tool in the ongoing arms race against spammers. It may work for a > > > while, but eventually they'll catch on and it will only cause > > > unnecessary delays for legitimate mail. > > > > finally some cares about the users here, that is a really important > > point, how do you justify that your client get the email he is waiting > > for an hour later? Probably he looks then for a better service > > provider ... > > The standard requires a retry time of at least 30 minutes: > http://tools.ietf.org/html/rfc2821#section-4.5.3 > > But most open-source MTA's will try to resend after around 15 minutes: > http://en.wikipedia.org/wiki/Greylisting > > Note that the SMTP protocol does not guarantee delivery within a certain > timeframe. > I guess most servers do retry after 1-4 hours > There are timeouts of several minutes for each of the SMTP > commands. This means that a full SMTP conversation can last at least 1/2 > hour, from one server to another. yes, therefore it does not make sense retrying after 10 or even 31 minutes > > In short, an extra hour transit time is not a fault or bad service as > far as SMTP is concerned. that is certainly a technical and political excuse which nobody want to he= ar=20 for getting email late, because the common understanding is getting an emai= l=20 on earth within some minutes =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br