Onderwerp: Dit is vreemd...[php mail]

> Kan apache dit bestandje openen (bestaat het en heeft het de juiste
> rechten)?

Ja zeker. Met een simpele include("/padnaar/test/test.list"); spuugt ie
braaf de inhoud uit.
Mazzel,

Matthijs

>
> --
> Maarten
>
> The difference between theory and practice in practice is greater than the
> difference between theory and practice in theory.
>

> Errors-To levert weinig op. Probeer de 5e parameter van mail zoals
>
> -fafzender@domein.nl

Dat gaf ook geen extra info over wat er fout ging. Ik ontving niets.

mail("mijn@adres.hier","$subject","hallo","$header s","-fmijn@adres.hier");

Groeten,

Matthijs

Matthijs de Z <haalallesvoorhetstreepjeplushetstreepjezelfweg-mldz@hotmail.com> wrote:
>> Op z'n minst niet volgense de specs
>> <q src="http://www.php.net/manual/en/function.mail.php">
>> Note: You must use \r\n to separate headers, although some Unix mail
>> transfer agents may work with just a single newline (\n).
>> </q>
>
> Op mijn eigen server werkt het met een \r niet en na het testen op die
> andere, bleek het ook niet het gewenste resultaat te geven.

Je hebt gemist dat je een \r\n _alleen_ als *seperator* dient te
gebruiken.

Maar als je nu eens zelf met het handje de zut die php naar de smtpd
stuurt rechtstreeks invult, dan zal je wellicht zien waar het mis gaat!

--

Daniel Tryba

Rene Pijlman <reply.in@the.newsgroup> wrote:
>>transfer agents may work with just a single newline (\n).
>></q>
>
> Dat staat er inderdaad, maar ik heb de omgekeerde ervaring: \n
> werkt, \r\n werkt niet op mijn Linux/Apache/PHP-server.

Het heeft dan ook niets te maken met Linux, Apache of PHP. Het ligt aan
de smtpd, en die lijkt zich dus niet aan de specs te houden als ie \r\n
niet als headers seperator herkent.

--

Daniel Tryba

Matthijs de Z <haalallesvoorhetstreepjeplushetstreepjezelfweg-mldz@hotmail.com> wrote:
> Ik heb vanmiddag op php.net gezocht naar wat je bedoeld. Maar ik kan niet
> vinden hoe ik een output kan krijgen van de foutcode. Ook niet in mijn PHP
> boek. Heb je misschien een voorbeeld / een link (google leverde me ook geen
> verheldering)

Ai, wellicht is het handig als je weer eens helemaal vooraan begint te
lezen in dat boek. mail() is namelijk een _function_ die een waarde
_returned_ -> http://www.php.net/manual/en/functio...ing-values.php

Je de returnvalue van mail gebruiken om een conditie te evalueren ->
http://www.php.net/manual/en/control...-structures.if

--

Daniel Tryba

Daniel Tryba:
>Rene Pijlman <reply.in@the.newsgroup> wrote:
>>>transfer agents may work with just a single newline (\n).
>>></q>
>>
>> Dat staat er inderdaad, maar ik heb de omgekeerde ervaring: \n
>> werkt, \r\n werkt niet op mijn Linux/Apache/PHP-server.
>
>Het heeft dan ook niets te maken met Linux, Apache of PHP. Het ligt aan
>de smtpd, en die lijkt zich dus niet aan de specs te houden als ie \r\n
>niet als headers seperator herkent.

Dat zou kunnen, maar het klinkt een beetje kort door de bocht.
Het hangt ervan af of en hoe PHP de string eventueel nog bewerkt
en hoe PHP de mail aan de MTA aanbiedt.

Beide vragen zijn natuurlijk te beantwoorden door in de source
van PHP te kijken, maar daar ben ik te lui voor :-)

Het probleem is overigens niet dat \r\n niet als seperator
herkend wordt, maar dat er kennelijk nog een expansie van \r of
\n plaatsvindt, waardoor de eerste de beste \r\n separator
gezien wordt als de lege regel die headers en body scheidt.

