Path: csiph.com!usenet.pasdenom.info!goblin2!goblin.stu.neva.ru!cyclone03.ams2.highwinds-media.com!news.highwinds-media.com!voer-me.highwinds-media.com!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <2474565.KKuniypEF1@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Tue, 25 Jun 2013 15:19:10 +0200 User-Agent: KNode/4.10.4 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <2348539.nhvccKBfxy@PointedEars.de> <6LidnRtLdZLuPFXMnZ2dnUVZ_qadnZ2d@posted.internetamerica> MIME-Version: 1.0 Lines: 142 NNTP-Posting-Date: 25 Jun 2013 15:19:12 CEST NNTP-Posting-Host: 07be5d48.newsspool4.arcor-online.net X-Trace: DXC=NCcH19mRfo;RadXUBHgFh34IUKjMdA6 X-Complaints-To: usenet-abuse@arcor.de X-Received-Bytes: 9126 Xref: csiph.com comp.lang.php: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