[Email] TXT bijlage wordt veranderd?

[JHMvP]

Het volgende ging jarenlang goed;

• Ik maakte met Kladblok bestandjes met regellengtes van exact 100 karakters
• Ik sloeg deze bestandjes op als blablabla.TXT in ANSI-formaat
• Deze bestandjes mailde ik naar een bepaald persoon
• Deze persoon stuurde deze bestandjes door naar een emailsysteem tbv. automatische verwerking

Dit emailsysteem neemt de bestanden in ontvangst, controleert of alle regellengtes inderdaad 100 karakters zijn en leest vervolgens regel-voor-regel de betreffende data in.

Sinds kort blijkt dit echter niet meer te werken en wat blijkt; als de andere persoon mij mijn eerdergezonden email terugstuurt, blijken de regels niet meer 100 karakters te zijn. Sterker nog, het 101ste karakter is een blokje (niet-herkend karakter) en de volgende regel wordt daar doodleuk achter aan geplakt. Het .TXT attachment wordt dus gewijzigd tussen verzending en openen.

Bekijk ik het bestand in de originele email dan is het bestand nog goed; 100 karakters en geen blokjes!

Op Google kwam ik weinig interessants tegen dus heb ik één en ander uitgeprobeerd met verschillende emailclients en het gaat fout bij de volgende combinaties;

- Outlook Express <-> Outlook Express
- Outlook Express <-> Outlook 2003 (en andersom!)
- Outlook Express <-> Squirrelmail (en andersom!)
- Outlook Express -> @MAIL

...en nu komt het leuke:

@MAIL -> Squirrelmail gaat wél goed!
@MAIL -> Outlook 2003 gaat wél goed!

Ergo, het probleem (b)lijkt te liggen bij de verzendende email-client.

Mocht iemand z'n kristallen bol bij zich hebben dan is de sluitende oplossing natuurlijk welkom maar tot die tijd sta ik open voor alle input!

[Verwijderd]

Open dat txt-bestand met dat "blokje" eens in bvb. notepad++ en zet dan "codes" eens aan, wss is er een extra EOL-char geappended onderweg.. (CR / LF / CRLF)

[Verwijderd]

Mss heeft het iets te maken met het type regeleinde. Je hebt namelijk Windows, Unix,... Zoals GaensDude voorstelt die codes eens nakijken. Mss dat jouw mailclient het niet goed kan vinden met bepaalde types regeleinde. Alhoewel het mij maar raar lijkt dat die het bestand gaat veranderen daarvoor

[JHMvP]

Outlook Express op Windows XP
Outlook 2003 op Windows Server 2003
Squirrelmail op RedHat Linux
@MAIL is een webmailapplicatie (geen idee welk OS)

...dus aan verschillen van OS'sen lijkt het niet te liggen.

Nog even in het kort;

- Email in "Verzonden"-bak, ongeacht emailclient -> attachment correct
- Email in "In"-bak, ongeacht emailclient -> regeleinden in attachment gewijzigd
- Email in "In"-bak, indien verzonden door @MAIL -> regeleinden in attachment correct!

...en dat is dus pas sinds kort; daarvóór gebruikten we van alles (OE, Outlook, Lotus Notes, Squirrelmail, etc.etc.) om de bestandjes mee te verzenden en toen was er nooit een probleem.

[Bastien]

Een eventuele virusscanner misschien een optie? Dat ie scant (opent) en dan na controle attachement opslaat? Lijkt me raar maar d'r gebeuren wel meer rare dingen

En probeer terug te denken wat er mogelijk gewijzigd is qua software etc.

[JHMvP]

Okay, ik heb eens even gekeken met NotePad++ en het blijkt dat in de originele TXT-bestanden de regeleinden worden aangegeven met [CR] en [LF].

Bij de bestanden die er niet meer goed uitzien worden de regeleinden aangegeven met alleen [LF].

Dus het bestand:
-----------------------------------------------------------
Regel 1 - data[CR][LF]
Regel 2 - data[CR][LF]
-----------------------------------------------------------

...wordt in veel gevallen (zie eerdere post) dus veranderd naar
-----------------------------------------------------------
Regel 1 - data[LF]Regel 2 - data[LF]
-----------------------------------------------------------

Waarschijnlijk heeft dit inderdaad te maken met hoe bepaalde OS'sen hun emails encoden.
Hoe kan ik voorkomen dat dit gebeurt?

[Noork]

Een andere mailclient gebruiken?

[F_J_K]

Gebruik je in alle gevallen dezelfde POP- en dezelfde SMTP-server? If not: kijk daar naar.