En voor de liefhebbers: ik gebruik de Postfix MTA, misschien dat
dat er inderdaad mee te maken heeft.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in@the.newsgroup> wrote:
>>Het heeft dan ook niets te maken met Linux, Apache of PHP. Het ligt aan
>>de smtpd, en die lijkt zich dus niet aan de specs te houden als ie \r\n
>>niet als headers seperator herkent.
>
> Dat zou kunnen, maar het klinkt een beetje kort door de bocht.
> Het hangt ervan af of en hoe PHP de string eventueel nog bewerkt
> en hoe PHP de mail aan de MTA aanbiedt.

Als PHP de string bewerkt dan heet dat gewoon 'BUG'.

> Beide vragen zijn natuurlijk te beantwoorden door in de source
> van PHP te kijken, maar daar ben ik te lui voor :-)

Een nog veel eenvoudigere poging om op te lossen is het gebruik van
tcpdump/(t)ethereal.

> Het probleem is overigens niet dat \r\n niet als seperator
> herkend wordt, maar dat er kennelijk nog een expansie van \r of
> \n plaatsvindt, waardoor de eerste de beste \r\n separator
> gezien wordt als de lege regel die headers en body scheidt.

Brrrrr. Ik ben nu toch uiterst benieuwd.

--

Daniel Tryba

> > Ik heb vanmiddag op php.net gezocht naar wat je bedoeld. Maar ik kan
niet
> > vinden hoe ik een output kan krijgen van de foutcode. Ook niet in mijn
PHP
> > boek. Heb je misschien een voorbeeld / een link (google leverde me ook
geen
> > verheldering)
>
> Ai, wellicht is het handig als je weer eens helemaal vooraan begint te
> lezen in dat boek. mail() is namelijk een _function_ die een waarde
> _returned_ -> http://www.php.net/manual/en/functio...ing-values.php
>
> Je de returnvalue van mail gebruiken om een conditie te evalueren ->
> http://www.php.net/manual/en/control...-structures.if

