Re: NOOP and Spamd
On 2007/03/19 20:39, Lyndon Nerenberg wrote: > You will also find the command sequence RSET+NOOP used to delimit > transactions when an SMTP client reuses an established SMTP session > to send multiple messages. That (reusing an established session) won't happen whilst talking to spamd.
Re: NOOP and Spamd
On Mar 19, 2007, at 7:17 PM, Timothy A. Napthali wrote: The only problem I can foresee is that I remember reading somewhere that some MTAs use NOOP as a kind of keep-alive at times. You will also find the command sequence RSET+NOOP used to delimit transactions when an SMTP client reuses an established SMTP session to send multiple messages. Once upon a time the NOOP after RSET was required to work around some SMTP server protocol state machine bugs. While those servers a likely long gone, I still see this client behaviour on occasion. --lyndon
Re: NOOP and Spamd
The only problem I can foresee is that I remember reading somewhere that some MTAs use NOOP as a kind of keep-alive at times. This may be an issue depending on how those MTAs deal with not getting the 250 response from SPAMD they were expecting. Tim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Anderson Sent: Tuesday, 20 March 2007 6:03 AM Cc: OpenBSD Misc Subject: Re: NOOP and Spamd ** Reply to message from Bob Beck <[EMAIL PROTECTED]> on Mon, 19 Mar 2007 09:40:52 -0600 >* Sid Carter <[EMAIL PROTECTED]> [2007-03-19 03:25]: > >> > Regardless, if NOOP is in the SMTP standard, and spamd does not >> > handle it correctly, that is a bug that needs to be fixed. > > Bullshit. that's not a good enough reason - spamd does not implement >all of smtp, and never will. saying "it's in the smtp standard" is the >wrong way to get anything into spamd :) > > OTOH, if there is real stuff from the century of the fruit bat that >uses this I'll put it in. If it's someone's BBS mailer from the >century of Def Leppard and Mullets I'm not bloating the code one line >to deal with it. I've asked the poster for details. Anyone else who can >confirm real stuff needing NOOP please let me know. I certainly don't want to see spamd (or anything else) made overcomplicated by "somebody might need that" code, but wouldn't it make sense to include anything which is both in the standards and truly trivial to implement sufficiently for spamd's purposes? It seems to me that in those cases the cost to implement and maintain is so low as to be worthwhile even if it only avoids relatively unlikely problems. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: NOOP and Spamd
** Reply to message from Bob Beck <[EMAIL PROTECTED]> on Mon, 19 Mar 2007 09:40:52 -0600 >* Sid Carter <[EMAIL PROTECTED]> [2007-03-19 03:25]: > >> > Regardless, if NOOP is in the SMTP standard, and spamd does not handle >> > it correctly, that is a bug that needs to be fixed. > > Bullshit. that's not a good enough reason - spamd does not >implement all of smtp, and never will. saying "it's in the smtp >standard" is the wrong way to get anything into spamd :) > > OTOH, if there is real stuff from the century of the fruit bat >that uses this I'll put it in. If it's someone's BBS mailer from >the century of Def Leppard and Mullets I'm not bloating the code one line >to deal with it. I've asked the poster for details. Anyone else who >can confirm real stuff needing NOOP please let me know. I certainly don't want to see spamd (or anything else) made overcomplicated by "somebody might need that" code, but wouldn't it make sense to include anything which is both in the standards and truly trivial to implement sufficiently for spamd's purposes? It seems to me that in those cases the cost to implement and maintain is so low as to be worthwhile even if it only avoids relatively unlikely problems. Dave -- Dave Anderson <[EMAIL PROTECTED]>
Re: NOOP and Spamd
* Sid Carter <[EMAIL PROTECTED]> [2007-03-19 03:25]: > > Regardless, if NOOP is in the SMTP standard, and spamd does not handle > > it correctly, that is a bug that needs to be fixed. Bullshit. that's not a good enough reason - spamd does not implement all of smtp, and never will. saying "it's in the smtp standard" is the wrong way to get anything into spamd :) OTOH, if there is real stuff from the century of the fruit bat that uses this I'll put it in. If it's someone's BBS mailer from the century of Def Leppard and Mullets I'm not bloating the code one line to deal with it. I've asked the poster for details. Anyone else who can confirm real stuff needing NOOP please let me know. -Bob
Re: NOOP and Spamd
"Darren Spruell" <[EMAIL PROTECTED]> writes:
> On 3/18/07, Sid Carter <[EMAIL PROTECTED]> wrote:
>> greylisting. On further investigation, we found out that the MS Mail
>> servers send a NOOP before they start sending other SMTP commands and
>> spamd returns a 451 even for a NOOP causing the SMTP connection to
>> terminate and the connecting mail server doesn't even get greylisted,
>> since it hasn't even sent a "MAIL FROM" and "RCPT TO".
>>
> Might be useful if you would include details, and lots of them, on a
> subject like this. "MS Mail Servers" is generic and meaningless; is it
> Exchange? Is it the SMTP Server? Something else? What software
> version(s)? OSes and versions?
I would just connect back to the IP which was showing this sympton and
those gave me the greeting as "Microsoft Mail Server". I could be wrong
though.
> More than anything, packet captures illustrating the behavior would be
> useful too.
Packet capture enclosed, taken on March 16th, before we applied the NOOP
patch.
Sid
11:05:23.401112 IP mail.client.57542 > spamd.server.smtp: . ack 3849587282 win
5840
[EMAIL PROTECTED]
R.A.
b...
11:05:24.086139 IP spamd.server.smtp > mail.client.57542: P 1:2(1) ack 0 win
17376
[EMAIL PROTECTED]@.3..*..1...t
RB.C..%.
b...
11:05:24.127337 IP mail.client.57542 > spamd.server.smtp: . ack 2 win 5840
[EMAIL PROTECTED]
S...
...5b...
11:05:25.075553 IP spamd.server.smtp > mail.client.57542: P 2:3(1) ack 0 win
17376
[EMAIL PROTECTED]@.*..1...t
SB.C
b..5b
11:05:25.119287 IP mail.client.57542 > spamd.server.smtp: . ack 3 win 5840
[EMAIL PROTECTED]
T...
b...
11:05:26.012268 IP spamd.server.smtp > mail.client.57542: P 3:4(1) ack 0 win
17376
[EMAIL PROTECTED]@.3,..*..1...t
TB.C..s.
b...a
11:05:26.052768 IP mail.client.57542 > spamd.server.smtp: . ack 4 win 5840
[EMAIL PROTECTED]
U./.
b...
11:05:27.137071 IP spamd.server.smtp > mail.client.57542: P 4:5(1) ack 0 win
17376
[EMAIL PROTECTED]@.5...*..1...t
UB.C.x..
b...s
11:05:27.180269 IP mail.client.57542 > spamd.server.smtp: . ack 5 win 5840
[EMAIL PROTECTED]
V...
...fb...
11:05:28.072700 IP spamd.server.smtp > mail.client.57542: P 5:6(1) ack 0 win
17376
[EMAIL PROTECTED]@.*..1...t
VB.C
b..fi
11:05:28.112502 IP mail.client.57542 > spamd.server.smtp: . ack 6 win 5840
[EMAIL PROTECTED]
W.[.
b...
11:05:29.037260 IP spamd.server.smtp > mail.client.57542: P 6:7(1) ack 0 win
17376
[EMAIL PROTECTED]@. ...*..1...t
WB.C.~?.
b...l
11:05:29.078219 IP mail.client.57542 > spamd.server.smtp: . ack 7 win 5840
[EMAIL PROTECTED]
X...
...$b...
11:05:30.037350 IP spamd.server.smtp > mail.client.57542: P 7:8(1) ack 0 win
17376
[EMAIL PROTECTED]@.;...*..1...t
XB.C
b..$i
11:05:30.077915 IP mail.client.57542 > spamd.server.smtp: . ack 8 win 5840
[EMAIL PROTECTED]
Y...
b...
11:05:31.027281 IP spamd.server.smtp > mail.client.57542: P 8:86(78) ack 0 win
17376
[EMAIL PROTECTED]@..m..*..1...t
YB.C
b...sk.boing.org.nz ESMTP spamd I
11:05:31.069865 IP mail.client.57542 > spamd.server.smtp: . ack 86 win 5840
[EMAIL PROTECTED]
b...
11:05:31.069867 IP mail.client.57542 > spamd.server.smtp: P 0:30(30) ack 86 win
5840
[EMAIL PROTECTED]
b...NOOP
11:05:31.070423 IP spamd.server.smtp > mail.client.57542: P 86:134(48) ack 30
win 17376
[EMAIL PROTECTED]@..2..*..1...t
.B.C
b...451 Temporary failure, please
11:05:31.070541 IP spamd.server.smtp > mail.client.57542: F 134:134(0) ack 30
win 17376
[EMAIL PROTECTED]@.:3..*..1...t
.B.C..}.
b...
11:05:31.111720 IP mail.client.57542 > spamd.server.smtp: P 30:36(6) ack 134
win 5840
E..:[EMAIL PROTECTED]
.m..
b...QUIT
11:05:31.111764 IP spamd.server.smtp > mail.client.57542: R
3849587415:3849587415(0) win 0
E..([EMAIL PROTECTED]@.*..1...t
.
P...
11:05:31.111843 IP mail.client.57542 > spamd.server.smtp: F 36:36(0) ack 135
win 5840
[EMAIL PROTECTED]
b...
11:05:31.111866 IP spamd.server.smtp > mail.client.57542: R
3849587416:3849587416(0) win 0
E..([EMAIL PROTECTED]@.M...*..1...t
.
P...
11:05:35.784386 IP mail.client.57557 > spamd.server.smtp: S
1132947596:1132947596(0) win 5840
E..<[EMAIL PROTECTED]:..1*.C.h.{K.
11:05:35.784471 IP spamd.server.smtp > mail.client.57557: S
3660589841:3660589841(0) ack 1132947597 win 16384
E..@&[EMAIL PROTECTED]@[EMAIL PROTECTED]
v.,1
11:05:35.824111 IP mail.client.57557 > spamd.server.smtp: . ack 1 win 5840
[EMAIL PROTECTED];..1*.C.h
Re: NOOP and Spamd
"Shawn K. Quinn" <[EMAIL PROTECTED]> writes: > On Mon, 2007-03-19 at 14:04 +0800, Lars Hansson wrote: >> He probably mean MS Mail, an ancient Microsoft mail system >> that no sane person should be running in 2007. > > Regardless, if NOOP is in the SMTP standard, and spamd does not handle > it correctly, that is a bug that needs to be fixed. A typical response from spamd: # telnet shear.ucar.edu smtp Trying 192.43.244.163... Connected to shear.ucar.edu. Escape character is '^]'. 220 shear.ucar.edu ESMTP spamd IP-based SPAM blocker; Mon Mar 19 02:42:20 2007 helo openbsd.org 250 Hello, spam sender. Pleased to be wasting your time. noop 451 Temporary failure, please try again later. Connection closed by foreign host. # And this one from the SMTP RFC 821: NOOP (NOOP) This command does not affect any parameters or previously entered commands. It specifies no action other than that the receiver send an OK reply. This command has no effect on any of the reverse-path buffer, the forward-path buffer, or the mail data buffer. Sid
Re: NOOP and Spamd
On Mon, 2007-03-19 at 14:04 +0800, Lars Hansson wrote: > He probably mean MS Mail, an ancient Microsoft mail system > that no sane person should be running in 2007. Regardless, if NOOP is in the SMTP standard, and spamd does not handle it correctly, that is a bug that needs to be fixed. -- Shawn K. Quinn <[EMAIL PROTECTED]>
Re: NOOP and Spamd
Darren Spruell wrote: On 3/18/07, Sid Carter <[EMAIL PROTECTED]> wrote: Might be useful if you would include details, and lots of them, on a subject like this. "MS Mail Servers" is generic and meaningless; He probably mean MS Mail, an ancient Microsoft mail system that no sane person should be running in 2007. --- Lars Hansson
Re: NOOP and Spamd
On 3/18/07, Sid Carter <[EMAIL PROTECTED]> wrote: Hi, I am currently running OpenBSD 4.0 as a greylisting server. We have found that many Microsoft Mail Servers/Mail Marshal cannot get past the greylisting. On further investigation, we found out that the MS Mail servers send a NOOP before they start sending other SMTP commands and spamd returns a 451 even for a NOOP causing the SMTP connection to terminate and the connecting mail server doesn't even get greylisted, since it hasn't even sent a "MAIL FROM" and "RCPT TO". I've seen no mention of this in the archives, so was wondering if this is intended and if there is a permanent fix for this. We've temporarily patched spamd.c, so that spamd does nothing on a NOOP command as required by the SMTP RFC and we've seen that the MS Mail servers get properly greylisted and subsequently whitelisted. Might be useful if you would include details, and lots of them, on a subject like this. "MS Mail Servers" is generic and meaningless; is it Exchange? Is it the SMTP Server? Something else? What software version(s)? OSes and versions? More than anything, packet captures illustrating the behavior would be useful too. DS
NOOP and Spamd
Hi, I am currently running OpenBSD 4.0 as a greylisting server. We have found that many Microsoft Mail Servers/Mail Marshal cannot get past the greylisting. On further investigation, we found out that the MS Mail servers send a NOOP before they start sending other SMTP commands and spamd returns a 451 even for a NOOP causing the SMTP connection to terminate and the connecting mail server doesn't even get greylisted, since it hasn't even sent a "MAIL FROM" and "RCPT TO". I've seen no mention of this in the archives, so was wondering if this is intended and if there is a permanent fix for this. We've temporarily patched spamd.c, so that spamd does nothing on a NOOP command as required by the SMTP RFC and we've seen that the MS Mail servers get properly greylisted and subsequently whitelisted. Sid
