| 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:
|
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
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]