Note: When I wrote this email I supplied 3 attachments, the files both6, both7, and both8. However the message bounced because of it's size, so I am attaching only the both6 libpcap dump. I am happy to supply the other dumps, or whatever else may be helpful.
On 09/11/2008 05:55:27 AM, Wietse Venema wrote:
Karl O. Pinc: > > On 09/10/2008 06:14:44 PM, Wietse Venema wrote: > > Karl O. Pinc: > > > When there's more than one subscriber the same thing > > > happens for mail sent to the first subscriber, but > > > then the same message is sent to the second subscriber. > > > Again, smtp sends a DATA command, gets back a 354, > > > sends the message, ends with a period, and gets > > > a 250 reply back. At that point things have changed > > > because the smtp side does not send a QUIT, instead it > > > closes it's side of the TCP connection with a FIN, ACK. > > > I presume that at this point spawn sends awk an EOF on stdin > > > because the process tree then looks like this: > > > > Nope, spawn does not close connections. Nor does it inform > > the external command that a connection goes away. > > I did not say that spawn closed the connection. I said _smtp_ sent > a FIN/ACK and closed it's side of the TCP connection to > spawn. At that point spawn can still send to smtp, just not > the reverse. The smtp side initiates the TCP close handshake. > I'm sorry if this was not clear. Nope, spawn does not inform the external command that a connection goes away.
I get the feeling that this is an exchange about what the word "inform" means. I have been wildly off the mark in the past through so I'll proceed as if that is presently the case. Please don't take this as antagonistic.
> Spawn must inform the external command that no more data is > available on the connection by closing the stdin > of the external command. Otherwise awk would not have terminated. > Am I misunderstanding? Yes.
Ok. What does it mean when the external command run by spawn receives an EOF on STDIN?
> I also thought you'd want to hear of apparent inconsistencies > in the postfix smtp program behavior, sending QUIT when > filtering mail sent to the first recipient of a message > but not to the second, although I'm not interested in > pursuing that if you're not. Only if I see the evidence itself. I am less interested in an eye witness's INTERPRETATION of that evidence. This may sound like being a rude hostile bastard, but those are my rules.
That's completely fair. I can't even think of an alternative.
I had previously attached traffic dumps showing that the postfix
smtp process is not sending a QUIT, but is closing the connection.
However, some of my code, the filter, was involved.
Now it occurs to me that the simplest possible filter is
no filter at all. I setup a test so that after queue filtering
goes straight from postfix smtp to postfix
smtpd by adding the following lines to master.cf:
# Try sending smtp straight to smtpd.
# The transport that invokes the filter
mfilterx unix - - n - 1 smtp
-o smtp_send_xforward_command=yes
-o disable_mime_output_conversion=yes
-o smtp_generic_maps=
-o smtp_bind_address=127.0.0.1
# Run the content filter
#127.0.0.1:11025 inet n n n - 1 spawn
# user=mfilter argv=/usr/local/sbin/mailman-filter 127.0.0.1
11026
# Reinject mail back into postfix
127.0.0.1:11025 inet n - n - 1 smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_milters
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
I captured the traffic in 3 scenarios, attached.
both6 is the file that shows the problem. (Or maybe
it's not a problem, but it's the behavior I'm asking
about.) The email message has
2 recipients. This time the second recipient, not the first
as in the previously supplied traffic captures, does not get
the QUIT command. Instead the Postfix smtp command
closes the connection. You can see this stream in packets 19-36.
In the captures where I see no SMTP QUIT, both the
ones attached here and the captures attached to one
of my previous messages in this thread, the common
denominator is that the QUIT does not happen when the
mail is destined for local delivery.
(There are actually 3 TCP streams in the both6 capture,
two for the external recipient as the mail goes out and
is bounced back (the 1st and 3rd stream) and 1 for the
local delivery (the 2nd stream.))
The both7 file shows a single recipient to a remote
destination (that is ultimately delivered locally
so there are 2 streams.) This stream has a SMTP
QUIT.
The both 8 file shows a single recipient to a
local destination. This stream also has a
SMTP QUIT as expected.
Are the packet captures the kind of evidence you
require or are you talking about being able
to reproduce the problem on your system?
I've not sent postconf output, but I can do
that if it'd help.
I'm not running the latest Postfix, perhaps
something has changed. If so it'd be nice
but not essential to know when the change
was made.
It's been a while since I started this thread so
I'll repeat the version information.
Debian etch
Postfix 2.3.8-2+etch1
> Your response above implies that the latter is recommended, > that it won't cause any problems when the SMTP protocol is > terminated early by TCP closure. I'm fine with that, but I do > want to verify my reading of your response before putting > such a configuration into production. Stop this. I never suggested that nc should exit immediately. A proper SMTP proxy implementation will recognize EOF on input, take appropriate action and and terminate after completing all unfinished write operations.
Sorry, it did not occur to me that nc would terminate without
flushing it's unfinished write operations. (I've looked
at the code and it does not, all buffers are flushed
before termination. Unfortunately, the -q
option used by my code appears to be a Debian-only
patch.)
My main question asked in the post that started this thread
was, more or less, "What is the appropriate action to
take as a proxy to smtpd when the receiving an EOF
on input after smtpd has received the message
and sent a .250 2.0.0 Ok: queued as ...' reply
but before receiving a QUIT from the sending
smtp process?" I can guess based on the Postfix
behavior demonstrated in the attached libpcap
captures, but I'd rather ask. The other half
of the coin is that I was not expecting
that QUIT would ever be omitted; it's either
a bug or some sort of deliberate Postfix shortcut I'm
not aware of. If it turns
out that Postfix has been changed so that
there is always a QUIT then I don't need this
question answered.
Thank you for your time.
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
both6
Description: Binary data
