[Mimedefang] SMTP Pipelining, and GREYLISTING

[Cormack, Ken]

Steffen,

As I understand the greylisting implimentation suggested by a member of this
list (and further explained by David S.), per the RFCs (821 and 2821) that
preceded pipelining, the client SMTP host is supposed to check that AT LEAST
ONE "RCPT TO:" succeeded, BEFORE issuing the DATA command.

Greylisting (as it's implimented here), will tempfail a message as soon as
it receives a recpient to be greylisted.  At that point, a good client will
NOT blindly ignore the 4.X.X and continue on, sending the DATA command.

"Bad" clients that ignore this 4.X.X, and continue on to send the DATA
command, are then given a 5.X.X permanent failure code.

With pipelining as I understand it, it is entirely possible for the sending
client SMTP host to "batch up" commands, and send them in a burst.  If that
pipelined "batch" includes "EHLO..., MAIL FROM:, RCPT TO:, and DATA", then
when greylisting steps in at the RCPT TO, sends a temp fail, and finds that
the sending client has "apparently ignored the 4.X.X error" and has already
sent the DATA command, then the greylisting server will FAIL the message.

Disabling support for pipelining at the server SMTP host, will allow the
conversation to more properly react to a greylisting tempfail, at the cost
of a couple extra packets.

As for the paragraph you reference, from RFC 2920, I suspect that just as
there are mailers that only partially impliment, incorrectly impoliment, or
choose to ignore portions of rfc821/2821, I suspect there would be
pipeline-capable hosts that only partially impliment, incorrectly impliment,
or partially ignore RFC 2920.

KEN CORMACK, RHCE
Sr. UNIX Systems Analyst,
    Open Systems Group
Sr. Software Analyst,
    TSG Midrange Systems Group
AFFILIATED COMPUTER SERVICES, INC.

"If that that is 'is' is that that is not 'not is', is that that is 'not is'
that that is not 'is'?  It is!" - Ken Cormack

"Sendmail administration is not black magic.  There are legitimate technical
reasons why it requires the sacrificing of a live chicken." - Unknown

-----Original Message-----
From: mimedefang-bounces at lists.roaringpenguin.com
[mailto:mimedefang-bounces at lists.roaringpenguin.com]On Behalf Of Steffen
Kaiser
Sent: Friday, March 26, 2004 8:04 AM
To: mimedefang at lists.roaringpenguin.com
Subject: Re: [Mimedefang] SMTP Pipelining, and GREYLISTING


On Thu, 25 Mar 2004, Cormack, Ken wrote:

Hello Ken,

please forgive my ignorance, but what problem is this thread about
actually? And why is pipelining a problem with greylisting only?
This kicks in whenever the server (temp-) fails a recipient, but accepts
the SMTP dialogue in advance (aka pipelining).

What do I miss?

Actually, if you read the SMTP RFC, the client may always sent the whole
message to your server, regardless wether or not it recieved a negative
response, it's the duty of the server to act as a bitbucket in this case.

However, does this paragraphe RFC2920:
  "Client SMTP implementations that employ pipelining MUST check ALL
   statuses associated with each command in a group. For example, if
   none of the RCPT TO recipient addresses were accepted the client must
   then check the response to the DATA command -- the client cannot
   assume that the DATA command will be rejected just because none of
   the RCPT TO commands worked.  If the DATA command was properly
   rejected the client SMTP can just issue RSET, but if the DATA command
   was accepted the client SMTP should send a single dot."

imply that the client have to wait for the response of DATA?

Bye,

-- 
Steffen Kaiser
_______________________________________________
Visit http://www.mimedefang.org and http://www.canit.ca
MIMEDefang mailing list
MIMEDefang at lists.roaringpenguin.com
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang