Indy 10 und SASLCRAMMD5

[Sergej_Molotov]

Hallo Zusammen,

ich versuche seit heute dem Indy-SMTP-Client beim Login auf einem E-Mail-Server das SASL zu benutzen. Leider erhalte ich eine Null-Pointer-Exception aus den tiefen der Indy Komponente. Mit dem Typen TIdSASLLOGIN geht alles wunderbar.

Vom Mailserver (Linux Postfix) erhalte ich folgende Meldung:
Jul 13 09:35:45 unicd postfix/smtpd[14266]: warning: SASL authentication failure: need authentication name
Jul 13 09:35:45 unicd postfix/smtpd[14266]: warning: [e-mail][172.16.16.88]: SASL CRAM-MD5 authentication failed: bad protocol / cancel
Jul 13 09:35:45 unicd postfix/smtpd[14266]: > [e-mail][172.16.16.88]: 535 5.7.8 Error: authentication failed: bad protocol / cancel


Die TidSASLCRAMMD5 Komponente habe ich natürlich mit einer TIdUserPassProvider Komponente verbunden.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  dummy : Boolean;
begin
  try
    IdSMTP1.Connect;

    if IdSMTP1.Connected then
    begin
      try
        IdUserPassProvider1.Username := 'dcssdfgsdjgfsdhjfgdsfsasfgsdfg';
        IdUserPassProvider1.Password := 'dcssdfgsdjgfsdhjfgsfgsdfg';
        IdSMTP1.Authenticate; // Hier kommt die Exception
        dummy := true;
      except
        dummy := false;
      end;

      if dummy then
      begin
        try
          IdSMTP1.Send(IdMessage1);
        except

        end;
      end;
      IdSMTP1.Disconnect();
    end;
  except

  end;
end;

DFM

Delphi-Quellcode:

object IdSMTP1: TIdSMTP
    PipeLine = False
    AuthType = atSASL
    Host = '172.16.16.51'
    SASLMechanisms = <
      item
        SASL = IdSASLCRAMMD51
      end>
    Left = 136
    Top = 240
  end
  object IdSASLCRAMMD51: TIdSASLCRAMMD5
    UserPassProvider = IdUserPassProvider1
    Left = 136
    Top = 200
  end
  object IdUserPassProvider1: TIdUserPassProvider
    Username = 'dcssdfgsdjgfsdhjfgdsfsasfgsdfg'
    Password = 'dcssdfgsdjgfsdhjfgsfgsdfg'
    Left = 136
    Top = 160
  end

Mit Hilfe der ICS-Komponente kann ich den CRAMMD5-Login durchführen. Also es liegt nach meiner Meinung nicht am Server. Ich muss leider die Indy-Komponente benutzen, da diese SSL unterstützt.

Hat jemand von euch bereits Erfahren mit SASL und Indy 10 gemacht und kann mir vielleicht einen Tip geben, was ich falsch mache, oder ob die Komponente Buggy ist.

[SubData]

Ist das die neuste Indy 10? Also ausm CVS?

[Sergej_Molotov]

Ich würde sagen nein.
Das ist die Indy 10 Version, welche mit Delphi 2005 damals ausgeliefert wurde. Ich habe eben auch schon mal versucht, die neue Version einzubinden, bin aber mit einem Einsprungsfehler beim Installieren der dcl* Komponente stehen geblieben. Den Rathschlag aus diesem Forum alle Indy-Dateien aus \lib\debug sowie die Pakete zu entfernen, bin ich noch nicht nachgegangen. Da das Delphi schon die Aktivierungsgrenze überschritten hat, möchte ich mir die Version nicht zerschießen.

Hast du denn Erfahrungen bzgl. der älteren Version???

[SubData]

Ja, ich hatte das gleiche Problem.
Nach dem Update ging es sofort.

Edit: Ich hatte aber ein separates Setup, da bei D7 noch die 9er bei war.

[Sergej_Molotov]

Ich versuch jetzt mal nen Delphi 5 mit der aktuellsten Version von Indy 10 in ner VM zu installieren. Werd mich mal wieder melden, falls es geklappt hat.

