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