Jon Ribbens <jon+usenet@unequivocal.co.uk> writes:
Broken, or confused? Compare the following two bug reports, for example:
http://bugs.php.net/bug.php?id=24400
http://bugs.php.net/bug.php?id=35659

(Obviously what it *should* do is take an array of headers, not a
string, and do some more internal validation of the data received,
which would solve most of the problem anyway)

--
Chris

In article <87y7zvznyg.fsf@dinopsis.dur.ac.uk>, Chris Morris wrote:
The developers are confused, so the function is broken. The whole
thing is a mish-mash of arbitrary and poorly-defined arguments that
are jumbled together in badly-documented ways to produce a
hard-to-predict stitched-together output that's then thrown whole at
the local 'sendmail' binary that will then respond to it in even
harder-to-predict ways in the vain hope that the 'right thing' will
happen.

The unmitigated gall of the developers in writing "Some poor quality
Unix mail transfer agents replace LF by CRLF automatically" in the
documentation when in fact it's their own ignorance that's at fault
is staggering. The fact that the entire response to the second bug
you list above is "not a bug, won't fix" just goes to illustrate that
no matter how long you wait, the PHP developers never acquire clue.

Message-ID: <1nodd3-l98.ln1@asgard.webthing.com> from Nick Kew contained
the following:

It's a requirement of the application

Well I think the advice of Jon and Mark will help reduce that risk.

--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011

In article <l6k802hn5ms8cqbrcc0h1408754746g9rs@4ax.com>, Geoff Berrow wrote:
Yes, I'm not sure what Nick was getting at there. It looked like he
was saying all systems which allow users to register with an email
address are incorrect in some way.

The important things are: (a) make sure the message subject and
content are not under an attacker's control and (b) make sure they
can't send to more than one address per invocation. Also it would be
a very good idea to rate-limit the number of emails it can send to a
particular address (e.g. perhaps one per day) and the number of emails
it can send at all (e.g. perhaps one per second, depending on the
volume of traffic to the site).

On Tue, 28 Feb 2006, Geoff Berrow wrote:

If the application requires you to do things which create a spam
relay, and will consequently result in you getting blacklisted for
such misbehaviour, then think again. Don't think the spammers won't
find you - plenty have tried that before and learned their lesson
(yes, it's happened to us too, in the distant past, so I can speak
with some experience).

Based on what I've read so far on this thread, I think you're still at
risk. Web security is a serious matter - it isn't solved by looking
for a few known abuse possibilities. It needs a fundamental analysis
from the ground up. And anything which allows some untrusted user to
supply an email address, which may or may not really belong to them,
is wide open to abuse. "Hence or otherwise deduce...".

In article <l6k802hn5ms8cqbrcc0h1408754746g9rs@4ax.com>, Geoff Berrow wrote:

I'd like to add that everyone's input on this topic has been informative
to me - keeping content of headers, notably subject, seperate from body
content, and not having the users email addy as the originating address,
including it in the body instead and hardcoding an address from your own
domain instead, are both good ideas I hadn't really considered before.
Definitely something to think about when I next re-write the script.
Thanks you.

--
Gazza
Mobile Number Network Checker - http://mnnc.net/
Leovanna Leonbergers - http://leovanna.co.uk/
Scarlet Town - http://scarlettown.co.uk/

On Tue, 28 Feb 2006 20:54:40 +0000, Alan J. Flavell put finger to
keyboard and typed:

The problem is that the only reliable way to confirm opt-in to a
mailing list, for example, is to send an email back to the address
supplied in the form. Not doing so is a very big no-no when it comes
to responsible list management. So there are some applications where
you have no choice but to send an email to the address given by the
user, as sending an email to it is precisely the reason why you're
asking for it. The important thing is to ensure that if a user does
supply an address other than his/her own, the worst that the real
owner of the address can suffer is a single unwanted confirmation
request.

Mark
--
Visit: http://www.CorporateContact.info - phone and email contacts for Amazon, Paypal, eBay and lots of other hard-to-contact organisations
Listen: http://www.goodge.co.uk/files/dweeb.mp3 - you'll love it!

On Tue, 28 Feb 2006, Mark Goodge wrote:

Absolutely. But you need to be completely and utterly in control of
the response mail which is generated, as well as having stringent rate
controls on what is sent out, or else you're open to being used for
either spam relaying or denial of service abuse, respectively.

Yes, and with no content which has been supplied by a spammer.

But achieving this, without loopholes, is non-trivial! As has, sadly,
been proved over, and over, and over again in practice.

On Sun, 26 Feb 2006 23:22:54 +0000, David M wrote:

I'm going to fly this kite again, because I think it has legs(!). This is
only an alternative to Capcha -- it has nothing to do with preventing
address/message injection into forms. Only careful writing of the mail
submission can thwart that.

You could rely on the fact that most spam bots will request the page with
the form on it and submit the form relatively soon after that. The idea
would be to generate a non-forgeable time token in a hidden field which
gets checked by the server script. When the form gets written (you must
use a server-side script for this) you include two fields. One has the
time the form was generated and the second contains the MD5 hash (say) of
this time concatenated with a string known only to the server. The server
rejects posts (guest-book entries, blog comments or whatever) if they
arrived too soon after the form was sent out. Of course, if spam bots are
happy to wait a bit then this won't work, but it is so simple to do that I
think it is worth a try.

If anyone has a guest book or blog that gets frequently spammed, I'd be
happy to try to add this fix if only to rule it out so I never post the
idea again!

--
Ben.

<uk.net.web.authoring , Ben Bacarisse , ben.usenet@bsb.me.uk>
<pan.2006.02.28.23.49.03.277029@bsb.me.uk>
<Tue, 28 Feb 2006 23:49:03 +0000>

The guestbook i'm about halfway through writing sends the admin the full
guestbook entry via email and has 2 links at the bottom of the email .

1 - verify
2 - abuse

Clicking on either will mark the guestbook entry accordingly & in the
case of abuse or spam it wont show up on the guestbook webpages as it
will become invisible for want of a better description .

Or if the admin is surfing the guestbook - they can click on the admin
link and mark it like the 2 options above .

Until a guestbook entry is verified it only displays text like THIS
GUESTBOOK ENTRY IS WAITING FOR VERIFICATION sort of thing .

So even if the guestbook does get spammed its only the admin who will
see the spammers text .

Nothing is ever going to be perfect though .


--
(c) The Amazing Krustov