Aber erst einmal Danke für den Hinweis.

[Assertor]

Zitat:

Zitat von Sergej_Molotov

Da das Delphi schon die Aktivierungsgrenze überschritten hat, möchte ich mir die Version nicht zerschießen.

Also ich lasse durch den Support in so einem Fall meinen Aktivierungszähler immer hochsetzen. Das machen die ohne Probleme und sind dabei sehr nett.

Zur älteren Version kann ich nicht viel sagen, aber:

- Früher galt die Indy 9 als stabiler, diese ist aber seit langem überholt und ist nun selbst manchmal überfordert
- Indy 10 aus der Delphi-Installation ist manchmal nicht die Beste. Hier ließe sich groß ausholen, wie die Indy's eigentlich ins Delphi kommen und was da von beiden Seiten schiefgehen kann...

Ich selbst habe 10.2.3 bzw. auch das aktuelle aus dem SVN (@Subdata: wir nutzen SVN, nicht CVS) im produktivem Einsatz.

Gruß Assertor

[Sergej_Molotov]

So, habe gerade jetzt die Delphi Version 2006 in der VM installiert. Bei der Installation hatte ich leider keine Möglichkeit, die Installation von Indy zu unterbinden.

Nach der Installation habe ich folgende Schritte durchgeführt:
SVN-Version aus dem Trunc ausgecheckt (laut makeindyrpm.sh ist die Version INDYVERSION=10.2.0.1).

@Assertor
woher hast du denn die Version 10.2.3. In den SVN-Tags existiert nur die Version 10.1.1 und im Trunc s.o.

1. Indy-Packages aus den installierten Komponenten in Delphi 2006 entfernen
2. Delphi 2006 beenden
3. Alte Indy Files auf $BDS$\lib\debug entfernen
4. Alte Indy Files auf $BDS$\lib entfernen
5. Alte Indy Files auf $BDS$\source entfernen
6. Alte Indy Files auf $BDS$\Bin entfernen
6. Sourcen von Indy mit Hilfe von SVN auschecken - svn://www.indyproject.org/indy/indy10/trunk
user = indy
password = indy
7. Folgende Packete öffnen und compilieren (NICHT installieren):
IndySystem100.bdsproj
IndyCore100.bdsproj
IndyProtocols100.bdsproj
8. Alle Projekte schließen
9. Folgende Packete öffnen und installieren:
dclIndyCore100.bdsproj
dclIndyProtocols100.bdsproj
10. Fertig (oder auch nicht)

Nachdem ich die oben gezeigten Schritte durchgeführt hatte, konnte ich auch die neue Version installieren. Danach wollte ich ein Testprojekt erstellen, in dem ich einen SMTPClient auf das MainForm packen wollte. Und siehe da, was passiert:
Prozedureinsprungspunkt konnte nicht gefunden werden (IDGlobal.....). Die Komponenten wurden nach dieser Meldung aus der Komponentenliste entfernt. Wenn ich Delphi schließe und wieder starte sind sie zwar da, aber man kann sie nicht verwenden.

@Assertor
Hast du vielleicht eine Idee, woran das liegen könnte?

Gruß
Molotov

[Assertor]

Hi Sergej,

Du müsstest auf jeden Fall eine Möglichkeit haben, die Indys nicht zu installieren. Ich habe Delphi auch ohne Indy installiert... Bei Turbo Delphi geht es auf jeden Fall (siehe Anhang).

Zitat:

Zitat von Sergej_Molotov

@Assertor
woher hast du denn die Version 10.2.3. In den SVN-Tags existiert nur die Version 10.1.1 und im Trunc s.o.

Das ist schon richtig, das Makefile makeindyrpm.sh ist nicht zum Nachprüfen der Version gedacht...

Sieh mal unter Trunk\Lib\System\IdVers.inc:

Delphi-Quellcode:

gsIdVersion = '10.2.3'; {do not localize}
gsIdProductName = 'Indy';  {do not localize}

Zitat:

Zitat von Sergej_Molotov

