Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #9806 > unrolled thread

FORMS, validating mail was sent

Back to article view | Back to comp.lang.php

Contents

  FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-20 13:40 -0400
    Re: FORMS, validating mail was sent Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 13:53 -0400
    Re: FORMS, validating mail was sent "J.O. Aho" <user@example.net> - 2013-06-20 20:18 +0200
    Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 19:24 +0100
      Re: FORMS, validating mail was sent Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 14:40 -0400
      Re: FORMS, validating mail was sent gordonb.vb4vo@burditt.org (Gordon Burditt) - 2013-06-20 14:44 -0500
        Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-20 22:03 +0100
        Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-21 14:06 -0400
        Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-22 11:42 -0400
        Re: FORMS, validating mail was sent Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-23 13:13 +0200
          Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-23 12:22 +0100
            Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-23 13:07 -0400
          Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-23 13:00 -0400
            Re: FORMS, validating mail was sent "J.O. Aho" <user@example.net> - 2013-06-23 20:22 +0200
              Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-23 14:53 -0400
          Re: FORMS, validating mail was sent gordonb.4qaft@burditt.org (Gordon Burditt) - 2013-06-24 14:43 -0500
            Re: FORMS, validating mail was sent "Peter H. Coffin" <hellsop@ninehells.com> - 2013-06-24 15:09 -0500
            Re: FORMS, validating mail was sent Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-25 15:19 +0200
              Re: FORMS, validating mail was sent Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-25 10:11 -0400
                Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-25 11:43 -0400
              Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-25 11:32 -0400
              Re: FORMS, validating mail was sent gordonb.htsnc@burditt.org (Gordon Burditt) - 2013-06-27 10:57 -0500
                Re: FORMS, validating mail was sent Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-06-27 21:13 +0200
              Re: FORMS, validating mail was sent Arno Welzel <usenet@arnowelzel.de> - 2013-06-28 11:43 +0200
    Re: FORMS, validating mail was sent gordonb.k0cb7@burditt.org (Gordon Burditt) - 2013-06-20 15:46 -0500
      Re: FORMS, validating mail was sent Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-20 17:03 -0400
        Re: FORMS, validating mail was sent gordonb.udxst@burditt.org (Gordon Burditt) - 2013-06-21 19:26 -0500
          Re: FORMS, validating mail was sent Jerry Stuckle <jstucklex@attglobal.net> - 2013-06-21 20:36 -0400
        Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-22 12:04 -0400
      Re: FORMS, validating mail was sent Christoph Michael Becker <cmbecker69@arcor.de> - 2013-06-20 23:39 +0200
        Re: FORMS, validating mail was sent Tim Streater <timstreater@greenbee.net> - 2013-06-21 10:11 +0100
          Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 11:25 +0100
            Re: FORMS, validating mail was sent Tim Streater <timstreater@greenbee.net> - 2013-06-21 12:27 +0100
              Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 17:59 +0100
                Re: FORMS, validating mail was sent Tim Streater <timstreater@greenbee.net> - 2013-06-21 18:25 +0100
                  Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 23:43 +0100
                    Re: FORMS, validating mail was sent Tim Streater <timstreater@greenbee.net> - 2013-06-22 13:45 +0100
            Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-22 12:20 -0400
      Re: FORMS, validating mail was sent "Peter H. Coffin" <hellsop@ninehells.com> - 2013-06-20 17:27 -0500
        Re: FORMS, validating mail was sent The Natural Philosopher <tnp@invalid.invalid> - 2013-06-21 07:57 +0100
      Re: FORMS, validating mail was sent Twayne <nobody@spamcop.net> - 2013-06-22 12:02 -0400
    Re: FORMS, validating mail was sent GravyCode <matty023@gmail.com> - 2013-06-21 11:30 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#9885

On 2013-06-25 9:19 AM, Thomas 'PointedEars' Lahn wrote:
> Gordon Burditt wrote:
>
...

>>
>> I certainly hope that a self-described "near newbie" is not going to try
>> to implement something of the scale of Gmail.

At least that's correct; this is a small, semi-social website for the 
graduating class of 1964, with 52 graduates and only half of them on 
e-mail, so it's small.
    Because of that, I'm using this additional form as a learning 
experience fIor myself. I have a mostly canned form already there and 
appaarently working very well re spam, XSS, etc..
    It's interesting how stupid some dummies can assume a newbie might 
be based on nothing but attempts for assistance.

>>
>> A self-described "near newbie" is not going to know all the issues
>> in properly validating things that go into mail headers.  I won't
>> encourage them to put up email forms (or try do-it-yourself parachute
>> packing and skydiving) until they learn more.

Actually as it turns out, Headers are not required for mail() at  my 
servers. Some dummie told me they were but that was straightened out 
quickly, fortunately. As I've mentioned before I verify things i'm not 
familiar with to minimize false starts and other problems.

>
> That the person you are advising is not knowledgable is not an excuse for
> your misinformation.
>
>>> Valid From addresses include all that meet the Address Specification in
>>> RFC 5322, instead.  This is a purely *syntactical* determination.  It is
>>> the fact that even addresses for which there are no mailboxes at the
>>> sending server can be used in the From header field value, and that
>>> afterwards checking of addresses is unreliable, that allows spammers to
>>> thrive.
>>
>>  From the point of view of sendmail, which is used by default setups in PHP
>> (except for Windows), there are other requirements.  Sendmail doesn't like
>> local users to forge mail in the name of other users.
>
> Nonsense.
    I and my ISP agree with you. Since I have multiple sites there and 
