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

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

FORMS, validating mail was sent

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

Contents

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

Page 1 of 3  [1] 2 3  Next page →

#9806 — FORMS, validating mail was sent

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`

[toc] | [next] | [standalone]

#9809

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@attglobal.net
==================

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

#9811

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

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

#9813

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.

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

#9814

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@attglobal.net
==================

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

#9819

> 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.  

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

#9823

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.

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

#9855

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.

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

#9861

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`

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

#9869

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.)

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

#9870

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@mydomain.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.

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

#9872

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@mydomain.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,

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

#9871

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
>

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

#9873

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

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

#9874

>
> This don't justify

"This don't justify"?  I'm supposed to take you seriously?

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

#9876

>> + 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.

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

#9877

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

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

#9882

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

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

#9884

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@attglobal.net
==================

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

#9886

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web