Was kann man von einem Programm Names IDEP erwarten?

Eigentlich müsste einem der Name ja schon stützig machen, das deutsche Finanzamt nennt ihre Software Elster – in Österreich bringen sie ein Programm namens IDEP an dem Mann. In dem Fall nicht vom Finanzamt sonder von „Statistik Austria“.

IDEP kümmert sich darum dass alle Firmen ihre EU Importe schön brav melden und irgend ein Bürokrat durch die ach so wichtig und geilen Zahlen ein, zwei Dosen Viagra weniger braucht…
Mal vom Aufwand abgesehen der durch die händische Erfassung der Daten im Idep entsteht, mag’s ja ganz nett sein wenn man den „freien Warenverkehr“ auf diese Art und Weise kontrolliert.
Allerdings sollte man es dann doch schaffen eine Software zur Verfügung zu stellen die sich an geltende Standards hält!!

IDEP ist da anders – in der Hilfe noch ausdrücklich erwähnt unterstützt IDEP ftp über Proxy server, eine Seite vorher wird noch explizit erwähnt dass IDEP allerdings nur aktives FTP spricht und man daher die Firewall entsprechend einstellen muss.
Ja geil – wer nimmt denn heute noch aktives FTP her???

Aber egal, zum testen mal die Zugangsdaten in einem Browser der mit entsprechenden Proxy Einstellungen versehen ist eingegeben und siehe da -> alles funktioniert wie gewünscht.
Also gleich im IDEP die Proxy Einstellungen entsprechend angepasst und getestet – außer einer Fehlermeldung kommt aber nicht recht viel zum Vorschein…

C 09:24:17 Proxy: http://proxy:8080/
C 09:24:17 Checking connection state…
C 09:24:17 Connection state: Connected= True
C 09:24:17 Connection state: Configured
C 09:24:17 Connection state: Lan
C 09:24:17 Connection state: Proxy
C 09:24:17 Connection state: RasInstalled
C 09:24:17 Connection state checked code 0
C 09:24:17 Connect: Already connected
F 09:24:17 Current directory C:ProgrammeEUROSTATIDEP CN8
F 09:24:17 Logging in ftp.statistik.gv.at 21
P 09:24:17 Resolving ftp.statistik.gv.at
P 09:24:17 ftp.statistik.gv.at resolved 193.170.163.75
P 09:24:17 connecting ftp.statistik.gv.at 21
P 09:24:38 SocketException 10060
System.Net.Sockets.SocketException: Ein Verbindungsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht ordnungsgem???? reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat
at System.Net.Sockets.Socket.Connect(EndPoint remoteEP)
at Inet.ProtocolSocket.Connect()
F 09:24:38 Connection failed
F 09:24:46 Close connection
P 09:24:46 Closing socket
P 09:24:46 SocketException 10057
System.Net.Sockets.SocketException: Eine Anforderung zum Senden oder Empfangen von Daten wurde verhindert, da der Socket nicht verbunden ist und (beim Senden ??ber einen Datagrammsocket mit einem sendto-Aufruf) keine Adresse angegeben wurde
at System.Net.Sockets.Socket.Shutdown(SocketShutdown how)
at Inet.ProtocolSocket.Close()
F 09:24:46 Connection closed
C 09:24:46 Disconnect: does not have to disconnect

Ja wunderbar – was soll man davon halten?
Nicht wirklich viel Tatsache ist dass IDEP wohl zu dumm ist die offensichtlich ja korrekt ausgelesenen Proxy Daten auch wirklich zu verwenden!

Ein Blick in das Firewall Logfile verrät näheres:

Sep 28 08:37:24 brutus kernel: RULE 30 — DENY IN=eth1 OUT=eth0 SRC=192.168.1.34 DST=193.170.163.75 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=16303 DF PROTO=TCP SPT=1171 DPT=21 WINDOW=65535 RES=0x00 SYN URGP=0

Also pfeift IDEP ganz einfach auf die Proxy Einstellungen und versuchts dann doch direkt…
Na ja es gibt ja noch die Option das ganze per E-Mail zu versenden! 🙂
Gleich an’s Werk und auf E-Mail umgestellt – da wir in der Firma einen Postfix-Server als SMTP-Server betreiben dessen Daten eingegeben und die Benachrichtigung versendet.
Siehe da IDEP schafft es tatsächlich die Mail zu schicken, allerdings bringt IDEP dann die geniale Meldung dass der Versand nicht geklappt hat – das Server Logfile behauptet an der Stelle was anderes!

Also ein Blick in’s Logfile von IDEP:

C 11:50:57 Proxy: http://proxy:8080/
C 11:50:57 Checking connection state…
C 11:50:57 Connection state: Connected= True
C 11:50:57 Connection state: Lan
C 11:50:57 Connection state: RasInstalled
C 11:50:57 Connection state checked code 0
C 11:50:57 Connect: Already connected
S 11:50:57 Current directory C:ProgrammeEUROSTATIDEP CN8
S 11:50:57 MailClient
S 11:50:57 Logging in mail 25
P 11:50:57 Resolving mail
P 11:50:57 mail resolved 192.168.1.10
P 11:50:57 connecting mail 25
P 11:50:57 connected
P 11:50:57 REPLY 220 mail ESMTP Postfix (Ubuntu)
( 46 bytes)
P 11:50:57 REPLY# 220
S 11:50:57 Hostname ab1356
P 11:50:57 COMMAND {HELO ab1356}
P 11:50:57 REPLY 250 mail
( 23 bytes)
P 11:50:57 REPLY# 250
S 11:50:57 LogOn succesful
P 11:50:57 COMMAND MAIL FROM:ab@example.com
P 11:50:57 REPLY 250 Ok
( 8 bytes)
P 11:50:57 REPLY# 250
P 11:50:57 COMMAND RCPT TO:daten@statistik.gv.at
P 11:50:57 REPLY 250 Ok
( 8 bytes)
P 11:50:57 REPLY# 250
P 11:50:57 COMMAND {DATA}
P 11:50:57 REPLY# 354
S 11:50:57 Headers Message-ID:
From: ab@example.com
To: daten@statistik.gv.at
Subject: INTATU32214109-001
Date: Fri, 24 Aug 2007 09:50:57 GMT
Organization: testfirma
X-Mailer: : IDEP/CN8 2.3.0.3
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=“B-)__REVOLUX__*IDEP.TNG_Mailer_Boundary*__“
If you see this your Email client doesn’t cope with MIME very well.
–B-)__REVOLUX__*IDEP.TNG_Mailer_Boundary*__
Content-Type: text/plain;
charset=“iso-8859-1″
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
S 11:50:57 Start message
P 11:50:57 Send data: 628 bytes sent 628 needed sending
S 11:50:57 Attaching C:DOKUME~1\TempTNGATU32214109-001_24082007_115057.EDI TNGATU32214109-001_24082007_115057
S 11:50:57 MIME header –B-)__REVOLUX__*IDEP.TNG_Mailer_Boundary*__
Content-Type: application/x-notepad;name=“TNGATU32214109-001_24082007_115057″
Content-Transfer-Encoding: base64
Content-Description: TNGATU32214109-001_24082007_115057(EDIFACT Interchange)
Content-Disposition: attachment; fileName=“TNGATU32214109-001_24082007_115057″
P 11:50:57 Send data: 324 bytes sent 324 needed sending
S 11:50:57 Attaching C:DOKUME~1TempTNGATU32214109-001_24082007_115057.EDI TNGATU32214109-001_24082007_115057 Size 1542 bytes
S 11:50:57 File attached succesfully 1542 bytes 2 blocks
S 11:50:57 Ending message
P 11:50:57 Send data: 52 bytes sent 52 needed sending
P 11:50:57 COMMAND {
.
}
P 11:50:57 REPLY 250 Ok: queued as 26787FF2D
500 Error: bad syntax
( 52 bytes)
P 11:50:57 REPLY# 500
S 11:50:57 END DATA expects 250
S 11:50:57 Close connection
P 11:50:57 COMMAND {QUIT}
P 11:50:57 REPLY 221 Bye
( 9 bytes)
P 11:50:57 REPLY# 221
P 11:50:57 Closing socket
P 11:50:57 Socket Closed
S 11:50:57 Connection closed
C 11:50:57 Disconnect: does not have to disconnect

Vom Ablauf her würde ich mal sagen erkennt man wunderbar dass die Mail rausgegangen ist – zumindest wenn man von SMTP ein bisserl was weiß.
IDEP interpretiert das ganze ein wenig anders, „250 Ok: queued as 26787FF2D“ wird da wohl nicht akzeptiert und als Fehler angesehen!

P 11:50:57 REPLY 250 Ok: queued as 26787FF2D
500 Error: bad syntax
( 52 bytes)

Tja, das Mail ist raus – die Antwort kommt wenige Sekunden später, Meldung vom Server angenommen und im Intrastat System korrekt eingetragen.

Eigentlich könnte man zufrieden sein, wenn da nicht IDEP hartnäckig behaupten würde die Meldung ist noch nicht gesendet worden. Aktuelle Meldungen gehen erst raus wenn die alten als gesendet in der Datenbank stehen…

Es gäbe dann noch die Möglichkeit auf MAPI Mail umzustellen, aber wer auf Microsoft Software nach Möglichkeit verzichtet wird kaum einen MAPI fähigen Mail-Client installiert haben.
Bleibt nur noch eines:
Meldung händisch generieren indem die Datei an ein Mail an die oben angeführte Adresse geschickt wird, IDEP ist dann wenigstens so schlau daß es diese Möglichkeit noch anbietet…
Keine Ahnung ob die Programmierer den Namen IDEP auf sich selbst oder das Programm bezogen haben, es war aber auf jeden Fall die richtige Wahl!