------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=711
Brad "anomie" Jorsch <anomie@users.sourceforge.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anomie@users.sourceforge.net
Status|NEW |RESOLVED
Priority|high |low
Resolution| |INVALID
--- Comment #1 from Brad "anomie" Jorsch <anomie@users.sourceforge.net> 2008-05-19 16:57:06 ---
The 417 error is not generated by exim internally. Does your exim.conf contain
any acl that would output such an error?
Anyway, I tested it by setting up a fake spamd that would never respond and
setting up a very simple exim.conf with spamd_address pointing to that port,
and it seemed to work as expected:
---
[...]
354 Enter message, ending with "." on a line by itself
<< From: root@mail.example.test
<< Date: Mon, 19 May 2008 10:54:56 -0400
<< Subject: Test
<<
<< Testing
<< .
>>> host in ignore_fromline_hosts? no (option unset)
>>> using ACL "acl_check_data"
>>> processing "deny"
>>> check spam = spamassassin/defer_ok
>>> trying server 127.0.0.1, port 8080
[... several minutes delay here ...]
LOG: 1Jy6gF-0006Gx-ED spam acl condition: error reading from spamd socket:
Connection timed out
>>> deny: condition test failed
>>> processing "accept"
>>> accept: condition test succeeded
>>> unspool_mbox(): unlinking '/var/spool/exim/scan/1Jy6gF-0006Gx-ED/1Jy6gF-0006Gx-ED.eml'
LOG: 1Jy6gF-0006Gx-ED <= root@mail.example.test H=([10.0.0.1]) [10.0.0.1]
P=esmtp S=285
250 OK id=1Jy6gF-0006Gx-ED
**** SMTP testing: that is not a real message id!
<< QUIT
221 mail.example.test closing connection
---
As for bug 404, in my testing just now it properly detects if the client drops
the connection before exim responds. When pipelining is active and the client
issues "QUIT" and disconnects, exim does not detect this; after checking RFC
2920, I don't think that it should. When pipelining is not active and the
client issues "QUIT" and disconnects, exim does not detect this; this is
probably a bug in that exim should treat any command at this point as a
pipelining violation.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=711
Brad "anomie" Jorsch <anomie@users.sourceforge.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anomie@users.sourceforge.net
Status|NEW |RESOLVED
Priority|high |low
Resolution| |INVALID
--- Comment #1 from Brad "anomie" Jorsch <anomie@users.sourceforge.net> 2008-05-19 16:57:06 ---
The 417 error is not generated by exim internally. Does your exim.conf contain
any acl that would output such an error?
Anyway, I tested it by setting up a fake spamd that would never respond and
setting up a very simple exim.conf with spamd_address pointing to that port,
and it seemed to work as expected:
---
[...]
354 Enter message, ending with "." on a line by itself
<< From: root@mail.example.test
<< Date: Mon, 19 May 2008 10:54:56 -0400
<< Subject: Test
<<
<< Testing
<< .
>>> host in ignore_fromline_hosts? no (option unset)
>>> using ACL "acl_check_data"
>>> processing "deny"
>>> check spam = spamassassin/defer_ok
>>> trying server 127.0.0.1, port 8080
[... several minutes delay here ...]
LOG: 1Jy6gF-0006Gx-ED spam acl condition: error reading from spamd socket:
Connection timed out
>>> deny: condition test failed
>>> processing "accept"
>>> accept: condition test succeeded
>>> unspool_mbox(): unlinking '/var/spool/exim/scan/1Jy6gF-0006Gx-ED/1Jy6gF-0006Gx-ED.eml'
LOG: 1Jy6gF-0006Gx-ED <= root@mail.example.test H=([10.0.0.1]) [10.0.0.1]
P=esmtp S=285
250 OK id=1Jy6gF-0006Gx-ED
**** SMTP testing: that is not a real message id!
<< QUIT
221 mail.example.test closing connection
---
As for bug 404, in my testing just now it properly detects if the client drops
the connection before exim responds. When pipelining is active and the client
issues "QUIT" and disconnects, exim does not detect this; after checking RFC
2920, I don't think that it should. When pipelining is not active and the
client issues "QUIT" and disconnects, exim does not detect this; this is
probably a bug in that exim should treat any command at this point as a
pipelining violation.
--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email
--
## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##