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!"

But then, just to be sure, I tried it myself, and lo and behold, Postfix
*does* apparently treat period-on-a-line-alone as the end of the input
message data, *even when* it is reading the message from STDIN (which, to
my way of thinking, is _totally_ bizzare, unnecessary, and certainly un-
expected).

So thanks!  This clears up the mystery pretty completely, I think.  The
attacker no doubt used the HTTP %xx notation to smugle in some newlines,
and also stuck a period in there somewhere, and that would completely
explain the content of the two exceptionally mysterious messages I saw.
(Thankfully, all this means that I was _most probably_ never actually
security compromised in any way.)

>> Well, I added to the script some rudimentary filtering/validation of
>> the input strings in question also.
>
>you need more than rudimentary filtering. make sure the from field is 
>one string, no newlines or anything but printable text.

Um, yes, sorry. I failed to make my meaning plain.

When I said "rudimentary filtering" of the input strings, what I really
had intended to say was that I implemented "quick and dirty" filtering of
the strings in question that is grotesquely *over*-restrictive in each
case.  (The input validation steps for both name and e-mail address
*should*, ideally, be much looser than what I have now, but I am too
busy just now to deal with it.)

For example, if you try *now* to use my contact form and if you try to
use any ``funny'' characters at all in either your name or your e-mail
address, the current data collection script will basically refuse that
data and then tell you to try again.

(I hope that nobody from Europe who has umlauts or grave accents in the
correct spellings of their names needs to use that form to contact me 
anytime soon. :-)


Regards,
rfg

-- 
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/


Reply via email to