Und siehe da, was passiert: Prozedureinsprungspunkt konnte nicht gefunden werden (IDGlobal.....).

Du bist auch nicht alles von den alten Indys losgeworden. Delphi installiert .bpls zum Teil auch im Windows-Verzeichnis. Mach mal bitte eine Suche nach .bpls auf dem gesamten Laufwerk. Dort wirst Du noch einige mehr finden.

Das Problem mit den fehlerhaften Prozedureinsprungspunkten gibt es beim Update von Komponenten sehr häufig und ist nicht Indy-bezogen. Es passiert immer dann, wenn die IDE eine andere Version eines Packages geladen hat und nun ein inkompatibles Package geladen werden soll (z.B. Versions-Mix wie hier).

Gruß Assertor

[Sergej_Molotov]

Hallo,

also die Version, die ich von Indy verwende ist die 10.2.3 und ich kann, wie du im Screenshot richtig gezeigt hast, Indy bei der Installation deaktivieren (hab es übersehen).

Habe soeben die ganze VM durchsucht und nochmals alle Indy BPL's gelöscht. Danach habe ich auf die Fulld10.bat geklickt, die mir ja das ganze getöse erstellt.

Soweit so gut.
Ich mach also wieder das grandiose Testprogramm auf und compiliere es --> Es geht.
Ich ändere die Linker Einstellungen auf:
Map-Datei = Detailliert (wird für Eureka-Log benötigt)
Exe- und Dll-Optionen = Mit TD32-Debug-Info und Mit ext. Symbolen Debuggen

Danach einmal speichern und erzeugen. Was passiert dann.

Division durch 0 (Details) = Kommt nicht von meinen Source :wink:

Delphi-Quellcode:

 
 + $0[21FBA689]{dcc100.dll  } C:\BUILDS\TP_DBG\COM\IA32\DEBUG.OBJ. + $0
 + $0[51F06B47]{rtl100.bpl  } System.System.@HandleAnyException (Line 9980, "system.pas" + 13) + $0
 + $41[7C913786]{ntdll.dll   } RtlConvertUlongToLargeInteger + $41

Könnte dies noch an den Bibliotheks bzw. Suchpfad-Einstellungen liegen?

Meine Einstellungen:
Bib-Pfad : C:\Indy Trunc\Lib\System;C:\Indy Trunc\Lib\Core;C:\Indy Trunc\Lib\Protocols
Such-Pfad: C:\Indy Trunc\Lib\System;C:\Indy Trunc\Lib\Core;C:\Indy Trunc\Lib\Protocols

Ist da vielleicht was nicht in Ordnung?

Danke für die Unterstützung!!!

[Assertor]

Hi Sergej,

ok, es freut mich, daß die Installation jetzt soweit geht.

Zitat:

Zitat von Sergej_Molotov

Division durch 0 (Details) = Kommt nicht von meinen Source :wink:

Delphi-Quellcode:

 
 + $0[21FBA689]{dcc100.dll  } C:\BUILDS\TP_DBG\COM\IA32\DEBUG.OBJ. + $0
 + $0[51F06B47]{rtl100.bpl  } System.System.@HandleAnyException (Line 9980, "system.pas" + 13) + $0
 + $41[7C913786]{ntdll.dll   } RtlConvertUlongToLargeInteger + $41

Mit TD32-Debug-Info und Mit ext. Symbolen Debuggen

Der Fehler kommt wirklich nicht von Deinen Sourcen. Bitte verzichte, wenn möglich, auf TD32-Debug-Infos. Für das Debugging in Delphi und für EurekaLog oder madExcept werden diese nicht benötigt, höchstens für etwas wie den AQTime Profiler.

Dieses Problem ist bekannt und wird derzeit geprüft - es wurde nur noch nicht zurückportiert in den Trunk. Momentan ist der Delphi Compiler mit manchen aus C übernommenen Record-Strukturen überfordert. Dies betrifft alle Delphi Versionen.

Ich werde nochmal Rücksprache halten und dir bescheid geben.

Zitat:

Zitat von Sergej_Molotov

Danke für die Unterstützung!!!

Gerne!

Gruß Assertor