MIME attachment komt niet aan

[Anthracite]

Ik zie waarschijnlijk iets simpels over het hoofd, en heb misschien alleen maar een duwtje nodig in de juiste richting. Wie kan inzicht verschaffen?

Ik ben bezig met een embedded applicatie voor een GPRS modem en heb daarin een simpele SMTP client ingebouwd die foutmeldingen via simpele plain text berichten verstuurt. Dat werkt probleemloos.

Ook wil ik een ASCII stream van een aangesloten apparaat als attachment via een e-mail kunnen verzenden. Dat lukt niet echt. Wat er gebeurt is dat de attachment wel in de e-mail staat, maar leeg is (0 bytes). Maar nu komt het vreemde: als ik de bron van het bericht bekijk, dan staat de ASCII data wel degelijk in het mailtje, op de plek waar de attachment ook zou moeten staan. De ontvangende client interpreteert het echter niet juist. Dit heb ik in 3 clients gecontroleerd (Outlook, Thunderbird, RoundCube webmail), alle 3 geven het mailtje het zelfde weer. De ASCII stream in bv. base64 coderen behoort niet tot de mogelijkheden, ik kan alleen de directe ASCII stream doorsturen vanwege een hardware limitatie.

Hieronder de conversatie met de SMTP server, zodat duidelijk is wat er precies verzonden wordt door mijn applicatie; daaronder de bron van het ontvangen bericht, waarin de attachment dus leeg is. In de mailadressen heb ik verwijzingen naar de naam van mijn werkgever verwijderd.

code:

220 pd-mta-04.operations.mobidata -- Server ESMTP (Sun Java(tm) System Messaging Server 7.3-11.01 64bit (built Sep  1 2009))
HELO
251 pd-mta-04.operations.mobidata system name not given in HELO command, host77-62-55-245.kpn-gprs.nl [77.62.55.245].
MAIL FROM:no-reply@*****.nl
250 2.5.0 Address Ok.
RCPT TO:[e-mail]
250 2.1.5 [e-mail] OK.
RCPT TO:[e-mail]
250 2.1.5 [e-mail] OK.
DATA
354 Enter mail, end with a single ".".
Subject:[Dumpfile] Lokatie TEST Prototype WM-5
Mime-Version: 1.0
Content-type: multipart/mixed; boundary="=*=*=*=*=*="

--=*=*=*=*=*=
Content-Type: text/plain

Bijgevoegd: TEST.0129

--=*=*=*=*=*=
Content-Type: text/plain;
Content-transfer-encoding: 7bit
Content-disposition: attachment; filename=TEST.0129

11 104 1 0 11 15 3 0 0 0 0 1 0 0 1 0 23 2 14 59 0 12 23 2 14 42 0 0 0 0 0 24 4 0 0 12 1 1 0 0 20 30 40 50 60 70 80 90 100 110 120 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 77 79 68 69 77 84 69 83 84 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

--=*=*=*=*=*=--

.
250 2.5.0 Ok, envelope id [e-mail]
QUIT
221 2.3.0 Bye received. Goodbye.

De bron van het ontvangen bericht:

code:

Return-path: <no-reply@*****.nl>
Envelope-to: [e-mail]
Delivery-date: Tue, 05 Jun 2012 14:59:28 +0200
Received: from cpsmtpb-lite02.kpnxchange.com ([213.75.38.72])
    by r3.host-services.nl with esmtp (Exim 4.77)
    (envelope-from <no-reply@*****.nl>)
    id 1SbtM8-0005be-3x
    for [e-mail]; Tue, 05 Jun 2012 14:59:28 +0200
Received: from cpbrm-lite01.kpnxchange.com ([10.94.80.87]) by cpsmtpb-lite02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675);
     Tue, 5 Jun 2012 14:59:24 +0200
Received: from pd-mta-04.operations.mobidata ([62.133.124.9]) by cpbrm-lite01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675);
     Tue, 5 Jun 2012 14:59:24 +0200
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_/ZkEJCMfn2+v1a6Eg611wg)"
Received: from host77-62-55-245.kpn-gprs.nl
 (host77-62-55-245.kpn-gprs.nl [77.62.55.245])
 by mta-pub1.mms.kpn.nl (Sun Java(tm) System Messaging Server 7.3-11.01 64bit
 (built Sep  1 2009)) with SMTP id <[e-mail]> for
 [e-mail]; Tue, 05 Jun 2012 14:59:24 +0200 (CEST)
From: no-reply@*****.nl
Date-warning: Date header was inserted by mta-pub1.mms.kpn.nl
Date: Tue, 05 Jun 2012 14:59:18 +0200 (CEST)
Message-id: <[e-mail]>
Subject: [Dumpfile] Lokatie TEST Prototype WM-5
Bcc:
X-OriginalArrivalTime: 05 Jun 2012 12:59:24.0738 (UTC) FILETIME=[08613A20:01CD431B]
X-RcptDomain: mijnweb.nl
X-Antivirus-Scanner: Seems clean.  You should still use an Antivirus Scanner


--Boundary_(ID_/ZkEJCMfn2+v1a6Eg611wg)
Content-type: text/plain
Content-transfer-encoding: 7BIT

Bijgevoegd: TEST.0129

