| FORMS, validating mail was sent [message #181855] |
Thu, 20 June 2013 17:40  |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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.
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?
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.
Any suggestions?
Thanks,
Twayne`
|
|
|
|
| Re: FORMS, validating mail was sent [message #181858 is a reply to message #181855] |
Thu, 20 June 2013 17:53  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/20/2013 1:40 PM, Twayne 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.
>
> 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?
>
> 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.
>
> Any suggestions?
>
> Thanks,
>
> Twayne`
No. All PHP knows (and can know) is the mail was handed off to the MTA.
The MTA will handle the message asynchronously, and there is no way
for PHP to know what has happened to the email.
It can be a hassle, I know. But I've never had a problem with the email
not being sent if the headers were correct (and the MTA's log showed me
the errors of my ways :) ) and the receiver's email address existed (and
was not full).
Whether it was received or not is another problem. The receiving MTA
may have passed the email off to a SPAM folder, for instance.
Unfortunately, there isn't much you can about what the receiving MTA
does with the email other than to ensure your headers are correct (i.e.
the most popular reason for failure is an improper From: address).
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: FORMS, validating mail was sent [message #181860 is a reply to message #181855] |
Thu, 20 June 2013 18:18 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 20/06/13 19:40, Twayne 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.
>
> 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?
You have the return value from mail() which tells you if PHP managed to
connect to the MTA and leave the mail there.
To be sure the mail was sent, you would need to look at the MTA's log
files and see if it sent the mail (could be that the MTA thinks the mail
is spam and may have discarded it). If the mail is sent, the only way to
know if it arrived is to look in the receiving mail box or the logs of
the MTA on the other end.
--
//Aho
|
|
|
|
| Re: FORMS, validating mail was sent [message #181862 is a reply to message #181855] |
Thu, 20 June 2013 18:24 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 20/06/13 18:40, Twayne 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.
>
> 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?
>
> 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.
>
> Any suggestions?
>
Not easy. I usually include myself in the mailing list.
BUT even so if there are bad mail addresses, then you need to set
yourself as the bounce target as well, to see those.
In general in a *nix platform the messages will be recieved by the SMTP
forwarding agent, and then get queued and a queue run will take place
immediately.
to check the mail queue there is a system command mailq which should
return empty.
But you cant execute that without root privileges. Which means having
that level of access to the machine and writing an su 'ed wrapper in C
and calling that instead.
If apache is running php as 'www-data' or whatever.
In short there are things you can do, but none are easy and all are
outside the scope of 'just' php.
> Thanks,
>
> Twayne`
--
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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181863 is a reply to message #181862] |
Thu, 20 June 2013 18:40 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/20/2013 2:24 PM, The Natural Philosopher wrote:
> On 20/06/13 18:40, Twayne 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.
>>
>> 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?
>>
>> 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.
>>
>> Any suggestions?
>>
>
> Not easy. I usually include myself in the mailing list.
>
> BUT even so if there are bad mail addresses, then you need to set
> yourself as the bounce target as well, to see those.
> In general in a *nix platform the messages will be recieved by the SMTP
> forwarding agent, and then get queued and a queue run will take place
> immediately.
>
> to check the mail queue there is a system command mailq which should
> return empty.
>
> But you cant execute that without root privileges. Which means having
> that level of access to the machine and writing an su 'ed wrapper in C
> and calling that instead.
>
You don't necessarily need root privileges to check the mail queue (the
exact command is dependent on the MTA being used - not always mailq).
You should also be able to use the MTA's userid (usually 'mail'), if the
MTA is on the same machine. See posix_setuid() and posix_setgid().
However, this creates a big security risk in PHP, by allowing a rogue
script to get root access. Better would be to invoke a CLI script to
change the uid/gid. Even this is subject to potential security risks,
but those are less.
Of course, this also depends on the MTA being on the same machine. It
also depends on the receiving MTA bouncing the email for an invalid
address (or other problems). More and more, email hosting companies are
not rejecting invalid addresses, because it will help spammers determine
what is a valid address and what isn't. It also depends on the MTA
processing the bounce immediately upon receipt, which is dependent on
the MTA's configuration.
It also doesn't work if the receiving MTA receives the email but then
dumps it, i.e. as spam.
> If apache is running php as 'www-data' or whatever.
>
> In short there are things you can do, but none are easy and all are
> outside the scope of 'just' php.
>
>> Thanks,
>>
>> Twayne`
>
>
This can all be done with 'just' PHP, but you have to ensure the rest of
the system is also set up properly. And even then, it's not perfect.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: FORMS, validating mail was sent [message #181868 is a reply to message #181862] |
Thu, 20 June 2013 19:44 |
gordonb.vb4vo
Messages: 1
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
> Not easy. I usually include myself in the mailing list.
>
> BUT even so if there are bad mail addresses, then you need to set
> yourself as the bounce target as well, to see those.
> In general in a *nix platform the messages will be recieved by the SMTP
> forwarding agent, and then get queued and a queue run will take place
> immediately.
>
> to check the mail queue there is a system command mailq which should
> return empty.
However, checking the mail queue doesn't tell you much. If a test
tells you that you might be ugly if it's positive and you might be
ugly if it's negative, why run the test at all? The mail queue may
be empty because:
+ Your mail was dropped on the floor for having an invalid
From: address. Valid From: addresses likely include ONLY
those with the host name of the server you are sending
from and a known valid user on that system. Typically
only a few users like root can send mail with 'fake'
(off-system) From: addresses. Hint: Do NOT put a
user-supplied email address in the From: header.
+ Your mail was already sent on.
+ Your mail has already bounced.
+ Your mail was already dropped for policy reasons like
sending over a number of addresses in a given hour.
The mail queue may *not* be empty because:
+ If the system load was high, the "immediate queue run" may
not be so immediate.
+ Someone's been sending a lot of mail. It is not at all
difficult to back up a mail server sending one email per second
(we'll assume you are sending individual copies because
they are personalized) and starting a queue run each time.
+ Someone (perhaps another user of your site) just sent
mail a few milliseconds ago.
+ The intended recipient has a slow DNS server. If you
send emails to 100 recipients at a time, it is likely
that at least a couple of them have slow DNS servers or
overloaded mail servers. The mail will stay in the queue
until the message has been delivered to all recipients,
and that can take days, even if 98 of them were delivered
in the first minute.
> But you cant execute that without root privileges. Which means having
> that level of access to the machine and writing an su 'ed wrapper in C
> and calling that instead.
Sometimes you can get a queue count without root privileges. The
program that comes with the MTA for this is likely already setuid-root,
and you may be able to configure allowing ordinary users to get a
queue count.
> If apache is running php as 'www-data' or whatever.
> In short there are things you can do, but none are easy and all are
> outside the scope of 'just' php.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181871 is a reply to message #181855] |
Thu, 20 June 2013 20:46 |
gordonb.k0cb7
Messages: 1
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
> 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(at)myserver(dot)hostingco(dot)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(at)gmail(dot)com\rCc: victim1(at)gmail(dot)com,
victim2(at)gmail(dot)com, victim3(at)gmail(dot)com, ..., victim99(at)gmail(dot)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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181872 is a reply to message #181868] |
Thu, 20 June 2013 21:03 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 20/06/13 20:44, Gordon Burditt wrote:
>> Not easy. I usually include myself in the mailing list.
>>
>> BUT even so if there are bad mail addresses, then you need to set
>> yourself as the bounce target as well, to see those.
>> In general in a *nix platform the messages will be recieved by the SMTP
>> forwarding agent, and then get queued and a queue run will take place
>> immediately.
>>
>> to check the mail queue there is a system command mailq which should
>> return empty.
> However, checking the mail queue doesn't tell you much. If a test
> tells you that you might be ugly if it's positive and you might be
> ugly if it's negative, why run the test at all? The mail queue may
> be empty because:
> + Your mail was dropped on the floor for having an invalid
> From: address. Valid From: addresses likely include ONLY
> those with the host name of the server you are sending
> from and a known valid user on that system. Typically
> only a few users like root can send mail with 'fake'
> (off-system) From: addresses. Hint: Do NOT put a
> user-supplied email address in the From: header.
>
> + Your mail was already sent on.
>
> + Your mail has already bounced.
>
> + Your mail was already dropped for policy reasons like
> sending over a number of addresses in a given hour.
>
> The mail queue may *not* be empty because:
> + If the system load was high, the "immediate queue run" may
> not be so immediate.
>
> + Someone's been sending a lot of mail. It is not at all
> difficult to back up a mail server sending one email per second
> (we'll assume you are sending individual copies because
> they are personalized) and starting a queue run each time.
>
> + Someone (perhaps another user of your site) just sent
> mail a few milliseconds ago.
>
> + The intended recipient has a slow DNS server. If you
> send emails to 100 recipients at a time, it is likely
> that at least a couple of them have slow DNS servers or
> overloaded mail servers. The mail will stay in the queue
> until the message has been delivered to all recipients,
> and that can take days, even if 98 of them were delivered
> in the first minute.
INdeed.
All you can say is that the message has left the building. Not whither
it was bound.
>> But you cant execute that without root privileges. Which means having
>> that level of access to the machine and writing an su 'ed wrapper in C
>> and calling that instead.
> Sometimes you can get a queue count without root privileges. The
> program that comes with the MTA for this is likely already setuid-root,
> and you may be able to configure allowing ordinary users to get a
> queue count.
it ain't the case here, cos I checked :-)
>> If apache is running php as 'www-data' or whatever.
>> In short there are things you can do, but none are easy and all are
>> outside the scope of 'just' php.
--
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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181873 is a reply to message #181871] |
Thu, 20 June 2013 21:03 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)myserver(dot)hostingco(dot)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(at)gmail(dot)com\rCc: victim1(at)gmail(dot)com,
> victim2(at)gmail(dot)com, victim3(at)gmail(dot)com, ..., victim99(at)gmail(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: FORMS, validating mail was sent [message #181874 is a reply to message #181871] |
Thu, 20 June 2013 21:39 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
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(at)myserver(dot)hostingco(dot)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(at)gmail(dot)com\rCc: victim1(at)gmail(dot)com,
> victim2(at)gmail(dot)com, victim3(at)gmail(dot)com, ..., victim99(at)gmail(dot)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
|
|
|
|
| Re: FORMS, validating mail was sent [message #181880 is a reply to message #181871] |
Thu, 20 June 2013 22:27 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: FORMS, validating mail was sent [message #181891 is a reply to message #181880] |
Fri, 21 June 2013 06:57 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181893 is a reply to message #181874] |
Fri, 21 June 2013 09:11 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <51c37641$0$6623$9b4e6d93(at)newsspool2(dot)arcor-online(dot)net>,
Christoph Michael Becker <cmbecker69(at)arcor(dot)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(at)myserver(dot)hostingco(dot)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
|
|
|
|
| Re: FORMS, validating mail was sent [message #181896 is a reply to message #181893] |
Fri, 21 June 2013 10:25 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21/06/13 10:11, Tim Streater wrote:
> In article <51c37641$0$6623$9b4e6d93(at)newsspool2(dot)arcor-online(dot)net>,
> Christoph Michael Becker <cmbecker69(at)arcor(dot)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(at)myserver(dot)hostingco(dot)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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181897 is a reply to message #181896] |
Fri, 21 June 2013 11:27 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <kq19lv$pqa$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> On 21/06/13 10:11, Tim Streater wrote:
>> In article <51c37641$0$6623$9b4e6d93(at)newsspool2(dot)arcor-online(dot)net>,
>> Christoph Michael Becker <cmbecker69(at)arcor(dot)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(at)myserver(dot)hostingco(dot)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
|
|
|
|
| Re: FORMS, validating mail was sent [message #181900 is a reply to message #181897] |
Fri, 21 June 2013 16:59 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21/06/13 12:27, Tim Streater wrote:
> In article <kq19lv$pqa$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>
>> On 21/06/13 10:11, Tim Streater wrote:
>>> In article <51c37641$0$6623$9b4e6d93(at)newsspool2(dot)arcor-online(dot)net>,
>>> Christoph Michael Becker <cmbecker69(at)arcor(dot)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(at)myserver(dot)hostingco(dot)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(at)xxxc(dot)com";
$from="webmaster(at)xxxc(dot)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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181901 is a reply to message #181900] |
Fri, 21 June 2013 17:25 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <kq20q8$9cc$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
> On 21/06/13 12:27, Tim Streater wrote:
>> In article <kq19lv$pqa$1(at)news(dot)albasani(dot)net>,
>> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>>
>>> On 21/06/13 10:11, Tim Streater wrote:
>>>> In article <51c37641$0$6623$9b4e6d93(at)newsspool2(dot)arcor-online(dot)net>,
>>>> Christoph Michael Becker <cmbecker69(at)arcor(dot)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(at)myserver(dot)hostingco(dot)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(dot)mouse(at)example(dot)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
|
|
|
|
| Re: FORMS, validating mail was sent [message #181904 is a reply to message #181868] |
Fri, 21 June 2013 18:06 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Just a short note for right now; I have to leave but I'll be back later
with responses and clarifications that will make things clearer, I hope.
Twayne`
On 2013-06-20 3:44 PM, Gordon Burditt wrote:
>> Not easy. I usually include myself in the mailing list.
>>
>> BUT even so if there are bad mail addresses, then you need to set
>> yourself as the bounce target as well, to see those.
>> In general in a *nix platform the messages will be recieved by the SMTP
>> forwarding agent, and then get queued and a queue run will take place
>> immediately.
>>
>> to check the mail queue there is a system command mailq which should
>> return empty.
>
> However, checking the mail queue doesn't tell you much. If a test
> tells you that you might be ugly if it's positive and you might be
> ugly if it's negative, why run the test at all? The mail queue may
> be empty because:
> + Your mail was dropped on the floor for having an invalid
> From: address. Valid From: addresses likely include ONLY
> those with the host name of the server you are sending
> from and a known valid user on that system. Typically
> only a few users like root can send mail with 'fake'
> (off-system) From: addresses. Hint: Do NOT put a
> user-supplied email address in the From: header.
>
> + Your mail was already sent on.
>
> + Your mail has already bounced.
>
> + Your mail was already dropped for policy reasons like
> sending over a number of addresses in a given hour.
>
> The mail queue may *not* be empty because:
> + If the system load was high, the "immediate queue run" may
> not be so immediate.
>
> + Someone's been sending a lot of mail. It is not at all
> difficult to back up a mail server sending one email per second
> (we'll assume you are sending individual copies because
> they are personalized) and starting a queue run each time.
>
> + Someone (perhaps another user of your site) just sent
> mail a few milliseconds ago.
>
> + The intended recipient has a slow DNS server. If you
> send emails to 100 recipients at a time, it is likely
> that at least a couple of them have slow DNS servers or
> overloaded mail servers. The mail will stay in the queue
> until the message has been delivered to all recipients,
> and that can take days, even if 98 of them were delivered
> in the first minute.
>
>> But you cant execute that without root privileges. Which means having
>> that level of access to the machine and writing an su 'ed wrapper in C
>> and calling that instead.
>
> Sometimes you can get a queue count without root privileges. The
> program that comes with the MTA for this is likely already setuid-root,
> and you may be able to configure allowing ordinary users to get a
> queue count.
>
>> If apache is running php as 'www-data' or whatever.
>
>> In short there are things you can do, but none are easy and all are
>> outside the scope of 'just' php.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181905 is a reply to message #181855] |
Fri, 21 June 2013 18:30 |
GravyCode
Messages: 2
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
On Friday, June 21, 2013 1:40:40 AM UTC+8, Twayne 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.
>
>
>
> 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?
>
>
>
> 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.
>
>
>
> Any suggestions?
>
>
>
> Thanks,
>
>
>
> Twayne`
I really like using PHPMailer, Create a mailer object with whatever settings you like, I usually run mine through gmail since I don't send many and they're mostly to myself.
https://github.com/Synchro/PHPMailer
//Setup
$mail = new PHPMailer();
$mail = $this->mail;
$mail->IsSMTP();
// enables SMTP debug information (for testing) // 1 = errors and messages // 2 = messages only
// $mail->SMTPDebug = 2;
$mail->SMTPAuth = true;
$mail->Host = 'ssl://smtp.gmail.com:465';
$mail->IsHTML(true); // send as HTML
$mail->Username = $account;
$mail->Password = $password;
$mail->FromName = $from;
//Sending
$mail->AddAddress($to);
$mail->Subject = $subject;
$mail->Body = $message; //HTML Body
if(!$mail->Send()){
echo "Mailer Error: " . $mail->ErrorInfo;
} else {
echo "Message sent!";
}
It gives Error messages, but what types and to what extend you might have to check yourself. But if you're using a foreign SMTP server it should be simpler to verify the message was sent, but you wont really know if it was received.
---
If you're just wanting to get user input for your own use and not sending data to others, you could simply add the data to a database - which you can confirm - then send an email with a link to yourself to view it. This way even if you don't receive the email you still have the data on the server. (You could also send the data in the email and store it on the server).
---
With a rather undetailed question as to your purposes and requirements, this is maybe the most helpful info I can provide while make some assumptions.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181906 is a reply to message #181901] |
Fri, 21 June 2013 22:43 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21/06/13 18:25, Tim Streater wrote:
> In article <kq20q8$9cc$1(at)news(dot)albasani(dot)net>,
> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>
>> On 21/06/13 12:27, Tim Streater wrote:
>>> In article <kq19lv$pqa$1(at)news(dot)albasani(dot)net>,
>>> The Natural Philosopher <tnp(at)invalid(dot)invalid> wrote:
>>>
>>>> On 21/06/13 10:11, Tim Streater wrote:
>>>> > In article <51c37641$0$6623$9b4e6d93(at)newsspool2(dot)arcor-online(dot)net>,
>>>> > Christoph Michael Becker <cmbecker69(at)arcor(dot)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(at)myserver(dot)hostingco(dot)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(dot)mouse(at)example(dot)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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181907 is a reply to message #181873] |
Sat, 22 June 2013 00:26 |
gordonb.udxst
Messages: 1
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
>>> 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(at)myserver(dot)hostingco(dot)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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181908 is a reply to message #181907] |
Sat, 22 June 2013 00:36 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)myserver(dot)hostingco(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: FORMS, validating mail was sent [message #181909 is a reply to message #181906] |
Sat, 22 June 2013 12:45 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <kq2ku9$hpj$1(at)news(dot)albasani(dot)net>,
The Natural Philosopher <tnp(at)invalid(dot)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
|
|
|
|
| Re: FORMS, validating mail was sent [message #181910 is a reply to message #181868] |
Sat, 22 June 2013 15:42 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-20 3:44 PM, Gordon Burditt wrote:
>> Not easy. I usually include myself in the mailing list.
I do that also; in fact I am the form's recipient in this case.
The particular site here is more a social site than anything else: it's
a school Graduating Class with a max or 54 members not counting the
grad's families who are also eligible, for our upcoming 50th Reunion in
2014.
>>
>> BUT even so if there are bad mail addresses, then you need to set
>> yourself as the bounce target as well, to see those.
>> In general in a *nix platform the messages will be recieved by the SMTP
>> forwarding agent, and then get queued and a queue run will take place
>> immediately.
There is a specific account for bounces; although it's never received
any mail other than my tests. So far it looks like my security measures
are working; I've had one attempted bot attack that tried for a couple
days and left. We're close to a college town. Hits are low and so is
activity for this particular site.
>>
>> to check the mail queue there is a system command mailq which should
>> return empty.
>
> However, checking the mail queue doesn't tell you much.
I found that; too complex for my level of expertise. I haven't learned
SQL well enough yet; I'm surviving on borrowed code right now.
...
When an e-mail is sent, and accepted, there is an ACK returned
indicating that it was accepted by the server. It's that ACK I am
wanting to detect.
....
>
>> If apache is running php as 'www-data' or whatever.
>
>> In short there are things you can do, but none are easy and all are
>> outside the scope of 'just' php.
I understand: but perhaps I've clarified what it is I'm looking for above.
Thanks,
Twayne`
|
|
|
|
| Re: FORMS, validating mail was sent [message #181911 is a reply to message #181871] |
Sat, 22 June 2013 16:02 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-20 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.
All good information. FWIW, I'm not new to websites and contact forms. I
have a couple I've used for years and never had a hack or any kind of
problem with them.
Due to a brain concussion I've lost all my PHP capabilities to
memory loss and I'm currently using this query as a way to keep on
relearning it. I've gotten some back, but not nearly enough to be
considered as knowledgeable. I remember a lot of the concepts, but C or
PHP actual coding just left for parts unknown.
>
> Wrong: From: $email
> Right: From: www-data(at)myserver(dot)hostingco(dot)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.
Correct.
>
> (For a mailing list to customers, you're stuck with a variable
> in the To:, Cc:, or Bcc: headers. )
To only: cc and bcc are not possible - on purpose.
>
> 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
Done those, too.
>
>
>
> (Consider what happens if $email='me(at)gmail(dot)com\rCc: victim1(at)gmail(dot)com,
> victim2(at)gmail(dot)com, victim3(at)gmail(dot)com, ..., victim99(at)gmail(dot)com', and
> $address (used in the body) contains a 5-page-long ad for body part
> enlargement)
Can't (shouldn't) happen without something pretty clever: Filters limit
it to only one To: address, no code, etc. etc..
>
>> 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?D
Depends on your viewpoint: If you're the one filling out the form, the
mail is "sent". If you're on the other end of the tunnel, the mail is
"accepted"; THAT is the ACK I want to detect.
>
> 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.
>
No argument for a larger site; but it's only the "ACK" that a mail was
accepted that I am looking for. Not that it was or will be delivered.
You have an interesting attitude & viewpoint; I think I like that.
Regards,
Twayne`
|
|
|
|
| Re: FORMS, validating mail was sent [message #181912 is a reply to message #181873] |
Sat, 22 June 2013 16:04 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181913 is a reply to message #181896] |
Sat, 22 June 2013 16:20 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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(at)newsspool2(dot)arcor-online(dot)net>,
>> Christoph Michael Becker <cmbecker69(at)arcor(dot)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.
>
>
>
|
|
|
|
| Re: FORMS, validating mail was sent [message #181918 is a reply to message #181868] |
Sun, 23 June 2013 11:13 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Gordon Burditt wrote:
> + Your mail was dropped on the floor for having an invalid
> From: address. Valid From: addresses likely include ONLY
> those with the host name of the server you are sending
> from and a known valid user on that system. Typically
> only a few users like root can send mail with 'fake'
> (off-system) From: addresses. Hint: Do NOT put a
> user-supplied email address in the From: header.
Utter nonsense. By that logic, Web-mail like GMail could not possibly work,
and it would not be possible to have large e-mail providers in the first
place (because the host name of their servers very likely differs from the
domain of the From header field address).
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.
One must differentiate between the address used as parameter for the MAIL
FROM (SMTP) command (the “Envelope-From”), and the “From” Internet message
header field. The latter can be anything; the former can, in theory, be
anything unless the *sending* MTA enables counter-measures. It is not
possible to change the Envelope-From with simple PHP commands like mail() as
that is determined by the MTA (like sendmail) used by the PHP executable.
The only good part of this answer is the notion that you invite spammers if
you let the end user specify the From header field address without
authentification; so you should not do that, indeed. The /modus operandi/
of spammers and phishers is to harvest or buy e-mail addresses from various
sources and use them also in the “From” header field value to make the
message look to the recipient like a legitimate e-mail (at first). This
kind of network abuse is also supported by “open relays” – MTAs that would
accept and transfer mail for any MAIL FROM to any RCPT TO.
> + The intended recipient has a slow DNS server. If you
> send emails to 100 recipients at a time, it is likely
> that at least a couple of them have slow DNS servers or
> overloaded mail servers. The mail will stay in the queue
> until the message has been delivered to all recipients,
> and that can take days, even if 98 of them were delivered
> in the first minute.
Utter nonsense. DNS is only used to resolve the target host of the message,
specifically to retrieve the host name from the “MX” or “A”/“AAAA” record of
the target domain, and subsequently to resolve the IP address for that host
name from its “A” or “AAAA” record (this double-handshake is intended as a
safety feature of DNS/SMTP: there must be a host *name* for an MX). There
are no DNS servers anywhere that have a respond time of minutes that would
suggest the remote possibility of a delay of days because of DNS issues
(after all, a backup DNS server is strongly recommended, and there are non-
authoritative answers).
When in rare cases e-mails arrive days later, it is usually due greylisting
and a long sender or receiver message queue that needs to be worked through;
not DNS issues at the receiver's (BTST). Also, the mail queue contains a
*copy* of the message for each recipient (not least because in the worst
case each copy must be sent to a different host). Only those copies that
have not been sent are still in the queue, not the single original message
(“the mail”) itself.
“Overloaded mail servers” also are unlikely to be a reason why a message
stays in the sending queue, because receiving MTAs *also* have an *incoming*
message queue which is worked through to put the message into the
corresponding receivers' mailboxes. Overloading is more likely the reason
why the message does not arrive at the recipient's mailbox sooner, but that
has nothing to do with the message transfer between the MTAs, and nothing
with the sending MTA's outgoing message queue.
>> But you cant execute that without root privileges. Which means having
>> that level of access to the machine and writing an su 'ed wrapper in C
>> and calling that instead.
>
> Sometimes you can get a queue count without root privileges. The
> program that comes with the MTA for this is likely already setuid-root,
> and you may be able to configure allowing ordinary users to get a
> queue count.
man sudo
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
|
| Re: FORMS, validating mail was sent [message #181919 is a reply to message #181918] |
Sun, 23 June 2013 11:22 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
I put user supplied data in my mail sender
All that happens is that I get two messages.
1/. "you have received mail from (cue absolute load of rubbsih)
and
2/. the following message could not be delivered (unkown
recipients(at)mydomain(dot)com)"
"YOUR email has been sent to webmaster@mydomain,com, and will be
attended to shortly"
No reason not to do it, provided you understand what will happen if
people attempt to subvert it.
THAT mailer is hard wired to send only to me, and a short 'I got your
email' back to who the sender says they are. So they cant type in spam,.
and send that to random people.
On the other hand, if I am the sender, of course I put user supplied
data into the recipient address. How else do I do a mail shot?
I don't put data into the data base from users if it has more than one
'@' in the email address either.
--
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.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181920 is a reply to message #181918] |
Sun, 23 June 2013 17:00 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Hi,
I've top-posted for two reasons: 1, It's a lot of good info that bears
repitition at lease once, and 2, it's a long post so rather than have
people CTRL-Ending or worse scrolling to the bottom for the response,
this makes it more immediate.
That's a great response and verifiable, which many are not. Some of it I
already knew, a lot of it was great clarification, and I learned a lot.
KUDOS!
Twayne`
On 2013-06-23 7:13 AM, Thomas 'PointedEars' Lahn wrote:
> Gordon Burditt wrote:
>
>> + Your mail was dropped on the floor for having an invalid
>> From: address. Valid From: addresses likely include ONLY
>> those with the host name of the server you are sending
>> from and a known valid user on that system. Typically
>> only a few users like root can send mail with 'fake'
>> (off-system) From: addresses. Hint: Do NOT put a
>> user-supplied email address in the From: header.
>
> Utter nonsense. By that logic, Web-mail like GMail could not possibly work,
> and it would not be possible to have large e-mail providers in the first
> place (because the host name of their servers very likely differs from the
> domain of the From header field address).
>
> 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.
>
> One must differentiate between the address used as parameter for the MAIL
> FROM (SMTP) command (the “Envelope-From”), and the “From” Internet message
> header field. The latter can be anything; the former can, in theory, be
> anything unless the *sending* MTA enables counter-measures. It is not
> possible to change the Envelope-From with simple PHP commands like mail() as
> that is determined by the MTA (like sendmail) used by the PHP executable.
>
> The only good part of this answer is the notion that you invite spammers if
> you let the end user specify the From header field address without
> authentification; so you should not do that, indeed. The /modus operandi/
> of spammers and phishers is to harvest or buy e-mail addresses from various
> sources and use them also in the “From” header field value to make the
> message look to the recipient like a legitimate e-mail (at first). This
> kind of network abuse is also supported by “open relays” – MTAs that would
> accept and transfer mail for any MAIL FROM to any RCPT TO.
>
>> + The intended recipient has a slow DNS server. If you
>> send emails to 100 recipients at a time, it is likely
>> that at least a couple of them have slow DNS servers or
>> overloaded mail servers. The mail will stay in the queue
>> until the message has been delivered to all recipients,
>> and that can take days, even if 98 of them were delivered
>> in the first minute.
>
> Utter nonsense. DNS is only used to resolve the target host of the message,
> specifically to retrieve the host name from the “MX” or “A”/“AAAA” record of
> the target domain, and subsequently to resolve the IP address for that host
> name from its “A” or “AAAA” record (this double-handshake is intended as a
> safety feature of DNS/SMTP: there must be a host *name* for an MX). There
> are no DNS servers anywhere that have a respond time of minutes that would
> suggest the remote possibility of a delay of days because of DNS issues
> (after all, a backup DNS server is strongly recommended, and there are non-
> authoritative answers).
>
> When in rare cases e-mails arrive days later, it is usually due greylisting
> and a long sender or receiver message queue that needs to be worked through;
> not DNS issues at the receiver's (BTST). Also, the mail queue contains a
> *copy* of the message for each recipient (not least because in the worst
> case each copy must be sent to a different host). Only those copies that
> have not been sent are still in the queue, not the single original message
> (“the mail”) itself.
>
> “Overloaded mail servers” also are unlikely to be a reason why a message
> stays in the sending queue, because receiving MTAs *also* have an *incoming*
> message queue which is worked through to put the message into the
> corresponding receivers' mailboxes. Overloading is more likely the reason
> why the message does not arrive at the recipient's mailbox sooner, but that
> has nothing to do with the message transfer between the MTAs, and nothing
> with the sending MTA's outgoing message queue.
>
>>> But you cant execute that without root privileges. Which means having
>>> that level of access to the machine and writing an su 'ed wrapper in C
>>> and calling that instead.
>>
>> Sometimes you can get a queue count without root privileges. The
>> program that comes with the MTA for this is likely already setuid-root,
>> and you may be able to configure allowing ordinary users to get a
>> queue count.
>
> man sudo
>
>
> PointedEars
>
|
|
|
|
| Re: FORMS, validating mail was sent [message #181921 is a reply to message #181919] |
Sun, 23 June 2013 17:07 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-23 7:22 AM, The Natural Philosopher wrote:
>
> I put user supplied data in my mail sender
>
> All that happens is that I get two messages.
>
> 1/. "you have received mail from (cue absolute load of rubbsih)
>
> and
> 2/. the following message could not be delivered (unkown
> recipients(at)mydomain(dot)com)"
> "YOUR email has been sent to webmaster@mydomain,com, and will be
> attended to shortly"
>
> No reason not to do it, provided you understand what will happen if
> people attempt to subvert it.
>
> THAT mailer is hard wired to send only to me, and a short 'I got your
> email' back to who the sender says they are. So they cant type in spam,.
> and send that to random people.
>
> On the other hand, if I am the sender, of course I put user supplied
> data into the recipient address. How else do I do a mail shot?
>
> I don't put data into the data base from users if it has more than one
> '@' in the email address either.
>
I'm doing something veru close to your methodology. Checking and
sanitizing/validating all input, same for final output, only one e-mail
address, plenty of relevant filtering. And testing by myself and a few
friends to see if they can break.
My ISP is also great at identifying spam or worse and only notifies
in Plain Text messages of same, allowing me to decide whether it's spam
or worse, or not.
It's nice to see validation of one's own ideas.
Regards,
|
|
|
|
| Re: FORMS, validating mail was sent [message #181922 is a reply to message #181920] |
Sun, 23 June 2013 18:22 |
J.O. Aho
Messages: 194
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 23/06/13 19:00, Twayne wrote:
> I've top-posted for two reasons: 1, It's a lot of good info that bears
> repitition at lease once, and 2, it's a long post so rather than have
> people CTRL-Ending or worse scrolling to the bottom for the response,
> this makes it more immediate.
This don't justify top posting, just remove all the irrelevant text and
suddenly the post is a lot shorter. There is no point in keeping text
which you don't reply to and for those who want to read the removed
text, they can access it by reading the previous post.
See, I didn't include anything of your post which I'm not responding to,
no need to scroll a lot and you don't need to play jeopardy and scroll
down and read all and then back up to the top to know what your reply to.
--
//Aho
|
|
|
|
|
|
| Re: FORMS, validating mail was sent [message #181925 is a reply to message #181918] |
Mon, 24 June 2013 19:43 |
gordonb.4qaft
Messages: 1
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
>> + Your mail was dropped on the floor for having an invalid
>> From: address. Valid From: addresses likely include ONLY
>> those with the host name of the server you are sending
>> from and a known valid user on that system. Typically
>> only a few users like root can send mail with 'fake'
>> (off-system) From: addresses. Hint: Do NOT put a
>> user-supplied email address in the From: header.
>
> Utter nonsense. By that logic, Web-mail like GMail could not possibly work,
> and it would not be possible to have large e-mail providers in the first
> place (because the host name of their servers very likely differs from the
> domain of the From header field address).
I certainly hope that a self-described "near newbie" is not going to try
to implement something of the scale of Gmail.
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.
> 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.
> One must differentiate between the address used as parameter for the MAIL
> FROM (SMTP) command (the “Envelope-From”), and the “From” Internet message
> header field. The latter can be anything; the former can, in theory, be
> anything unless the *sending* MTA enables counter-measures. It is not
For many default setups, the sending MTA enables countermeasures. This
can be turned off but not if you are stuck with an unsophisticated hosting
company that likes to leave settings at the default.
For some, the receiving MTA enables countermeasures and checks *BOTH* the
From: line and the envelope sender to the extent that it can (which usually
means that the domain exists, has an MX or A record, and it doesn't point
to 127.0.0.1. However, if the MTA also hosts the sender domain, the
check can verify the mailbox exists).
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.
> possible to change the Envelope-From with simple PHP commands like mail() as
> that is determined by the MTA (like sendmail) used by the PHP executable.
> The only good part of this answer is the notion that you invite spammers if
> you let the end user specify the From header field address without
> authentification; so you should not do that, indeed. The /modus operandi/
> of spammers and phishers is to harvest or buy e-mail addresses from various
> sources and use them also in the “From” header field value to make the
> message look to the recipient like a legitimate e-mail (at first). This
> kind of network abuse is also supported by “open relays” – MTAs that would
> accept and transfer mail for any MAIL FROM to any RCPT TO.
They also use header injection, so that poorly written contact forms
can be misused (like an open relay) to send to lots more victims
than just the webmaster of the site. Spammers like that even if
they can't control the From: line.
>> + The intended recipient has a slow DNS server. If you
>> send emails to 100 recipients at a time, it is likely
>> that at least a couple of them have slow DNS servers or
>> overloaded mail servers. The mail will stay in the queue
>> until the message has been delivered to all recipients,
>> and that can take days, even if 98 of them were delivered
>> in the first minute.
>
> Utter nonsense. DNS is only used to resolve the target host of the message,
> specifically to retrieve the host name from the “MX” or “A”/“AAAA” record of
> the target domain, and subsequently to resolve the IP address for that host
> name from its “A” or “AAAA” record (this double-handshake is intended as a
> safety feature of DNS/SMTP: there must be a host *name* for an MX). There
> are no DNS servers anywhere that have a respond time of minutes that would
I suggest that nobody would know that, since software doesn't wait
that long for a response - it just gets treated as a nonresponse.
However, there are a fair number of DNS servers that don't answer,
perhaps because they are on the far end of a loaded DSL line. At
any given time there are DNS servers that are down or unreachable
because of hardware failure, loss of network connectivity, or power
failure.
I hope that the company net admin who said he shuts down his
nameservers and mail servers on weekends, holidays, and overnight
has changed his mind.
The fact that BIND (and some other nameserver software) has memory
leaks and over time will start paging more and more when presented
with an ISP-level load doesn't help. Neither does putting your
nameserver and your mailserver on the same host.
> suggest the remote possibility of a delay of days because of DNS issues
> (after all, a backup DNS server is strongly recommended, and there are non-
> authoritative answers).
Some people seem to think a backup DNS server can be accomplished
with a CNAME record pointing ns2.mycompany.com to ns1.mycompany.com.
Or putting two nameservers at the far end of the same DSL line. I
think if your net presence is important to you, you should have at
least 3 different nameservers on 3 different continents, but for
many companies that's overkill. Hmm... how long before it's practical
to put DNS servers on 3 different planets?
About non-authoritative answers: those can cause mail to be delayed
indefinitely (until a mail server gives up completely, or someone
manually fixes the problem). If my mail server's nameserver doesn't
have the destination domain in it's cache, it asks the root servers,
which probably refer it to the appropriate registrar's servers,
which may refer it to the hosting company's servers, which give it
the MX host. The problem comes when the registrar's servers give
a referral to a DNS server that gives a non-authoritative no-such-domain
error (or worse, isn't up yet). The MTA considers this a retryable
error. This problem usually arises (at least briefly) when you
first set up a domain, or change hosting companies for your DNS.
It can extend for a long period (e.g. weeks or years) if someone
botches the move and nobody notices. Perhaps even worse is the
case where *half* of the registrar's nameservers point to the
wrong place - it may look fine to the domain admin, but not work
for half the world trying to send mail in.
Back in the time frame of 1998-2004 there was a TOP-LEVEL DOMAIN
that was consistently pointed at an unreachable nameserver for a
period of at least 5 years. I think it was .et (Ethiopia). Or
maybe .nt (Neutral Zone - and not the one between the Federation
and the Romulan Empire). Some people would get long-delayed bounce
messages because they had left a letter out of a .net address.
> When in rare cases e-mails arrive days later, it is usually due greylisting
> and a long sender or receiver message queue that needs to be worked through;
> not DNS issues at the receiver's (BTST). Also, the mail queue contains a
> *copy* of the message for each recipient (not least because in the worst
> case each copy must be sent to a different host). Only those copies that
> have not been sent are still in the queue, not the single original message
> (“the mail”) itself.
Many MTAs are much smarter than that (if you hand them one email
with multiple addresses). Some of the stupider MTAs use one queue
copy per destination domain in the list (granted, for some mailing
lists, this is almost equivalent to one per addressee). Some might
use one per set of destination MX records (so if two domains are
hosted on the same server, only one copy is sent). Exim, and I
believe sendmail also, uses one copy, period. (Of course, it can't
always get away with *sending* only one copy.) Control information
is kept which indicates which addressees have completed deliveries.
By looking at a verbose queue listing, I can find how long the
message has been sitting in the queue, and which addresses are
having problems.
I was seeing the long-delayed messages in the outgoing queue. I
also don't claim that the problem addresses were all correct. There
was the *.et problem, and email addresses where the domain was still
up but the company mail server had been auctioned off with other
company assets.
> “Overloaded mail servers” also are unlikely to be a reason why a message
> stays in the sending queue, because receiving MTAs *also* have an *incoming*
> message queue which is worked through to put the message into the
> corresponding receivers' mailboxes.
An overloaded mail server can be unable to respond to a new connection
in time (5 minutes is a typical timeout) for reasons such as heavy
paging/swapping, so the sending server gives up and tries later
(which makes the problem worse). Sometimes this is an "inrush"
problem: a server that's been down for hours gets hammered when it
comes back up. If you don't have limits on the number of incoming
connections, you can run out of swap space or TCP buffer space.
Sometimes the server needs to deliberately ignore incoming connections
so it can finish up with the ones it already has.
> Overloading is more likely the reason
> why the message does not arrive at the recipient's mailbox sooner, but that
> has nothing to do with the message transfer between the MTAs, and nothing
> with the sending MTA's outgoing message queue.
If a mail server can consistently (even if slowly) accept mail for the
queue, I don't call it overloaded, although there may be a problem with
the queue building up. Heavily loaded, yes.
>>> But you cant execute that without root privileges. Which means having
>>> that level of access to the machine and writing an su 'ed wrapper in C
>>> and calling that instead.
>>
>> Sometimes you can get a queue count without root privileges. The
>> program that comes with the MTA for this is likely already setuid-root,
>> and you may be able to configure allowing ordinary users to get a
>> queue count.
>
> man sudo
I prefer a MTA-supplied solution over sudo, *if* there is one.
|
|
|
|
| Re: FORMS, validating mail was sent [message #181926 is a reply to message #181925] |
Mon, 24 June 2013 20:09 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 24 Jun 2013 14:43:47 -0500, Gordon Burditt wrote:
> Some people seem to think a backup DNS server can be accomplished
> with a CNAME record pointing ns2.mycompany.com to ns1.mycompany.com.
> Or putting two nameservers at the far end of the same DSL line. I
> think if your net presence is important to you, you should have at
> least 3 different nameservers on 3 different continents, but for
> many companies that's overkill. Hmm... how long before it's practical
> to put DNS servers on 3 different planets?
It's possible now, but the latency's a bitch and a half....
--
81. If I am fighting with the hero atop a moving platform, have
disarmed him, and am about to finish him off and he glances behind
me and drops flat, I too will drop flat instead of quizzically
turning around to find out what he saw. --Evil Overlord list
|
|
|
|
| Re: FORMS, validating mail was sent [message #181931 is a reply to message #181925] |
Tue, 25 June 2013 13:19 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Gordon Burditt wrote:
>>> + Your mail was dropped on the floor for having an invalid
>>> From: address. Valid From: addresses likely include ONLY
>>> those with the host name of the server you are sending
>>> from and a known valid user on that system. Typically
>>> only a few users like root can send mail with 'fake'
>>> (off-system) From: addresses. Hint: Do NOT put a
>>> user-supplied email address in the From: header.
>>
>> Utter nonsense. By that logic, Web-mail like GMail could not possibly
>> work, and it would not be possible to have large e-mail providers in the
>> first place (because the host name of their servers very likely differs
>> from the domain of the From header field address).
>
> I certainly hope that a self-described "near newbie" is not going to try
> to implement something of the scale of Gmail.
>
> 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.
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.
>> One must differentiate between the address used as parameter for the MAIL
>> FROM (SMTP) command (the “Envelope-From”), and the “From” Internet
>> message
>> header field. The latter can be anything; the former can, in theory, be
>> anything unless the *sending* MTA enables counter-measures. It is not
>
> For many default setups, the sending MTA enables countermeasures. This
> can be turned off but not if you are stuck with an unsophisticated hosting
> company that likes to leave settings at the default.
>
> For some, the receiving MTA enables countermeasures and checks *BOTH* the
> From: line and the envelope sender to the extent that it can (which
> usually means that the domain exists, has an MX or A record, and it
> doesn't point to 127.0.0.1.
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.
> 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.
> 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().
>> possible to change the Envelope-From with simple PHP commands like mail()
>> as that is determined by the MTA (like sendmail) used by the PHP
>> executable.
>
>> The only good part of this answer is the notion that you invite spammers
>> if you let the end user specify the From header field address without
>> authentification; so you should not do that, indeed. The /modus
>> operandi/ of spammers and phishers is to harvest or buy e-mail addresses
>> from various sources and use them also in the “From” header field value
>> to make the message look to the recipient like a legitimate e-mail (at
>> first). This kind of network abuse is also supported by “open relays” –
>> MTAs that would accept and transfer mail for any MAIL FROM to any RCPT
>> TO.
>
> They also use header injection, so that poorly written contact forms
> can be misused (like an open relay) to send to lots more victims
> than just the webmaster of the site. Spammers like that even if
> they can't control the From: line.
There is the Suhosin patch and PHP 5.4 against that.
>>> + The intended recipient has a slow DNS server. If you
>>> send emails to 100 recipients at a time, it is likely
>>> that at least a couple of them have slow DNS servers or
>>> overloaded mail servers. The mail will stay in the queue
>>> until the message has been delivered to all recipients,
>>> and that can take days, even if 98 of them were delivered
>>> in the first minute.
>>
>> Utter nonsense. DNS is only used to resolve the target host of the
>> message, specifically to retrieve the host name from the “MX” or
>> “A”/“AAAA” record of the target domain, and subsequently to resolve the
>> IP address for that host name from its “A” or “AAAA” record (this
>> double-handshake is intended as a
>> safety feature of DNS/SMTP: there must be a host *name* for an MX).
>> There are no DNS servers anywhere that have a respond time of minutes
>> that would
>
> I suggest that nobody would know that, since software doesn't wait
> that long for a response - it just gets treated as a nonresponse.
My chkmadd(1) has been treated to a number of Usenet Froms over 10 years to
talk SMTP to MTAs automatically for checking whether they are munged, and
never ever has a DNS request timed out.
> However, there are a fair number of DNS servers that don't answer,
> perhaps because they are on the far end of a loaded DSL line. At
> any given time there are DNS servers that are down or unreachable
> because of hardware failure, loss of network connectivity, or power
> failure.
Name one.
> [more nonsense]
ISTM you need professional help.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
| Re: FORMS, validating mail was sent [message #181933 is a reply to message #181931] |
Tue, 25 June 2013 14:11 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/25/2013 9:19 AM, Thomas 'PointedEars' Lahn wrote:
> Gordon Burditt wrote:
>
>>>> + Your mail was dropped on the floor for having an invalid
>>>> From: address. Valid From: addresses likely include ONLY
>>>> those with the host name of the server you are sending
>>>> from and a known valid user on that system. Typically
>>>> only a few users like root can send mail with 'fake'
>>>> (off-system) From: addresses. Hint: Do NOT put a
>>>> user-supplied email address in the From: header.
>>>
>>> Utter nonsense. By that logic, Web-mail like GMail could not possibly
>>> work, and it would not be possible to have large e-mail providers in the
>>> first place (because the host name of their servers very likely differs
>>> from the domain of the From header field address).
>>
>> I certainly hope that a self-described "near newbie" is not going to try
>> to implement something of the scale of Gmail.
>>
>> 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.
>
> 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.
>
He is correct. Responsible hosting companies validate information and
will reject email with falsified From: addresses (i.e. not in the
sender's domain). It limits their interest to spammers.
>>> One must differentiate between the address used as parameter for the MAIL
>>> FROM (SMTP) command (the “Envelope-From”), and the “From” Internet
>>> message
>>> header field. The latter can be anything; the former can, in theory, be
>>> anything unless the *sending* MTA enables counter-measures. It is not
>>
>> For many default setups, the sending MTA enables countermeasures. This
>> can be turned off but not if you are stuck with an unsophisticated hosting
>> company that likes to leave settings at the default.
>>
>> For some, the receiving MTA enables countermeasures and checks *BOTH* the
>> From: line and the envelope sender to the extent that it can (which
>> usually means that the domain exists, has an MX or A record, and it
>> doesn't point to 127.0.0.1.
>
> 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.
>
Correct. And mail sent from my scripts to my local host show up as
coming from 127.0.0.1.
It is your comments which are "utter nonsense".
>> 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.
>
No, you really don't.
>> 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().
>
Again, utter nonsense. Depending on the PHP setup, the 5th parameter in
the mail() function can be used to override the envelope-from parameter.
>>> possible to change the Envelope-From with simple PHP commands like mail()
>>> as that is determined by the MTA (like sendmail) used by the PHP
>>> executable.
>>
>>> The only good part of this answer is the notion that you invite spammers
>>> if you let the end user specify the From header field address without
>>> authentification; so you should not do that, indeed. The /modus
>>> operandi/ of spammers and phishers is to harvest or buy e-mail addresses
>>> from various sources and use them also in the “From” header field value
>>> to make the message look to the recipient like a legitimate e-mail (at
>>> first). This kind of network abuse is also supported by “open relays” –
>>> MTAs that would accept and transfer mail for any MAIL FROM to any RCPT
>>> TO.
>>
>> They also use header injection, so that poorly written contact forms
>> can be misused (like an open relay) to send to lots more victims
>> than just the webmaster of the site. Spammers like that even if
>> they can't control the From: line.
>
> There is the Suhosin patch and PHP 5.4 against that.
>
That is not a fix for poor programming.
>>>> + The intended recipient has a slow DNS server. If you
>>>> send emails to 100 recipients at a time, it is likely
>>>> that at least a couple of them have slow DNS servers or
>>>> overloaded mail servers. The mail will stay in the queue
>>>> until the message has been delivered to all recipients,
>>>> and that can take days, even if 98 of them were delivered
>>>> in the first minute.
>>>
>>> Utter nonsense. DNS is only used to resolve the target host of the
>>> message, specifically to retrieve the host name from the “MX” or
>>> “A”/“AAAA” record of the target domain, and subsequently to resolve the
>>> IP address for that host name from its “A” or “AAAA” record (this
>>> double-handshake is intended as a
>>> safety feature of DNS/SMTP: there must be a host *name* for an MX).
>>> There are no DNS servers anywhere that have a respond time of minutes
>>> that would
>>
>> I suggest that nobody would know that, since software doesn't wait
>> that long for a response - it just gets treated as a nonresponse.
>
> My chkmadd(1) has been treated to a number of Usenet Froms over 10 years to
> talk SMTP to MTAs automatically for checking whether they are munged, and
> never ever has a DNS request timed out.
>
You're lucky. But then how would you know? Do you check every line of
your logs?
>> However, there are a fair number of DNS servers that don't answer,
>> perhaps because they are on the far end of a loaded DSL line. At
>> any given time there are DNS servers that are down or unreachable
>> because of hardware failure, loss of network connectivity, or power
>> failure.
>
> Name one.
>
More utter nonsense. DNS servers are like any other server. They can
crash. Their links can fail. Their power can fail. There is nothing
magic about them.
>> [more nonsense]
>
> ISTM you need professional help.
>
>
> PointedEars
>
ISTM you need basic education.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: FORMS, validating mail was sent [message #181934 is a reply to message #181931] |
Tue, 25 June 2013 15:32 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
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`
>
|
|
|
|
| Re: FORMS, validating mail was sent [message #181935 is a reply to message #181933] |
Tue, 25 June 2013 15:43 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-25 10:11 AM, Jerry Stuckle wrote:
>>> 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.
In the electrical residential wiring world, the lates NEC code is often
thought to be the "bible" describing all of what can and cannot be done
when that isn't true: The Local Zoning Rul;es & Regs are the final word;
without checking those, you may well not pass an electrical inspection.
It's the same with PHP; it is not the final word, but it is the list
of all that needs to be known with one important exception: Like the
wiring codes, the server-admins where sites are parked will have their
own rules too. Don't follow those and PHP may never run on those
servers. Your server will tell you a lot of things you need to do to
make PHP compatible with their servers; directory locations, how to use
them, what their MX et al may require, and on and on.
I don't mean to sound authorative here, just relating my own experience
based on 4 different servers I've used over the years.
Regards,
Twayne
|
|
|
|
| Re: FORMS, validating mail was sent [message #181948 is a reply to message #181931] |
Thu, 27 June 2013 15:57 |
gordonb.htsnc
Messages: 1
Registered: June 2013
Karma: 0
|
Junior Member |
|
|
> 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.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]