Call Transfert : courriels de confirmation bloqués
Modérateur : Equipe technique
Call Transfert : courriels de confirmation bloqués
Bonjour,
Nous utilisons encore actuellement le port 25 pour émettre les messages de confirmation de Call Transfert via le relais SMTP de notre FAI.
Le port 25, massivement utilisé par les polluposteurs, est en voie de bannissement chez nombre de FAIs, dont l'un des nôtres.
Nous avons voulu reparamétrer Call Transfert avec les données d'identification propres à l'utilisation du port 587 chez ce FAI, mais le champ Login de votre interface est trop court (20 caractères !!!), ne nous permettant pas de finaliser notre paramétrage (notre identifiant pour ce compte fait 28 caractères de long, mais nous utilisons pour d'autres comptes des identifiants de 40 caractères : l'adresse de courriel complète).
Pourriez-vous nous dire dans combien de temps cette lacune sera corrigée et la version corrective de ce module disponible au téléchargement, afin que nous puissions l'installer ?
D'avance merci.
Cordialement.
Nous utilisons encore actuellement le port 25 pour émettre les messages de confirmation de Call Transfert via le relais SMTP de notre FAI.
Le port 25, massivement utilisé par les polluposteurs, est en voie de bannissement chez nombre de FAIs, dont l'un des nôtres.
Nous avons voulu reparamétrer Call Transfert avec les données d'identification propres à l'utilisation du port 587 chez ce FAI, mais le champ Login de votre interface est trop court (20 caractères !!!), ne nous permettant pas de finaliser notre paramétrage (notre identifiant pour ce compte fait 28 caractères de long, mais nous utilisons pour d'autres comptes des identifiants de 40 caractères : l'adresse de courriel complète).
Pourriez-vous nous dire dans combien de temps cette lacune sera corrigée et la version corrective de ce module disponible au téléchargement, afin que nous puissions l'installer ?
D'avance merci.
Cordialement.
Dernière modification par scp le 19 mars 2009 08:43 am, modifié 1 fois.
UP (diem perdidi)
La situation empire : pas moyen d'obtenir la confirmation systématique par courriel des renvois. Lorsque l'envoi d'un courriel d'acquittement se trouve bloqué, tous les messages d'acquittement suivants sont placés en file mais ne partent plus. Il est alors nécessaire de redémarrer CallTransfert pour "dépiler" les messages en attente. Encore une intervention manuelle et chronophage qui pourrait être évitée...
Comptez-vous rester muets devant ce dysfonctionnement ?
D'avance merci de vous manifester...
Cordialement.
La situation empire : pas moyen d'obtenir la confirmation systématique par courriel des renvois. Lorsque l'envoi d'un courriel d'acquittement se trouve bloqué, tous les messages d'acquittement suivants sont placés en file mais ne partent plus. Il est alors nécessaire de redémarrer CallTransfert pour "dépiler" les messages en attente. Encore une intervention manuelle et chronophage qui pourrait être évitée...
Comptez-vous rester muets devant ce dysfonctionnement ?
D'avance merci de vous manifester...
Cordialement.
Dernière modification par scp le 21 avr. 2009 12:14 pm, modifié 1 fois.
Bonjour,
Le problème est têtu : il persiste à se reproduire de plus en plus fréquemment, et... nous sommes toujours sans nouvelles de votre point de vue sur la question.
Nous ne sommes d'ailleurs plus seuls à faire face à des problèmes de ce genre : http://public.abm2000.com/viewtopic.php?p=2294
Dans l'attente d'une réponse de votre part,
Cordialement.
Le problème est têtu : il persiste à se reproduire de plus en plus fréquemment, et... nous sommes toujours sans nouvelles de votre point de vue sur la question.
Nous ne sommes d'ailleurs plus seuls à faire face à des problèmes de ce genre : http://public.abm2000.com/viewtopic.php?p=2294
Dans l'attente d'une réponse de votre part,
Cordialement.
Contrat Premium
Depuis pratiquement une semaine aucun email confirmant les renvois ou annulations n'a été réceptionné.
Pour nous assurer du bon fonctionnement de Call Transfert nous devons nous déplacer jusqu'au serveur hébergeant l'application et vérifier que les transferts ou annulations de transferts ont bien été effectués, ce qui, vous en conviendrez, n'est pas pratique.
Dans l'attente de votre réponse rapide.
PS : le forum est resté à l'heure d'hiver.
Depuis pratiquement une semaine aucun email confirmant les renvois ou annulations n'a été réceptionné.
Pour nous assurer du bon fonctionnement de Call Transfert nous devons nous déplacer jusqu'au serveur hébergeant l'application et vérifier que les transferts ou annulations de transferts ont bien été effectués, ce qui, vous en conviendrez, n'est pas pratique.
Dans l'attente de votre réponse rapide.
PS : le forum est resté à l'heure d'hiver.
Dernière modification par scp le 10 avr. 2009 11:43 am, modifié 1 fois.
Rebonjour,
Comme indiqué précédemment, nous aimerions pouvoir utiliser le SMTP authentifié de notre FAI principal : smtp.msa.orange-business.com via le port 587 (avec authentification) ou celui d'un autre FAI (nous avons plusieurs fournisseurs), toujours avec le même type de contraintes (spécification du port et authentification à l'émission). C'est actuellement impossible du fait de la limitation de la zone de saisie du champ "login" de l'interface de Call Transfert à 20 caractères (non respect des normes en vigueur) !
Nous employons donc actuellement un autre serveur SMTP, d'un FAI secondaire : smtp.phonemessage.fr, via le port 25, sans authentification.
Veuillez noter qu'Orange avertit sa clientèle que l'usage du port 25 peut être interrompu à tout instant sans préavis : http://assistance.orange.fr/1354.php?dub=2&
D'avance merci pour examiner ce problème gênant.
Cordialement.
Comme indiqué précédemment, nous aimerions pouvoir utiliser le SMTP authentifié de notre FAI principal : smtp.msa.orange-business.com via le port 587 (avec authentification) ou celui d'un autre FAI (nous avons plusieurs fournisseurs), toujours avec le même type de contraintes (spécification du port et authentification à l'émission). C'est actuellement impossible du fait de la limitation de la zone de saisie du champ "login" de l'interface de Call Transfert à 20 caractères (non respect des normes en vigueur) !
Nous employons donc actuellement un autre serveur SMTP, d'un FAI secondaire : smtp.phonemessage.fr, via le port 25, sans authentification.
Veuillez noter qu'Orange avertit sa clientèle que l'usage du port 25 peut être interrompu à tout instant sans préavis : http://assistance.orange.fr/1354.php?dub=2&
D'avance merci pour examiner ce problème gênant.
Cordialement.
Dernière modification par scp le 21 avr. 2009 12:20 pm, modifié 2 fois.
-
Romain
- Administrateur
- Messages : 692
- Inscription : 10 janv. 2006 10:36 am
- Localisation : Paris 13eme
Re:
Le problème à été remonté.
Panneau de l’utilisateur > Préférences du forum > Modifier les préférences générales > Heure d’été en vigueur: OUIscp a écrit :
PS : le forum est resté à l'heure d'hiver.
-
Romain
- Administrateur
- Messages : 692
- Inscription : 10 janv. 2006 10:36 am
- Localisation : Paris 13eme
Re: Call Transfert : courriels de confirmation bloqués
Lorsque cette fonctionnalité sera proposée sur le Call Transfert nous ne manquerons pas de le dire sur le forum. Pour le moment aucune date pour cette évo.
En attendant vous pouvez installer une serveur SMTP sur votre réseau afin de pouvoir utiliser la fonction d'envois de mails sur le port 25 ?
En attendant vous pouvez installer une serveur SMTP sur votre réseau afin de pouvoir utiliser la fonction d'envois de mails sur le port 25 ?
Re: Call Transfert : courriels de confirmation bloqués
Bonjour,
Ne confondez pas : il ne s'agit pas d'une évolution, puisque les caractéristiques et les normes des communications électroniques sont publiées et archiconnues depuis des années et antérieures à EmailSender (1982 pour la RFC 822, 2001 pour les RFC 2821 et 2822) : les limitations de longueur des champs sont des erreurs, et nous attendons donc des corrections avant de parler d'évolutions.
L'installation d'un relais SMTP sur notre réseau serait effectivement un palliatif, mais que dire de la lourdeur de son administration ?
Il est tout de même assez difficile de considérer que le type de correction demandé puisse consommer d'immenses ressources...
Cordialement.
Ne confondez pas : il ne s'agit pas d'une évolution, puisque les caractéristiques et les normes des communications électroniques sont publiées et archiconnues depuis des années et antérieures à EmailSender (1982 pour la RFC 822, 2001 pour les RFC 2821 et 2822) : les limitations de longueur des champs sont des erreurs, et nous attendons donc des corrections avant de parler d'évolutions.
L'installation d'un relais SMTP sur notre réseau serait effectivement un palliatif, mais que dire de la lourdeur de son administration ?
Il est tout de même assez difficile de considérer que le type de correction demandé puisse consommer d'immenses ressources...
Cordialement.
Qui est en ligne ?
Utilisateurs parcourant ce forum : ClaudeBot [Bot] et 0 invité