have been a customer for over tehn years, I get pretty great technical 
support responses, and quickly too. My forms are also filtered so as to 
be Plain Text messages only in addition to the other expected safeguards.
    I wish I knew more, but that's what learning is all about,
>
...

>
> Utter nonsense.  An (standards-compliant) “MX” or “A” DNS record *never*
> points to 127.0.0.1.  In particular, an MX record never has an IP address as
> its value, as I have already pointed out.
>
> 127.0.0.1 is specified at most in the local host file, and resolving a
> domain name of a supposed e-mail address will *never* result in 127.0.0.1.

I didn't think so ... thanks.
>
>> However, if the MTA also hosts the sender domain, the
>> check can verify the mailbox exists).
>
> Evidently now you have no clue what you are talking about.

>
...

>
>>> possible to change the Envelope-From with simple PHP commands like mail()

>
>> [more nonsense]
>
> ISTM you need professional help.
>
>
> PointedEars

Thanks - good post.

Twayne`
>

[toc] | [prev] | [next] | [standalone]

#9900

> Utter nonsense.  An (standards-compliant) “MX” or “A” DNS record *never* 
> points to 127.0.0.1.  In particular, an MX record never has an IP address as 
> its value, as I have already pointed out.

You expect spammers, vandals, and viruses to generate standards-compliant
DNS?  Or standards-compliant *anything*?  Wow, I thought that kind
of gullibility died out eons ago.

Standards consist mostly of things *YOU* are responsible for checking,
and a checklist of things for spammers, vandals, and viruses to try
breaking to see if they can bypass any filters that way.  That may
not be the purpose the standards writers intended, but they are
often used that way anyway.

An MX record is not supposed to have an IP address as it's value,
but there is a good chance that if it does (for the destination
address) a good fraction of the mail will be delivered anyway.  When
was the last time you tested whatever MTA you use to see if it will
use such an address?  Some accept it, some don't, and some have an
option.  ISPs using the software with an option may discover that
allowing it anyway reduces customer complaints.  ("Why can't I send
mail to fubar.com through you?  It works from AOL.")

I don't think there are any places in email standards that require
delivery of mail to fail due to an IP address in a MX record.  In
any case, anti-SPAM rules often trump situations where the standards
say mail should be delivered.

> 127.0.0.1 is specified at most in the local host file, and resolving a 

There's nothing wrong with including "localhost" in a nameserver for
a local LAN.

> domain name of a supposed e-mail address will *never* result in 127.0.0.1.

You're wrong, unless you're going to use the "(standards-compliant)"
dodge.  Some people don't know you shouldn't put IP addresses in
MX records, especially those where it seems to work.  Others use
off-in-the-weeds IP addresses to ignore bounce messages from their
mailing lists, something I think violates a reasonable anti-SPAM
policy - they are ignoring requests for removal from the list.
Others use wrongly-pointed MX records to direct distributed attacks.

As to DNS servers not responding:  there are 13 root server names
and at various times I've seen them all individually (so I know
it's not just my ISP off the net) fail to respond.  Sometimes there
were announced outages.

[toc] | [prev] | [next] | [standalone]

#9902

Gordon Burditt wrote:

>> Utter nonsense.  An (standards-compliant) “MX” or “A” DNS record *never*
>> points to 127.0.0.1.  In particular, an MX record never has an IP address
>> as its value, as I have already pointed out.
> 
> You expect spammers, vandals, and viruses to generate standards-compliant
> DNS?

No, you are very confused.

> [non sequitur]
> An MX record is not supposed to have an IP address as it's value,

More, the value of an MX record is never interpreted as an IP address in the 
first place, the same as the value of a CNAME record is never interpreted as 
an IP address by any DNS client implementation that is not FUBAR.

> but there is a good chance that if it does (for the destination
> address) a good fraction of the mail will be delivered anyway.

Pray tell, which host will the mail be delivered to if it cannot be resolved 
in the first place?

> […]
>> 127.0.0.1 is specified at most in the local host file, and resolving a
> 
> There's nothing wrong with including "localhost" in a nameserver for
> a local LAN.

Depends.
 
>> domain name of a supposed e-mail address will *never* result in
>> 127.0.0.1.
> 
> You're wrong, unless you're going to use the "(standards-compliant)"
> dodge.

It is no dodge, it is both the standard *and* the *implementation* of DNS.

> Some people don't know you shouldn't put IP addresses in MX records,
> especially those where it seems to work. 

“Seems” is correct, because MX 127.0.0.1 is equivalent to 127.0.0.1.$ZONE, 
_not_ to 127.0.0.1.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#9912

Am 25.06.2013 15:19, schrieb Thomas 'PointedEars' Lahn:

> Gordon Burditt wrote:
[...]
>> Exim also has "sender verify" (which can be optionally enabled).
>> On starting to receive an incoming message, Exim starts to send a
>> bounce message back to the envelope-sender.  If the bounce message
>> is refused (at the MAIL FROM: and RCPT TO: stage), so is the message.
>> The bounce message is never completely sent (and has no text) so
>> it's never delivered.  If sender DNS or mail server goes down, the
>> message goes nowhere.
> 
> That is the counter-measure I was talking about.  It does not pertain to the 
> “From” header field, but to the *Envelope*-From.  Which is something that 
> you cannot change with PHP's mail().

JFTR: Depending on the platform you use PHP you can - just pass an
optional parameter to sendmail (-f) to override the envelope-From:

mail('to@foobar.example',
  'subject',
  'message',
  'From: from@foobar.example',
  '-f from@foobar.example');

Also see: <http://php.net/manual/en/function.mail.php>


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#9822

> I'm a PHP near-newbie working fairly successfully on creating a secure 
> PHP e-mail (mail()) function. It occurs to me that the only way a user 
> knows (thinks) a form has been sent, is that I tell him so either in a 
> line of code or with a Thank You page.

Since you're a near-newbie, please save the world from having to
block email from your server, and DO NOT put any variables in email
headers, DO NOT put any variables from the user in email headers,
and DO NOT put any variables set in your form in email headers.
Put them in the body of the mail.

Wrong:		 From: $email
Right:		 From: www-data@myserver.hostingco.com

Some servers are going to require that (a) the From: address is
local, (b) the From: address is a valid local user, and perhaps (c)
the user name must match the user id of the code that called the
MTA.  In other words, there might be only one correct From: line
you're allowed to use.

(For a mailing list to customers, you're stuck with a variable
in the To:, Cc:, or Bcc: headers.  )

Wrong:		Subject: Contact form from $email
Right:		Subject: Contact form - read body to tell who it's from.

Wrong:		Subject: Order for $itemname
Right:		Subject: Order



(Consider what happens if $email='me@gmail.com\rCc: victim1@gmail.com,
victim2@gmail.com, victim3@gmail.com, ..., victim99@gmail.com', and
$address (used in the body) contains a 5-page-long ad for body part
enlargement)

>  With that in mind, is there any way with PHP to actually tell that a 
> message was actually sent? That it at least was mailed out?

The return value from the mail() function is about as good as you
can get.  The mail was handed off to the MTA.

> I came across retval() and thought that might be way to do it, but I 
> misinterpreted it, thinking it was a PHP function, which it turns out to 
> not be. Therefore I'm looking for some way to authenticate that the 
> e-mail actually left the server.

It can actually take an incredible number of DNS lookups and alias
file searches to determine if the mail is even *SUPPOSED* to leave
the server (that is, the destination is not local to the server),
especially since shared hosted web servers tend to have lots of
different DNS hostnames all pointing at them.

[toc] | [prev] | [next] | [standalone]

#9824

On 6/20/2013 4:46 PM, Gordon Burditt wrote:
>> I'm a PHP near-newbie working fairly successfully on creating a secure
>> PHP e-mail (mail()) function. It occurs to me that the only way a user
>> knows (thinks) a form has been sent, is that I tell him so either in a
>> line of code or with a Thank You page.
>
> Since you're a near-newbie, please save the world from having to
> block email from your server, and DO NOT put any variables in email
> headers, DO NOT put any variables from the user in email headers,
> and DO NOT put any variables set in your form in email headers.
> Put them in the body of the mail.
>
> Wrong:		 From: $email
> Right:		 From: www-data@myserver.hostingco.com
>
> Some servers are going to require that (a) the From: address is
> local, (b) the From: address is a valid local user, and perhaps (c)
> the user name must match the user id of the code that called the
> MTA.  In other words, there might be only one correct From: line
> you're allowed to use.
>
> (For a mailing list to customers, you're stuck with a variable
> in the To:, Cc:, or Bcc: headers.  )
>
> Wrong:		Subject: Contact form from $email
> Right:		Subject: Contact form - read body to tell who it's from.
>
> Wrong:		Subject: Order for $itemname
> Right:		Subject: Order
>
>
>
> (Consider what happens if $email='me@gmail.com\rCc: victim1@gmail.com,
> victim2@gmail.com, victim3@gmail.com, ..., victim99@gmail.com', and
> $address (used in the body) contains a 5-page-long ad for body part
> enlargement)
>

I will agree not to put UNVALIDATED data in the Subject: line.  But 
proper validation of the data will solve this problem.

I do agree not to put user-supplied data in the To: or From: fields.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9858

>>> I'm a PHP near-newbie working fairly successfully on creating a secure
>>> PHP e-mail (mail()) function. It occurs to me that the only way a user
>>> knows (thinks) a form has been sent, is that I tell him so either in a
>>> line of code or with a Thank You page.
>>
>> Since you're a near-newbie, please save the world from having to
>> block email from your server, and DO NOT put any variables in email
>> headers, DO NOT put any variables from the user in email headers,
>> and DO NOT put any variables set in your form in email headers.
>> Put them in the body of the mail.
>>
>> Wrong:                 From: $email
>> Right:                 From: www-data@myserver.hostingco.com

 
> I will agree not to put UNVALIDATED data in the Subject: line.  But 
> proper validation of the data will solve this problem.

And you expect a self-described "near-newbie" to get that right the
first time?  Note that I didn't call Jerry Stuckle a "near-newbie",
because he's not.

> I do agree not to put user-supplied data in the To: or From: fields.

[toc] | [prev] | [next] | [standalone]

#9859

On 6/21/2013 8:26 PM, Gordon Burditt wrote:
>>>> I'm a PHP near-newbie working fairly successfully on creating a secure
>>>> PHP e-mail (mail()) function. It occurs to me that the only way a user
>>>> knows (thinks) a form has been sent, is that I tell him so either in a
>>>> line of code or with a Thank You page.
>>>
>>> Since you're a near-newbie, please save the world from having to
>>> block email from your server, and DO NOT put any variables in email
>>> headers, DO NOT put any variables from the user in email headers,
>>> and DO NOT put any variables set in your form in email headers.
>>> Put them in the body of the mail.
>>>
>>> Wrong:                 From: $email
>>> Right:                 From: www-data@myserver.hostingco.com
>
>
>> I will agree not to put UNVALIDATED data in the Subject: line.  But
>> proper validation of the data will solve this problem.
>
> And you expect a self-described "near-newbie" to get that right the
> first time?  Note that I didn't call Jerry Stuckle a "near-newbie",
> because he's not.
>

No, but OTOH you're also telling him to unconditionally not do something 
which is very valid.  It is much better to tell him he can do it - but 
must be careful on how it's done.

>> I do agree not to put user-supplied data in the To: or From: fields.
>
>



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#9863

On 2013-06-20 5:03 PM, Jerry Stuckle wrote:
> On 6/20/2013 4:46 PM, Gordon Burditt wrote:

...

>>
>
> I will agree not to put UNVALIDATED data in the Subject: line.  But
> proper validation of the data will solve this problem.
>
> I do agree not to put user-supplied data in the To: or From: fields.
>

Well put.

[toc] | [prev] | [next] | [standalone]

#9825

Am 20.06.2013 22:46, schrieb Gordon Burditt:
>> I'm a PHP near-newbie working fairly successfully on creating a secure 
>> PHP e-mail (mail()) function. It occurs to me that the only way a user 
>> knows (thinks) a form has been sent, is that I tell him so either in a 
>> line of code or with a Thank You page.
> 
> Since you're a near-newbie, please save the world from having to
> block email from your server, and DO NOT put any variables in email
> headers, DO NOT put any variables from the user in email headers,
> and DO NOT put any variables set in your form in email headers.
> Put them in the body of the mail.

Or use at least a good email library which caters for security issues
and other "details" regarding correct headers.

And one should not forget that not everything could be put in the
message body--at least not without proper setting of some headers.

> Wrong:		 From: $email
> Right:		 From: www-data@myserver.hostingco.com
> 
> Some servers are going to require that (a) the From: address is
> local, (b) the From: address is a valid local user, and perhaps (c)
> the user name must match the user id of the code that called the
> MTA.  In other words, there might be only one correct From: line
> you're allowed to use.

Indeed, but the OP may *try* if custom From headers are allowed on his
webspace.

> (For a mailing list to customers, you're stuck with a variable
> in the To:, Cc:, or Bcc: headers.  )

In my limited experience Cc and Bcc headers *might* be blocked by the ISP.

> Wrong:		Subject: Contact form from $email
> Right:		Subject: Contact form - read body to tell who it's from.
> 
> Wrong:		Subject: Order for $itemname
> Right:		Subject: Order
> 
> 
> 
> (Consider what happens if $email='me@gmail.com\rCc: victim1@gmail.com,
> victim2@gmail.com, victim3@gmail.com, ..., victim99@gmail.com', and
> $address (used in the body) contains a 5-page-long ad for body part
> enlargement)
> 
>>  With that in mind, is there any way with PHP to actually tell that a 
>> message was actually sent? That it at least was mailed out?
> 
> The return value from the mail() function is about as good as you
> can get.  The mail was handed off to the MTA.

ACK.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#9844

In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
 Christoph Michael Becker <cmbecker69@arcor.de> wrote:

> Am 20.06.2013 22:46, schrieb Gordon Burditt:
> >> I'm a PHP near-newbie working fairly successfully on creating a secure 
> >> PHP e-mail (mail()) function. It occurs to me that the only way a user 
> >> knows (thinks) a form has been sent, is that I tell him so either in a 
> >> line of code or with a Thank You page.
> > 
> > Since you're a near-newbie, please save the world from having to
> > block email from your server, and DO NOT put any variables in email
> > headers, DO NOT put any variables from the user in email headers,
> > and DO NOT put any variables set in your form in email headers.
> > Put them in the body of the mail.
> 
> Or use at least a good email library which caters for security issues
> and other "details" regarding correct headers.
> 
> And one should not forget that not everything could be put in the
> message body--at least not without proper setting of some headers.
> 
> > Wrong:		 From: $email
> > Right:		 From: www-data@myserver.hostingco.com
> > 
> > Some servers are going to require that (a) the From: address is
> > local, (b) the From: address is a valid local user, and perhaps (c)
> > the user name must match the user id of the code that called the
> > MTA.  In other words, there might be only one correct From: line
> > you're allowed to use.
> 
> Indeed, but the OP may *try* if custom From headers are allowed on his
> webspace.
> 
> > (For a mailing list to customers, you're stuck with a variable
> > in the To:, Cc:, or Bcc: headers.  )
> 
> In my limited experience Cc and Bcc headers *might* be blocked by the ISP.

Well you shouldn't be sending a Bcc: header, now, should you? :-)

And why should it block a cc: header anyway? It's just part of the data.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#9847

On 21/06/13 10:11, Tim Streater wrote:
> In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
> Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>
>> Am 20.06.2013 22:46, schrieb Gordon Burditt:
>> >> I'm a PHP near-newbie working fairly successfully on creating a 
>> secure >> PHP e-mail (mail()) function. It occurs to me that the only 
>> way a user >> knows (thinks) a form has been sent, is that I tell him 
>> so either in a >> line of code or with a Thank You page.
>> > > Since you're a near-newbie, please save the world from having to
>> > block email from your server, and DO NOT put any variables in email
>> > headers, DO NOT put any variables from the user in email headers,
>> > and DO NOT put any variables set in your form in email headers.
>> > Put them in the body of the mail.
>>
>> Or use at least a good email library which caters for security issues
>> and other "details" regarding correct headers.
>>
>> And one should not forget that not everything could be put in the
>> message body--at least not without proper setting of some headers.
>>
>> > Wrong:         From: $email
>> > Right:         From: www-data@myserver.hostingco.com
>> > > Some servers are going to require that (a) the From: address is
>> > local, (b) the From: address is a valid local user, and perhaps (c)
>> > the user name must match the user id of the code that called the
>> > MTA.  In other words, there might be only one correct From: line
>> > you're allowed to use.
>>
>> Indeed, but the OP may *try* if custom From headers are allowed on his
>> webspace.
>>
>> > (For a mailing list to customers, you're stuck with a variable
>> > in the To:, Cc:, or Bcc: headers.  )
>>
>> In my limited experience Cc and Bcc headers *might* be blocked by the 
>> ISP.
>
> Well you shouldn't be sending a Bcc: header, now, should you? :-)

well there is no there way other than sending EACH message INDIVIDULLY 
that you can hide other members of the mailing list from the intended 
recipient.

The only difference betwen a list mailer and spam, is that the people 
recieving spam didnt ask to be on the list...

>
> And why should it block a cc: header anyway? It's just part of the data.
>
Anti-spam. If there are more than e.g. 10 people on a CC: or Bcc field 
many ISPs - or mail subsystems - will bounce it as spam.



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9848

In article <kq19lv$pqa$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 21/06/13 10:11, Tim Streater wrote:
> > In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
> > Christoph Michael Becker <cmbecker69@arcor.de> wrote:
> >
> >> Am 20.06.2013 22:46, schrieb Gordon Burditt:
> >> >> I'm a PHP near-newbie working fairly successfully on creating a 
> >> secure >> PHP e-mail (mail()) function. It occurs to me that the only 
> >> way a user >> knows (thinks) a form has been sent, is that I tell him 
> >> so either in a >> line of code or with a Thank You page.
> >> > > Since you're a near-newbie, please save the world from having to
> >> > block email from your server, and DO NOT put any variables in email
> >> > headers, DO NOT put any variables from the user in email headers,
> >> > and DO NOT put any variables set in your form in email headers.
> >> > Put them in the body of the mail.
> >>
> >> Or use at least a good email library which caters for security issues
> >> and other "details" regarding correct headers.
> >>
> >> And one should not forget that not everything could be put in the
> >> message body--at least not without proper setting of some headers.
> >>
> >> > Wrong:         From: $email
> >> > Right:         From: www-data@myserver.hostingco.com
> >> > > Some servers are going to require that (a) the From: address is
> >> > local, (b) the From: address is a valid local user, and perhaps (c)
> >> > the user name must match the user id of the code that called the
> >> > MTA.  In other words, there might be only one correct From: line
> >> > you're allowed to use.
> >>
> >> Indeed, but the OP may *try* if custom From headers are allowed on his
> >> webspace.
> >>
> >> > (For a mailing list to customers, you're stuck with a variable
> >> > in the To:, Cc:, or Bcc: headers.  )
> >>
> >> In my limited experience Cc and Bcc headers *might* be blocked by the 
> >> ISP.
> >
> > Well you shouldn't be sending a Bcc: header, now, should you? :-)
> 
> well there is no there way other than sending EACH message INDIVIDULLY 
> that you can hide other members of the mailing list from the intended 
> recipient.

Here's how I do it in my email client wot I rote.

1) The user (i.e, just me at this point) composes a mail and adds a 
certain number of destination addresses in the To:, cc:, and bcc: fields.

2) These are then checked for being properly formatted and stored in 
three strings.

3) At the point the mail is sent, logon to the mail host. Send "MAIL 
FROM <address>" where 'address' is whatever the user types into the From 
field or gets put there automatically if the user selects it.

4) The three strings from (2) are converted to arrays of addresses and 
sent to the host as a series of "RCPT TO <address>".

5) Then send "DATA" followed by the headers such as From:, Subject: 
Date:, cc:, any content-type and so on, then a blank line and the actual 
body, encoded and in parts as necessary.


So that's one mail sent for all the addresses (above I've left out 
checking returned statuses, timeouts, etc) with no bcc: line sent. So 
all the addresses *could* be put in the bcc: field, with no 
inter-recipient consciousness.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#9851

On 21/06/13 12:27, Tim Streater wrote:
> In article <kq19lv$pqa$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 21/06/13 10:11, Tim Streater wrote:
>> > In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
>> > Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>> >
>> >> Am 20.06.2013 22:46, schrieb Gordon Burditt:
>> >> >> I'm a PHP near-newbie working fairly successfully on creating a 
>> >> secure >> PHP e-mail (mail()) function. It occurs to me that the 
>> only >> way a user >> knows (thinks) a form has been sent, is that I 
>> tell him >> so either in a >> line of code or with a Thank You page.
>> >> > > Since you're a near-newbie, please save the world from having to
>> >> > block email from your server, and DO NOT put any variables in email
>> >> > headers, DO NOT put any variables from the user in email headers,
>> >> > and DO NOT put any variables set in your form in email headers.
>> >> > Put them in the body of the mail.
>> >>
>> >> Or use at least a good email library which caters for security issues
>> >> and other "details" regarding correct headers.
>> >>
>> >> And one should not forget that not everything could be put in the
>> >> message body--at least not without proper setting of some headers.
>> >>
>> >> > Wrong:         From: $email
>> >> > Right:         From: www-data@myserver.hostingco.com
>> >> > > Some servers are going to require that (a) the From: address is
>> >> > local, (b) the From: address is a valid local user, and perhaps (c)
>> >> > the user name must match the user id of the code that called the
>> >> > MTA.  In other words, there might be only one correct From: line
>> >> > you're allowed to use.
>> >>
>> >> Indeed, but the OP may *try* if custom From headers are allowed on 
>> his
>> >> webspace.
>> >>
>> >> > (For a mailing list to customers, you're stuck with a variable
>> >> > in the To:, Cc:, or Bcc: headers.  )
>> >>
>> >> In my limited experience Cc and Bcc headers *might* be blocked by 
>> the >> ISP.
>> >
>> > Well you shouldn't be sending a Bcc: header, now, should you? :-)
>>
>> well there is no there way other than sending EACH message 
>> INDIVIDULLY that you can hide other members of the mailing list from 
>> the intended recipient.
>
> Here's how I do it in my email client wot I rote.
>
> 1) The user (i.e, just me at this point) composes a mail and adds a 
> certain number of destination addresses in the To:, cc:, and bcc: fields.
>
> 2) These are then checked for being properly formatted and stored in 
> three strings.
>
> 3) At the point the mail is sent, logon to the mail host. Send "MAIL 
> FROM <address>" where 'address' is whatever the user types into the 
> From field or gets put there automatically if the user selects it.
>
> 4) The three strings from (2) are converted to arrays of addresses and 
> sent to the host as a series of "RCPT TO <address>".
>
> 5) Then send "DATA" followed by the headers such as From:, Subject: 
> Date:, cc:, any content-type and so on, then a blank line and the 
> actual body, encoded and in parts as necessary.
>
>
> So that's one mail sent for all the addresses (above I've left out 
> checking returned statuses, timeouts, etc) with no bcc: line sent. So 
> all the addresses *could* be put in the bcc: field, with no 
> inter-recipient consciousness.
>
in MTA terms there is no Bcc: field at all. That's an MUA masking of the 
underlying way SMTP mail works.

The To: and CC: and BBC: headers are parsed to get a list of addresses 
which become the envelope address.
The Bcc: fields are removed from the headers, leaving only To: and From:

(and a lot of others)

But the ONLY  thing that matters is the RCPT TO transactions when 
talking to the MTA. In terms of the message getting there, and the fact 
is that many MTAS will dump the message if it has too many RCPT TO 
instructionsbefore it gets to 'data'.

And the workaround is to send those message individually. Not as bulk mail.


This is how I do it at PHP level:

     $return_path="webmaster@xxxc.com";
       $from="webmaster@xxxc.com";
     // get list of addressees
     mysql_query("set group_concat_max_len = 8192"); //to avoid truncation
    // picks up a comma delimited list of peopole who want to be mailed, 
and actually have valid email addresses
     $email=mysql_result(mysql_query(sprintf("select 1 as g, 
group_concat(email separator ',') as them from people where status>='%d' 
and instr(email,'@') group by g",$status)),
         0,'them');
     //
     $headers = sprintf("To: %s\nFrom: %s\nBcc:%s\n", $from, $from,$email);
     mail('', $subject, $body, $headers, "-f ".$return_path );

Note the -f.$return_path

If you don't have that set to a valid address, many mailers will reject 
your email as spam. You cannot rely on that to be set by the MTA either. 
It tends to default to www-data@machine-name

In my case with an exim mailer I had also to set  'don't send multiple 
recipient emails' somehow

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9852

In article <kq20q8$9cc$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 21/06/13 12:27, Tim Streater wrote:
> > In article <kq19lv$pqa$1@news.albasani.net>,
> > The Natural Philosopher <tnp@invalid.invalid> wrote:
> >
> >> On 21/06/13 10:11, Tim Streater wrote:
> >> > In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
> >> > Christoph Michael Becker <cmbecker69@arcor.de> wrote:
> >> >
> >> >> Am 20.06.2013 22:46, schrieb Gordon Burditt:
> >> >> >> I'm a PHP near-newbie working fairly successfully on creating a 
> >> >> secure >> PHP e-mail (mail()) function. It occurs to me that the 
> >> only >> way a user >> knows (thinks) a form has been sent, is that I 
> >> tell him >> so either in a >> line of code or with a Thank You page.
> >> >> > > Since you're a near-newbie, please save the world from having to
> >> >> > block email from your server, and DO NOT put any variables in email
> >> >> > headers, DO NOT put any variables from the user in email headers,
> >> >> > and DO NOT put any variables set in your form in email headers.
> >> >> > Put them in the body of the mail.
> >> >>
> >> >> Or use at least a good email library which caters for security issues
> >> >> and other "details" regarding correct headers.
> >> >>
> >> >> And one should not forget that not everything could be put in the
> >> >> message body--at least not without proper setting of some headers.
> >> >>
> >> >> > Wrong:         From: $email
> >> >> > Right:         From: www-data@myserver.hostingco.com
> >> >> > > Some servers are going to require that (a) the From: address is
> >> >> > local, (b) the From: address is a valid local user, and perhaps (c)
> >> >> > the user name must match the user id of the code that called the
> >> >> > MTA.  In other words, there might be only one correct From: line
> >> >> > you're allowed to use.
> >> >>
> >> >> Indeed, but the OP may *try* if custom From headers are allowed on 
> >> his
> >> >> webspace.
> >> >>
> >> >> > (For a mailing list to customers, you're stuck with a variable
> >> >> > in the To:, Cc:, or Bcc: headers.  )
> >> >>
> >> >> In my limited experience Cc and Bcc headers *might* be blocked by 
> >> the >> ISP.
> >> >
> >> > Well you shouldn't be sending a Bcc: header, now, should you? :-)
> >>
> >> well there is no there way other than sending EACH message 
> >> INDIVIDULLY that you can hide other members of the mailing list from 
> >> the intended recipient.
> >
> > Here's how I do it in my email client wot I rote.
> >
> > 1) The user (i.e, just me at this point) composes a mail and adds a 
> > certain number of destination addresses in the To:, cc:, and bcc: fields.
> >
> > 2) These are then checked for being properly formatted and stored in 
> > three strings.
> >
> > 3) At the point the mail is sent, logon to the mail host. Send "MAIL 
> > FROM <address>" where 'address' is whatever the user types into the 
> > From field or gets put there automatically if the user selects it.
> >
> > 4) The three strings from (2) are converted to arrays of addresses and 
> > sent to the host as a series of "RCPT TO <address>".
> >
> > 5) Then send "DATA" followed by the headers such as From:, Subject: 
> > Date:, cc:, any content-type and so on, then a blank line and the 
> > actual body, encoded and in parts as necessary.
> >
> >
> > So that's one mail sent for all the addresses (above I've left out 
> > checking returned statuses, timeouts, etc) with no bcc: line sent. So 
> > all the addresses *could* be put in the bcc: field, with no 
> > inter-recipient consciousness.
> >
> in MTA terms there is no Bcc: field at all. That's an MUA masking of the 
> underlying way SMTP mail works.

Quite.

> The To: and CC: and BBC: headers are parsed to get a list of addresses 
> which become the envelope address.

I may do some experiments where I'll do the RCPT-TO correctly but put 
junk in the To: and cc: headers to see what happens. I have found that 
it doesn't always matter what the From: header says. I was able to 
change it to mickey.mouse@example.com and the mail arrived at the 
destination.

>      mail('', $subject, $body, $headers, "-f ".$return_path );

I don't use mail(). I've rolled my own, which seems to work.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#9857

On 21/06/13 18:25, Tim Streater wrote:
> In article <kq20q8$9cc$1@news.albasani.net>,
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> On 21/06/13 12:27, Tim Streater wrote:
>> > In article <kq19lv$pqa$1@news.albasani.net>,
>> > The Natural Philosopher <tnp@invalid.invalid> wrote:
>> >
>> >> On 21/06/13 10:11, Tim Streater wrote:
>> >> > In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
>> >> > Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>> >> >
>> >> >> Am 20.06.2013 22:46, schrieb Gordon Burditt:
>> >> >> >> I'm a PHP near-newbie working fairly successfully on 
>> creating a >> >> secure >> PHP e-mail (mail()) function. It occurs to 
>> me that the >> only >> way a user >> knows (thinks) a form has been 
>> sent, is that I >> tell him >> so either in a >> line of code or with 
>> a Thank You page.
>> >> >> > > Since you're a near-newbie, please save the world from 
>> having to
>> >> >> > block email from your server, and DO NOT put any variables in 
>> email
>> >> >> > headers, DO NOT put any variables from the user in email 
>> headers,
>> >> >> > and DO NOT put any variables set in your form in email headers.
>> >> >> > Put them in the body of the mail.
>> >> >>
>> >> >> Or use at least a good email library which caters for security 
>> issues
>> >> >> and other "details" regarding correct headers.
>> >> >>
>> >> >> And one should not forget that not everything could be put in the
>> >> >> message body--at least not without proper setting of some headers.
>> >> >>
>> >> >> > Wrong:         From: $email
>> >> >> > Right:         From: www-data@myserver.hostingco.com
>> >> >> > > Some servers are going to require that (a) the From: 
>> address is
>> >> >> > local, (b) the From: address is a valid local user, and 
>> perhaps (c)
>> >> >> > the user name must match the user id of the code that called the
>> >> >> > MTA.  In other words, there might be only one correct From: line
>> >> >> > you're allowed to use.
>> >> >>
>> >> >> Indeed, but the OP may *try* if custom From headers are allowed 
>> on >> his
>> >> >> webspace.
>> >> >>
>> >> >> > (For a mailing list to customers, you're stuck with a variable
>> >> >> > in the To:, Cc:, or Bcc: headers.  )
>> >> >>
>> >> >> In my limited experience Cc and Bcc headers *might* be blocked 
>> by >> the >> ISP.
>> >> >
>> >> > Well you shouldn't be sending a Bcc: header, now, should you? :-)
>> >>
>> >> well there is no there way other than sending EACH message >> 
>> INDIVIDULLY that you can hide other members of the mailing list from 
>> >> the intended recipient.
>> >
>> > Here's how I do it in my email client wot I rote.
>> >
>> > 1) The user (i.e, just me at this point) composes a mail and adds a 
>> > certain number of destination addresses in the To:, cc:, and bcc: 
>> fields.
>> >
>> > 2) These are then checked for being properly formatted and stored 
>> in > three strings.
>> >
>> > 3) At the point the mail is sent, logon to the mail host. Send 
>> "MAIL > FROM <address>" where 'address' is whatever the user types 
>> into the > From field or gets put there automatically if the user 
>> selects it.
>> >
>> > 4) The three strings from (2) are converted to arrays of addresses 
>> and > sent to the host as a series of "RCPT TO <address>".
>> >
>> > 5) Then send "DATA" followed by the headers such as From:, Subject: 
>> > Date:, cc:, any content-type and so on, then a blank line and the > 
>> actual body, encoded and in parts as necessary.
>> >
>> >
>> > So that's one mail sent for all the addresses (above I've left out 
>> > checking returned statuses, timeouts, etc) with no bcc: line sent. 
>> So > all the addresses *could* be put in the bcc: field, with no > 
>> inter-recipient consciousness.
>> >
>> in MTA terms there is no Bcc: field at all. That's an MUA masking of 
>> the underlying way SMTP mail works.
>
> Quite.
>
>> The To: and CC: and BBC: headers are parsed to get a list of 
>> addresses which become the envelope address.
>
> I may do some experiments where I'll do the RCPT-TO correctly but put 
> junk in the To: and cc: headers to see what happens. I have found that 
> it doesn't always matter what the From: header says. I was able to 
> change it to mickey.mouse@example.com and the mail arrived at the 
> destination.
>
>>      mail('', $subject, $body, $headers, "-f ".$return_path );
>
> I don't use mail(). I've rolled my own, which seems to work.
>

yes., well in which case its the MAIL  FROM: command which is crucial in 
the smtp conversation.

MTAS generally ONLY respond to RCPT TO to get the message moved along 
and the MAIL FROM  to determine its come from a real person. They will 
normally check MX records for that domain and may even send a null 
message to it to check it exists. If not it may junk the mail.  Because 
its unbounceable, so norally its rejected right at te start.



The headers are completely ignored unless to be rewritten (rare these 
days) or to be added to.



-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#9860

In article <kq2ku9$hpj$1@news.albasani.net>,
 The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 21/06/13 18:25, Tim Streater wrote:

> > I don't use mail(). I've rolled my own, which seems to work.

> yes., well in which case its the MAIL  FROM: command which is crucial in 
> the smtp conversation.
> 
> MTAS generally ONLY respond to RCPT TO to get the message moved along 
> and the MAIL FROM  to determine its come from a real person. They will 
> normally check MX records for that domain and may even send a null 
> message to it to check it exists. If not it may junk the mail.  Because 
> its unbounceable, so norally its rejected right at te start.

I was able to use a MAIL FROM with a fake address from one of my mail 
accounts to another. That arrived a s expected, so it can be done but 
that of course is just one pairing out of a large number.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#9864

On 2013-06-21 6:25 AM, The Natural Philosopher wrote:
> On 21/06/13 10:11, Tim Streater wrote:
>> In article <51c37641$0$6623$9b4e6d93@newsspool2.arcor-online.net>,
>> Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>>
>>> Am 20.06.2013 22:46, schrieb Gordon Burditt:
>>> >> I'm a PHP near-newbie working fairly successfully on creating a
>>> secure >> PHP e-mail (mail()) function. It occurs to me that the only
>>> way a user >> knows (thinks) a form has been sent, is that I tell him
>>> so either in a >> line of code or with a Thank You page.
>>> > > Since you're a near-newbie, please save the world from having to
>>> > block email from your server, and DO NOT put any variables in email
>>> > headers, DO NOT put any variables from the user in email headers,
>>> > and DO NOT put any variables set in your form in email headers.
>>> > Put them in the body of the mail.

...

>>>
>>> > (For a mailing list to customers, you're stuck with a variable
>>> > in the To:, Cc:, or Bcc: headers.  )
>>>
>>> In my limited experience Cc and Bcc headers *might* be blocked by the
>>> ISP.

Not mine; but I do receive reports on anything that looks suspicious. 
For an online form, which was the subject of the OP here, a BCC: list 
(or even cc:) shouldn't be needed.

If I'm sending out a mailing list though, I do use Bcc: so that 
everyone's e-mail address isn't exposed to every recipient's view and 
Address Book, just primed to be hacked. But an online form has no use 
for such things and they should be filtered from all input.

>>
>> Well you shouldn't be sending a Bcc: header, now, should you? :-)
>
> well there is no there way other than sending EACH message INDIVIDULLY
> that you can hide other members of the mailing list from the intended
> recipient.
>
> The only difference betwen a list mailer and spam, is that the people
> recieving spam didnt ask to be on the list...

Not here: Every single person on the list has signed up and ASKED to 
receive the e-mails. And those come from me, NOT an online form.
>
>>
>> And why should it block a cc: header anyway? It's just part of the data.
>>
> Anti-spam. If there are more than e.g. 10 people on a CC: or Bcc field
> many ISPs - or mail subsystems - will bounce it as spam.

Not on any of the four ISP/servers I've used anyway. I'd hope that only 
applied to online forms; my limit is 150 e-mails per 24 hr period or 500 
per month and they do an excellent job with identifying spam. Should I 
send spam, they'll detect it immediately and give me 24 hours to stop.
>
>
>

[toc] | [prev] | [next] | [standalone]

#9831

On Thu, 20 Jun 2013 15:46:23 -0500, Gordon Burditt wrote:
> (For a mailing list to customers, you're stuck with a variable
> in the To:, Cc:, or Bcc: headers.  )

There's lots of entirely reasonable mailing list software already
written and writing it oneself is a non-trivial task, fraught with ways
of doing it wrong, with a pretty high price for errors.

-- 
31. All naive, busty tavern wenches in my realm will be replaced with 
   surly, world-weary waitresses who will provide no unexpected 
   reinforcement and/or romantic subplot for the hero or his sidekick.
        --Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [next] | [standalone]

#9842

On 20/06/13 23:27, Peter H. Coffin wrote:
> On Thu, 20 Jun 2013 15:46:23 -0500, Gordon Burditt wrote:
>> (For a mailing list to customers, you're stuck with a variable
>> in the To:, Cc:, or Bcc: headers.  )
> There's lots of entirely reasonable mailing list software already
> written and writing it oneself is a non-trivial task,

I dunno. Mine runs in less than half a page of PHP and is reasonably 
flawless. Either it works or it don't.
Only issue I had to address was that some sites reject mail with 
multiple Bcc's (yahoo! IIRC)  but that was sorted at the mail system 
level, telling it to use individual connections for each email.



>   fraught with ways
> of doing it wrong, with a pretty high price for errors.
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web