• [^] # Re: C'est pas si simple l'email.

    Posté par . En réponse au journal Les emails par Neuf.... Évalué à 2.

    Et donc, quand l'anti-spam de l'utilisateur efface le mail, il faudrait aussi avertir l'autre… Bizarrement, personne ne le fait.

    Hors sujet: L'utilisateur (ou son antispam) n'efface pas son mail avec SMTP.
    Et si il efface le mail, c'est son problème. Du point de vue du protocole, il à reçu le message, et il ne peut affirmer le contraire.

    Mais si tu répond que tu accepte d'assumer la responsabilité de transmettre le mail jusqu'à son destinataire mais que tu jette le mail, tu est juste malhonnête. Et tu casse la transaction, puisqu'il n'y à plus personne pour s'assurer que le mail soit transmis.

    Idem. Ca dépend vraiment du point de vue…

    la RFC ne prévoit pas que tu puisse choisir ton point de vue comme tu en a envie. Si tu n'est pas d'accord avec la RFC, alors utilise un autre protocole et vire ton MX et ton serveur SMTP.

    Mais pour moi hors de question de perdre des ressources à informer un spammeur qu'on l'a détecté. Rappel : on parle de mails dont on est sûr que c'est du spam.

    Tu n'a rien détecté du tout, tu ne fait que des suppositions vagues. SMTP ne standardise aucun moyen pour détecter le spam, et encore moins de valider la transaction tout en jetant le mail, même si ta méthode foireuse est soit disant sure à 100%. Tout ce que tu fait n'est autre qu'une violation du protocole.

    En plus, ça te coûterai moins cher de répondre un 542 Zenitram hates you avant même que tu reçoivent le mail plutôt que de gaspiller la capacité de ton lien pour recevoir de la merde.