On Thu, 3 May 2007, Kjetil Torgrim Homme wrote:
> On Fri, 2007-04-13 at 16:29 +0100, Philip Hazel wrote:
> > Then it struck me that there is no need to mess with signals. A simple
> > call to select() can also detect this situation. I have therefore
> > implemented code to do this (with some ext
On Fri, 2007-04-13 at 16:29 +0100, Philip Hazel wrote:
> Then it struck me that there is no need to mess with signals. A simple
> call to select() can also detect this situation. I have therefore
> implemented code to do this (with some extra features for the "input
> sent too soon" case, becaus
On Sat, 14 Apr 2007, Jack Bailey wrote:
> The test I just finished has local_scan() create a process that catches
> SIGIO before running any of its filter code. When SIGIO arrives, the
> process stops whatever it's doing and silently abandons the message.
> The advantage to using signals is t
Philip Hazel wrote:
> On Mon, 2 Apr 2007, Jack Bailey wrote:
>
>
>> I took a look at this awhile back and it's possible to detect far end
>> disconnections by setting the socket to async IO. The idea is arrange
>> for Unix to send the process a signal when IO is pending on the socket,
>> but it
On Fri, Apr 13, 2007 at 04:29:09PM +0100, Philip Hazel wrote:
> As this is happening at the point where Exim is about to issue a 250
> "OK, I've got your message" response, *both* those situations are
> errors. What should be the case is that the connection is still present,
> but there is no in
On Mon, 2 Apr 2007, Jack Bailey wrote:
> I took a look at this awhile back and it's possible to detect far end
> disconnections by setting the socket to async IO. The idea is arrange
> for Unix to send the process a signal when IO is pending on the socket,
> but it also works for disconnects.
On Tue, 3 Apr 2007, Ian FREISLICH wrote:
> Is it safe to abandon the mail after crlf.crlf when the connection
> has vanished?
Yes. A server that has not sent the OK is not deemed to have accepted
the message.
> Can fgetc(), ungetc() and ferror() not be abused to test this or
> does exim not use
Philip Hazel wrote:
> On Mon, 2 Apr 2007, Magnus Holmgren wrote:
>
> > Even if it's not a bug in Exim, I think it's something that could be
> > improved. Exim should be able to check if the sender has gone away
> > before sending the final OK. Not in all cases, but at least in the
> > case describ
On Mon, 2 Apr 2007, Jack Bailey wrote:
> I took a look at this awhile back and it's possible to detect far end
> disconnections by setting the socket to async IO. The idea is arrange
> for Unix to send the process a signal when IO is pending on the socket,
> but it also works for disconnects.
>>> We've been here before. If you can find a way to tell that the sender
>>> has gone away without trying to read from the input file descriptor, it
>>> would also solve the problem of "delay" hanging around when the other
>>> end has disappeared. We had a discussion about this about a year ago (
On Mon, 2007-04-02 at 11:27 +0100, Philip Hazel wrote:
> On Mon, 2 Apr 2007, Magnus Holmgren wrote:
>
> > Even if it's not a bug in Exim, I think it's something that could be
> > improved.
> > Exim should be able to check if the sender has gone away before sending the
> > final OK. Not in all c
On Mon, 2 Apr 2007, Magnus Holmgren wrote:
> > We've been here before. If you can find a way to tell that the sender
> > has gone away without trying to read from the input file descriptor, it
> > would also solve the problem of "delay" hanging around when the other
> > end has disappeared. We had
On Monday 02 April 2007 12:27, Philip Hazel wrote:
> On Mon, 2 Apr 2007, Magnus Holmgren wrote:
> > Even if it's not a bug in Exim, I think it's something that could be
> > improved. Exim should be able to check if the sender has gone away before
> > sending the final OK. Not in all cases, but at l
On Mon, 2 Apr 2007, Magnus Holmgren wrote:
> Even if it's not a bug in Exim, I think it's something that could be
> improved.
> Exim should be able to check if the sender has gone away before sending the
> final OK. Not in all cases, but at least in the case described.
We've been here before.
On Thursday 29 March 2007 00:24, Matthew Byng-Maddick wrote:
> On Wed, Mar 28, 2007 at 02:44:43PM -0400, Bob Johnson wrote:
> [snip correct diagnosis of problem that is extensively discussed in the
> RFCs for SMTP]
>
> > I think the sending system should have a timeout longer than 60 seconds,
> >
Arthur Hagen schrieb:
> There's many things that are required according to RFCs that are
> impractical on the modern day Internet. The mandated 10 minute timeout
> is one of these [...] Similar for mail, where spammers in particular don't
> play
> nice, and may not bother about niceties like QUI
On Sun, 2007-04-01 at 17:00 +0200, Thomas Hochstein wrote:
> Bob Johnson schrieb:
>
> > I think the sending system should have a timeout longer than 60 seconds,
>
> It is *required* to have a much longer timeout.
There's many things that are required according to RFCs that are
impractical on the
Bob Johnson schrieb:
> I think the sending system should have a timeout longer than 60 seconds,
It is *required* to have a much longer timeout.
> but even so, this is a bug in Exim.
No, it isn't. It is a bug in the remote installation, and perhaps a
poor configuration of the local SpamAssassin,
On Wed, Mar 28, 2007 at 02:44:43PM -0400, Bob Johnson wrote:
[snip correct diagnosis of problem that is extensively discussed in the
RFCs for SMTP]
> I think the sending system should have a timeout longer than 60 seconds, but
> even so, this is a bug in Exim. At the moment I can't find a log en
> From: gagabay <[EMAIL PROTECTED]>
> To: exim-users@exim.org
>
> Renaud Allard wrote:
> > Could you please post some logs from this email.
> > I already got someone telling me the exact same thing, and indeed, the
> > MUA sent it only once but their MTA sent the very same mail every 4
> > seconds
20 matches
Mail list logo
