This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
- Previous message (by thread): [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
- Next message (by thread): [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Edward Shryane
eshryane at ripe.net
Fri Mar 15 11:48:25 CET 2024
Hi Lutz, > On 15 Mar 2024, at 08:57, Lutz Donnerhacke via db-wg <db-wg at 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://mailman.ripe.net/
- Previous message (by thread): [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
- Next message (by thread): [db-wg] Complying with Mail Provider Requirements When Sending Mail from Whois
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]