--Boundary_(ID_/ZkEJCMfn2+v1a6Eg611wg)
Content-type: text/plain; NAME=TEST.0129
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=TEST.0129
11 104 1 0 11 15 3 0 0 0 0 1 0 0 1 0 23 2 14 59 0 12 23 2 14 42 0 0 0 0 0 24 4
 0 0 12 1 1 0 0 20 30 40 50 60 70 80 90 100 110 120 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 77 79 68 69 77 84 69 83 84
 32 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 


--Boundary_(ID_/ZkEJCMfn2+v1a6Eg611wg)--

[planB]

er ontbreekt een lege regel onder

Content-disposition: attachment; filename=TEST.0129

in het ontvangen bericht.

als je die toevoegt, is de attachment niet leeg.

Nu aan jou om uit te vinden waar/waarom die regel gestripped wordt

[Anthracite]

Bedankt voor je snelle reactie.

Je hebt helemaal gelijk. De open regel ontbreekt; dat was me niet opgevallen. De oorzaak daarvan heb ik al kunnen achterhalen, en alles werkt nu naar behoren.

Bij het overschakelen naar de ASCII stream vergat ik te wachten tot de laatste <LF> verstuurd was. In de logfile stond dus alleen de <CR>, en mijn text editor geeft dan wel een regel wit weer, maar de SMTP server wil per sé die <LF> ook hebben. Die kwam niet, dus geen regel wit.

Bedankt voor het duwtje in de rug!

[Janoz]

Anthracite schreef op donderdag 07 juni 2012 @ 11:02:
Bedankt voor je snelle reactie.

Je hebt helemaal gelijk. De open regel ontbreekt; dat was me niet opgevallen. De oorzaak daarvan heb ik al kunnen achterhalen, en alles werkt nu naar behoren.

Bij het overschakelen naar de ASCII stream vergat ik te wachten tot de laatste <LF> verstuurd was. In de logfile stond dus alleen de <CR>, en mijn text editor geeft dan wel een regel wit weer, maar de SMTP server de definitie van het mail protocol ( rfc822 en opvolgers) wil per sé die <LF> ook hebben. Die kwam niet, dus geen regel wit.

Bedankt voor het duwtje in de rug!

FIFY

[Anthracite]

Als je op semantiek wil gaan spelen: het is toch echt de SMTP server die die LF wil zien, het protocol schrijft alleen voor dat die SMTP server de LF wil zien, maar het protocol zelf wil geen LF zien.

[Remus]

Anthracite schreef op donderdag 07 juni 2012 @ 12:34:
Als je op semantiek wil gaan spelen: het is toch echt de SMTP server die die LF wil zien, het protocol schrijft alleen voor dat die SMTP server de LF wil zien, maar het protocol zelf wil geen LF zien.

Het SMTP protocol zelf schrijft dit niet voor, maar het Internet Message Format (RFC 5322 en voorgangers zoals RFC 822) dat gebruikt wordt voor het bericht dat je verstuurt vereist dit wel.

Overigens vereist SMTP wel dat commands met CR/LF beeindigd worden:
http://tools.ietf.org/html/rfc2821#section-4.1

Zie onder andere
http://tools.ietf.org/html/rfc5322#section-2.1

A message consists of header fields (collectively called "the header
section of the message") followed, optionally, by a body. The header
section is a sequence of lines of characters with special syntax as
defined in this specification. The body is simply a sequence of
characters that follows the header section and is separated from the
header section by an empty line (i.e., a line with nothing preceding
the CRLF).

En de MIME standaard (RFC-2045) bouwt voort op de definities van het Internet Message Format

[ Voor 5% gewijzigd door Remus op 07-06-2012 13:33 ]

[Anthracite]

Ik snap echt wel wat je/jullie bedoelen, maar als je iemand verbetert, doe het dan goed.

Janos fixed it for me en stelde dat "de definitie van het mail protocol (rfc822 en opvolgers) wil per sé die <LF> hebben". Het protocol wil helemaal niets, je kan geen LF naar een protocol sturen. Je stuurt de LF naar de server, en het protocol schrijft de LF voor. Wat ik schreef had dus niet gefixed hoeven worden.

Semantiek.

[ Voor 7% gewijzigd door Anthracite op 07-06-2012 14:05 ]

[Remus]

Anthracite schreef op donderdag 07 juni 2012 @ 14:04:
Ik snap echt wel wat je/jullie bedoelen, maar als je iemand verbetert, doe het dan goed.

Janos fixed it for me en stelde dat "de definitie van het mail protocol (rfc822 en opvolgers) wil per sé die <LF> hebben". Het protocol wil helemaal niets, je kan geen LF naar een protocol sturen. Je stuurt de LF naar de server, en het protocol schrijft de LF voor. Wat ik schreef had dus niet gefixed hoeven worden.

Semantiek.

Zoals jij het schrijft stel je dat (enkel) jouw specifieke server het zo wil hebben (overigens je mailserver heeft er niks mee te maken: het is de mailclient in dit specifieke geval).
Dat is dus niet zo, want het protocol vereist dit gedrag en daarom wil jouw server (en alle andere complaint mailservers) het zo, dus is het in algemeen zo. Aangezien het protocol het vereist is het ook het protocol dat het wil hebben; jouw mailserver (of gezien dit probleem: de mailclient) is daarbij een implementatie van het protocol. Ergo het is nog steeds het protocol die het zo wil hebben.

offtopic:
Mierenneuken kan ik ook

[Anthracite]

Eindeloze discussie over semantiek. Ik stop ermee.

Bedankt voor de nuttige bijdragen.