Re: [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
In this release, we will implement mail bounce detection (i.e. an outgoing message has permanently failed delivery) and also unsubscription (i.e. one- click unsubscribe from a mail client). Once an address is undeliverable or unsubscribed, we will not send further Whois update acknowledgements or notifications to that address. However we will continue to send targeted notifications where required by RIPE policy (e.g. abuse-c validation, RIPE- NONAUTH route object cleanup etc.).
Thank you for your ongoing work and please forgive my ignorance on this subject. IIUC, all addresses, which are unavailable for the sending RIPE MTA once, will be blocked until manual interference. The cause of this error might be located in the RIPE MTA, the RIPE uplink, a global network routing issue, a peering issue, our uplink, our local MTA, or even a DNS(sec) issue. In consequence we will not receive any notifications anymore unless we try to update the very object in question and read the warning box the RIPE-DB update web form. Hence we can't rely on the email notifications anymore?
Hi Lutz,
On 15 Mar 2024, at 08:57, Lutz Donnerhacke via db-wg <db-wg@ripe.net> wrote:
In this release, we will implement mail bounce detection (i.e. an outgoing message has permanently failed delivery) and also unsubscription (i.e. one- click unsubscribe from a mail client). Once an address is undeliverable or unsubscribed, we will not send further Whois update acknowledgements or notifications to that address. However we will continue to send targeted notifications where required by RIPE policy (e.g. abuse-c validation, RIPE- NONAUTH route object cleanup etc.).
Thank you for your ongoing work and please forgive my ignorance on this subject.
Thanks for your feedback. I welcome any feedback from the community on how best to implement these requirements.
IIUC, all addresses, which are unavailable for the sending RIPE MTA once, will be blocked until manual interference. The cause of this error might be located in the RIPE MTA, the RIPE uplink, a global network routing issue, a peering issue, our uplink, our local MTA, or even a DNS(sec) issue. In consequence we will not receive any notifications anymore unless we try to update the very object in question and read the warning box the RIPE-DB update web form.
Immediate failures from the RIPE MTA won't be counted as a permanent failure, i.e. we will retry those. Only permanent failure replies (i.e. delivery failure notifications) will mark the address as undeliverable. We will keep track of of failure replies so we can analyse the root cause (in case we have an operational issue). We plan to implement a retry mechanism for undeliverable addresses in a future Whois release, but at a sufficiently low rate (to be determined) that won't cause a mail provider to see us as spammers . We also plan to create an internal report of undeliverable addresses for resource holders, and depending on workload of the Registry team, we will make an effort to contact the responsible organisation to fix the addresses.
Hence we can't rely on the email notifications anymore?
I think this change will make notifications more reliable, as we will now detect permanent failures, i.e. we didn't know if an outgoing message failed until this release. We do need to make sure these failures get fixed however. Regards Ed
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
participants (2)
-
Edward Shryane -
Lutz Donnerhacke