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.
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?
It's up to the external command to handle an EOF condition
appropriately. The spawn daemon just waits until the external
command decides to terminate.
In your case awk detects EOF on input and terminates, but apparently
netcat doesn't.
Netcat can. I can tell it to close the connection as soon as
it receives an EOF. But is that the appropriate behavior?
To handle mail with SMTP, use software that understands the SMTP
protocol.
"The simplest content filter just copies SMTP commands and data
between its inputs and outputs." says the FILTER_README. No
understanding required. So I thought I'd try it. Here I've
found out otherwise; it is also necessary to understand what
happens when TCP close terminates SMTP early.
It seems sensible to ask here because here there are people
experienced with the corner cases of smtp, and postfix's
relationship with them. There are enough "should"s,
rather than "must"s, in the SMTP standard and it seems
there's enough wiggle room for plenty of MTA
interoperability issues that I felt
better asking the experts than trying to reason my way
through all the relevant states in an SMTP state machine
using the RFC as a guide. Even if I got it right there
might be things about postfix I need to know to understand
what will happen in the various cases.
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.
So, the simplest possible smtp filter setup in master.cf is
either of the form:
localhost:10025 inet n n n - 10 spawn
user=filter argv=/bin/nc localhost 10026
or of the form:
localhost:10025 inet n n n - 10 spawn
user=filter argv=/bin/nc -q 0 localhost 10026
The latter tells netcat to shut down it's connection to smtpd
immediately upon receiving EOF.
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.
Thank you for your time.
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