Ik kan niets anders verzinnen dan dat je zoiets als dit zou willen zien (zal
wel weer niet goed zijn denk ik....)
========================
function test()
{
$spuuguit = mail("info@beursanalyse.info", "Subject", "Line 1\nLine 2\nLine
3");

return $spuuguit;
}


if ($spuuguit = true)
print "de mail is verwerkt door php";
========================
Ik krijg dat als waarde 'de mail is verwerkt door php'. bij if ($spuuguit ==
true), krijg ik niets te zien.

Ik heb gelijk maar een variant gemaakt op bovenstaande met dit als code:
========================
function test()
{
$spuuguit = mail("info@beursanalyse.info", "Subject", "Line 1\nLine 2\nLine
3");

return $spuuguit;
}


if (test() == true)
print "de mail is verwerkt door php";
========================
Ook daarmee kreeg ik 'de mail is verwerkt door php' te zien. Als ik het goed
heb, betekend het dus dat php de mail functie wel correct afhandeld.
Als dit niet klopt, zou je me dan even willen laten zien wat je dan bedoelt,
want ik weet het niet.
Groeten,

Matthijs


>
> --
>
> Daniel Tryba

> Maar als je nu eens zelf met het handje de zut die php naar de smtpd
> stuurt rechtstreeks invult, dan zal je wellicht zien waar het mis gaat!

Huh, wat bedoel je met rechtstreeks invult?
Groeten,

Matthijs

Matthijs de Z <haalallesvoorhetstreepjeplushetstreepjezelfweg-mldz@hotmail.com> wrote:
> Ik kan niets anders verzinnen dan dat je zoiets als dit zou willen zien (zal
> wel weer niet goed zijn denk ik....)

Men had je natuurlijk ook direct de oplossing kunnen vertellen, maar
hier leer je meer van

> ========================
> function test()
> {
> $spuuguit = mail("info@beursanalyse.info", "Subject", "Line 1\nLine 2\nLine
> 3");
>
> return $spuuguit;
> }
>
>
> if ($spuuguit = true)
> print "de mail is verwerkt door php";
> ========================
> Ik krijg dat als waarde 'de mail is verwerkt door php'. bij if ($spuuguit ==
> true), krijg ik niets te zien.

Hier is het probleem dat de scope van $spuuguit buiten de scope van de
if valt (http://www.php.net/manual/en/languag...bles.scope.php)
*plus* het gebruik van = ipv == (resp. toekenning en verglijking) *en*
dat de functie test nergens wordt aangeroepen.

Bovenstaande stukje code is dus niet veel soeps (zoals je zelf al
vreesde

> Ik heb gelijk maar een variant gemaakt op bovenstaande met dit als code:

Tadaa, zelf werkzaamheid.

> ========================
> function test()
> {
> $spuuguit = mail("info@beursanalyse.info", "Subject", "Line 1\nLine 2\nLine
> 3");
>
> return $spuuguit;
> }
>
>
> if (test() == true)
> print "de mail is verwerkt door php";
> ========================
> Ook daarmee kreeg ik 'de mail is verwerkt door php' te zien. Als ik het goed
> heb, betekend het dus dat php de mail functie wel correct afhandeld.

Bingo. Deze keer een goed test() (alhoewel ik niet test zou gebruiken
omdat die naam erg ruikt naar een reserved woord). Inprincipe betekent
het dat het mis gaat bij de smtp server die de mail moet afhandelen.

Probeer eens direct met bv telnet vanaf de host een mailtje te versturen
(zie bv rfc 821 hoe dat precies moet (http://www.ietf.org/rfc/rfc821.txt)):

> telnet 0 25
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 localhost ESMTP Postfix 2.0.2 TLS+IPv6 1.11
helo localhost
250 localhost
MAIL FROM: me@localhost
250 Ok
RCPT TO: me@localhost
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
tst
..
250 Ok: queued as 8A6BD6B

q500 Error: bad syntax
uit
221 Bye
Connection closed by foreign host

> Als dit niet klopt, zou je me dan even willen laten zien wat je dan bedoelt,
> want ik weet het niet.

Het klopt wel, maar is een beetje omslachtig. Je mag de returncode van
mail() ook direct testen:

if(mail(...))
{
echo 'Mailtje is verstuurd';
}
else
{
die('Ooops, mail() deed niet wat verwacht werd';
}

--

Daniel Tryba

In article <b5t0bn$9ja$1@nl-news.euro.net>, "Matthijs de Z" <haalallesvoorhetstreepjeplushetstreepjezelfweg-mldz@hotmail.com> wrote:
>wel weer niet goed zijn denk ik....)
>========================
>function test()
>{
>$spuuguit = mail("info@beursanalyse.info", "Subject", "Line 1\nLine 2\nLine
>3");
>
> return $spuuguit;
>}
>
>
>if ($spuuguit = true)
> print "de mail is verwerkt door php";
>========================
>Ik krijg dat als waarde 'de mail is verwerkt door php'. bij if ($spuuguit ==
>true), krijg ik niets te zien.

klopt want je kijkt nu niet of $spuuguit de waarde true heeft, maar je
kent aan $spuuguit de waarde true toe, als dat goed gaat, dan wordt de
mail is verwerkt door php getoond (ergo heeft niet te maken met de test).
Voor testdoeleinden zou je dus iets kunnen doen als:
$spuuguit=mail (dit dus keurig invullen);
if ($spuuguit==true)
echo "mailen is hiero goed gegaan";
elseif ($spuuguit==false)
echo "mailen is niet goed gegaan";
else
echo "ongeldige waarde spuuguit: $spuuguit";


>
>Ik heb gelijk maar een variant gemaakt op bovenstaande met dit als code:
>========================
>function test()
>{
>$spuuguit = mail("info@beursanalyse.info", "Subject", "Line 1\nLine 2\nLine
>3");
>
> return $spuuguit;
>}
>
>
>if (test() == true)
> print "de mail is verwerkt door php";
>========================
>Ook daarmee kreeg ik 'de mail is verwerkt door php' te zien. Als ik het goed
>heb, betekend het dus dat php de mail functie wel correct afhandeld.
>Als dit niet klopt, zou je me dan even willen laten zien wat je dan bedoelt,
>want ik weet het niet.

hmmm dit suggereert toch dat de mailfunctie het wel goed doet, of zie
ik iets over het hoofd, maar je hebt nu dus geen additionele headers
gezet (line 1 etc komt in de body van het bericht....).

Jaap-Andre

> Men had je natuurlijk ook direct de oplossing kunnen vertellen, maar
> hier leer je meer van

Helemaal mee eens ;-)

<knip verkeerde code>

> Bovenstaande stukje code is dus niet veel soeps (zoals je zelf al
> vreesde

> > Ik heb gelijk maar een variant gemaakt op bovenstaande met dit als code:
>
> Tadaa, zelf werkzaamheid.

Jahoe! Ben ik even blij ;-P

<knip juiste code>

> > Ook daarmee kreeg ik 'de mail is verwerkt door php' te zien. Als ik het
goed
> > heb, betekend het dus dat php de mail functie wel correct afhandeld.

> Bingo. Deze keer een goed test() (alhoewel ik niet test zou gebruiken
> omdat die naam erg ruikt naar een reserved woord). Inprincipe betekent
> het dat het mis gaat bij de smtp server die de mail moet afhandelen.
>
> Probeer eens direct met bv telnet vanaf de host een mailtje te versturen
> (zie bv rfc 821 hoe dat precies moet
(http://www.ietf.org/rfc/rfc821.txt)):

helaas heeft die account geen telnet / ssh toegang. Ik heb de host dan ook
maar een mailtje gestuurd, want blijkbaar zit het probleem toch op de server
en niet zo zeer in de script code.

> Het klopt wel, maar is een beetje omslachtig. Je mag de returncode van

En ik maar denken dat het te simpel zou zijn.... :-D
Bedankt voor de moeite en de groeten,

Matthijs

> mail() ook direct testen:
>
> if(mail(...))
> {
> echo 'Mailtje is verstuurd';
> }
> else
> {
> die('Ooops, mail() deed niet wat verwacht werd';
> }
>
> --
>
> Daniel Tryba
>

> hmmm dit suggereert toch dat de mailfunctie het wel goed doet, of zie
> ik iets over het hoofd, maar je hebt nu dus geen additionele headers
> gezet (line 1 etc komt in de body van het bericht....).

bedankt voor de reactie, ik heb een mailtje verstuurd naar de host in de
hoop dat ze het oplossen.
Groeten,

Matthijs

>
> Jaap-Andre

Matthijs de Z <haalallesvoorhetstreepjeplushetstreepjezelfweg-mldz@hotmail.com> wrote:
>> Probeer eens direct met bv telnet vanaf de host een mailtje te versturen
>> (zie bv rfc 821 hoe dat precies moet
>
> helaas heeft die account geen telnet / ssh toegang. Ik heb de host dan ook
> maar een mailtje gestuurd, want blijkbaar zit het probleem toch op de server
> en niet zo zeer in de script code.

Het kan ook met PHP hoor. Kijk eens bij http://www.phpclasses.org/ (moet
je wel voor registeren): en zoek op 'sendmail', daar zijn wel enkele
classes te vinden om tegen een willekeurige smtpd te lullen, eentje die
ik ooit daarvan gebruikt heb had een mooie debug optie om de smtp sessie
weer te geven (weet alleen niet meer welke .

BTW een andere optie is om "de sendmail binary" direct aan te roepen met
popen (moet je natuurlijk wel weten waar die staat (/usr/lib/sendmail of
/usr/sbin/sendmail zijn volgens mij de meest voorkomende plekken):

if($fp=popen("/path/naar/sendmail -t -i","w"))
{
$message=<<<EOF
From: $from
To: $to
Subject: 'tst'

tst
EOF;

fwrite($fp,$message);
pclose($fp);
}

--

Daniel Tryba

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote:
> Het kan ook met PHP hoor. Kijk eens bij http://www.phpclasses.org/ (moet
> je wel voor registeren): en zoek op 'sendmail', daar zijn wel enkele
> classes te vinden om tegen een willekeurige smtpd te lullen, eentje die
> ik ooit daarvan gebruikt heb had een mooie debug optie om de smtp sessie
> weer te geven (weet alleen niet meer welke .

Volgens mij was het 'smtpclass'
(http://phpclasses.php-start.de/brows...ackage/14.html)

BTW als je tegen een willekeurige smtpd wilt praten zul je zeer
waarschijnlijk (hopelijk) tegen problemen met relaying aanlopen. Je zult
zeer waarschijnlijk de server van de provider moeten gebruiken waar je
je php zut gehost heb.

--

Daniel Tryba