In message <52699767.2050...@shaw.ca>, you wrote: >Ronald F. Guilmette wrote: >> In message<5268663c.4040...@stemsystems.com>, >> Uri Guttman<u...@stemsystems.com>wrote: >> >>> i think a blank line with . will end input to smtp servers. try that too >>> in the line after the from field. >> >> DING DING DING!!! >> >> Give that man a cupie doll, because he's the winner of today's >> perplexing puzzle test! >> >> In short, yes, when I first read the above sentence, I said to myself >> "No way! I know that when input is coming in ``over the wire'' to a >> normal SMTP server *and* when it is already in ``DATA'' (input message >> collection) SMTP protocol mode, *then* a period alone on a line ends >> input, *however* in this case Postfix is reading the message from STDIN, >> and so there is really no need for that period-alone-on-a-line bit of >> SMTP protocol to apply in this case, because EOF in this case can be >> signalled by... well... an actual EOF, of course!" > >stdin (and stdout) are part of a stream protocol and as such are not >about files and do not signal End-Of-File which is part of why emails >use the single period to signal the end of the message.
I'm not sure that I can even properly parse what you just said, but if I am parsing what you said correctly, then I disagree. C language stdio streams _do_ most definietly signal EOF. See: man 3 feof In the case of *bi-directional* network *sockets* used for SMTP transactions however, it is necessary to use some sort of in-band signaling (i.e. the period alone on a line) to signal the end of the message text, because after that, the socket must remain open so that the client can receive back and then properly interpret and react to whatever following XXX numeric response code the server decides to send back, just after the client has sent the end-of-message indicator. But when Postfix is reading a message from stdin, and when it gets to the end of the message... well, there isn't any more interaction, and in fact their could not be, because this is just uni-directional data flow. The message comes in on Postfix's stdin and then its done and that's it. So in this case, to my way of thinking at least, it is downright nonsensical that in this context Postfix is even looking for (or recognizing) the specialized in-band end-of-message indicator that, of necessity, had to be invented for and used with by-directional SMTP transactions/conversations. Sigh. I'll would wager that Wietse probably feels the same way, but that, as is often the case, he was constrained by the need to implement odd bits of behavior like this in order to be maximally compatible with the pre-existing Sendmail behavior. :-( Anyway, I'll be asking about this.. on the appropriate mailing list, of course. (It just "feels" wrong to me, and is definitely *not* what I would call ``intutive'' behavior.) Regards, rfg -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
