Deutschsprachige CAcert Support Liste

[<ulrich AT cacert.org>]

Hi,

> -----Original Message-----
> From: Michael Nausch 
> [mailto:michael AT nausch.org]
>  
> Sent: Thursday, November 26, 2009 8:44 AM
> To: 
> cacert-de AT lists.cacert.org
> Subject: Assurance fehlgeschlagen

> HI!

> Sicherlich gibt es irgendwo einen workaround wie mit folgender  
> Situation umgegangen werden soll.

> Ein User lässt sich assuren.
> Daten des Ausweisdokumentes stimmen mit den Daten des  
> Assurance-Formulares überein, auch sonst ist keine Unstimmigkiet oder  
> Besonderheit auffällig.

> Beim späteren Versuch, die Assurance zu vervollständigen, stellt ich  
> aber fest, dass das beim Userkonto hinterlegte Geburtsdatum nicht mit  
> dem auf dem CAP-Formular übereinstimmt.

> Also erst einmal keine "Punkte vergeben"

Korrekt so.

Niemals in solch einem Fall die Assurance zuende fuehren!



> und versucht den User per  eMail anzusprechen.

Hier ist es abhaengig davon, ob der User bereits Punkte
auf sein Konto bekommen hat oder nicht.
Wenn _kein_ zusaetzlicher Text kommt, wie
User hat bereits 70 Punkte oder dergleichen,
dann User anschreiben, in der Hoffnung, dass er noch
0 Punkte hat, denn nur dann kann er auch noch
Namen und Geburtsdatum in seinem Konto aendern.

Andernfalls, sobald auch nur 1 Punkt auf seinem
Konto gelandet sind, laesst sich das Problem nur
noch mittels Dispute loesen.

Ich gehe von aus, dass in der Online Anzeige
kein weiterer Hinweis auf bereits vergebene
Punkte zu lesen war ... dann Email an
die im CAP angegebene Email Adresse ....


> Doch ewas passiert? Die eMail kommt mit einem  
> 441er zurück, sprich der für die eMailadresse
> zuständige eMailserver  
> ist nicht erreichbar?

4## code bedeutet -> temporarely not avialable
      zu gut Deutsch, versuchen Sie es spaeter
      noch einmal

4## bedeutet also, es existiert sicherlich solch
eine Domain, die Domain kann aber momentan
aufgrund technischer Schwierigkeiten nicht
erreicht werden. Das koennen Wartungsarbeiten
am Mailgateway sein, das koennen Routingprobleme
sein, das koennen Reorganisationen sein. Die
Liste laesst sich beliebig lang fortsetzen
was es da an Gruenden gibt, weswegen die
Mail im Moment nicht entgegen genommen
werden kann. Prinzipiell heisst das:
ja, da ist ein Mailer der auf die Connection
Anfrage reagiert, er nimmt im Moment
nur keine Mails an ...

Mailserver sind angehalten, in gewissen Abstaenden
immer wieder mal die Gegenstelle zu kontaktieren
um die Uebertragung dennoch durchzubekommen.
Standardmaessig sind Mailserver dafuer ausgelegt
entweder 2, manche sogar 5 Tage lang zu versuchen
Mails an ein Gateway abzuliefern, bevor ein
5xx - NDR  (Non-Delivery-Report) generiert
wird.


> So, what to do?

Dieses "spaeter" noch einmal probieren fuehrt
normalerweise ein Mailserver selbst aus
(sofern er RFC konform arbeitet)
kann man sich aber nicht 100%ig drauf verlassen.
Ich habe schon Mailserver gesehen, die
die Mail zurueckgeschickt haben, und es
dem User ueberlassen haben die Mail erneut
zu versenden ....

Generell: 1, 2 Tage abwarten.
Dann sicherheitshalber die Mail noch
einmal neu senden.




> Danke für den Tip/Info!


> cul8r,
>       Django


regards, uli   ;-)

Attachment: smime.p7s
Description: S/MIME cryptographic signature