Is there any kind of mechanism available for Koha to use to test the existence of an email address before actually trying to send an email? It seems like there should be some way to ask email servers if the address at least exists, if not asking the status of the account, so it can make an informed decision on sending notices. Right now, Koha just sends to the address without knowing anything. If it doesn't exist, or is full, or blocked, then it is up to staff to figure it out and pass that information along to the patron. If there is some way to figure this out before sending, then we would be able have Koha do something else, like send to a secondary email address, text, phone, restrict the account, etc.
And yes, I know that every server is different, but we could teach Koha the responses of different mail servers.
There's no simple way to test the existence of an email address before actually trying to send an email. There are whole software systems that combine a number of different methods to try to guess if an email address is valid, but even then it's essentially an educated guess. So I don't think that aspect would be something included in Koha. -- However, perhaps there could be a better way of falling back to another method if one fails. Also, Koha could include an "email_verified" column. Many systems will ask you to verify your email. That could be a worthwhile addition to Koha for sure.
(In reply to David Cook from comment #2) > There's no simple way to test the existence of an email address before > actually trying to send an email. There are sites that will test. Like https://email-checker.net/. It even seems to offer an API. Even if it isn't 100%, it could offer a way to say to staff, hey, something might be wrong here. Better verify. And then we can mark if it has been verified. > However, perhaps there could be a better way of falling back to another > method if one fails. > > Also, Koha could include an "email_verified" column. Many systems will ask > you to verify your email. That could be a worthwhile addition to Koha for > sure. Yes, I have actually filed another bug somewhere asking for that very thing. Maybe someday. :)
(In reply to Christopher Brannon from comment #3) > (In reply to David Cook from comment #2) > > There's no simple way to test the existence of an email address before > > actually trying to send an email. > > There are sites that will test. Like https://email-checker.net/. It even > seems to offer an API. Even if it isn't 100%, it could offer a way to say > to staff, hey, something might be wrong here. Better verify. And then we > can mark if it has been verified. As I said before, there are entire software systems devoted to this, yes. If you look at the "How do we verify an email" section of https://email-checker.net/, you'll see that it's a multi-step process and not 100%. Koha already checks the email address format. Previously, we've talked a bit about checking the domain name and MX records, but it never went anywhere. As for simulating sending a message, that's more complex. Perhaps this is an area where a Koha plugin hook could be added. > > However, perhaps there could be a better way of falling back to another > > method if one fails. > > > > Also, Koha could include an "email_verified" column. Many systems will ask > > you to verify your email. That could be a worthwhile addition to Koha for > > sure. > > Yes, I have actually filed another bug somewhere asking for that very thing. > Maybe someday. :) If you sponsor the change, it'll be more likely to get done.
Would it not also be dangerous/a security issue if such a service existed? Guessing email addresses and testing them would be a great activity for spammers or even people who want to sell email addresses to spammers. But I like the idea of having users verify their emails and flagging verified ones.
(In reply to Katrin Fischer from comment #5) > Would it not also be dangerous/a security issue if such a service existed? > Guessing email addresses and testing them would be a great activity for > spammers or even people who want to sell email addresses to spammers. Regardless, tools exist.
But how do those tools operate and should we be using them? If you use a web service, it will know that you requested information about a certain email, giving them more information. I might not know much about how this works, but I would not want the library to use a third party vendors software and give them my email (GDPR etc.)
I have my doubts whether this should be part of Koha as ILS. I suppose that you could process/parse the mail logs from an internal mail server (if being used) in a "neighboring application" and support changing mail queue status and/or patron email address etc. via REST API in order to signal that there are issues with this address. Perhaps we need a flag to temporarily block email. Just brainstorming..
I think having the library send a verification email and flagging verified or problematic emails in Koha would be totally ok. But I think using any kind of outsite tool, API or website would be a big no-no in terms of data privacy and I also agree with Marcel that we should not implement it within Koha.
Perhaps Koha could just have an option for both email and SMS that if an email or number for SMS is given, it automatically just sends a verification link to the destination. The address is listed as unverified in the patron account and unusable until the patron responds.
(In reply to Christopher Brannon from comment #10) > Perhaps Koha could just have an option for both email and SMS that if an > email or number for SMS is given, it automatically just sends a verification > link to the destination. The address is listed as unverified in the patron > account and unusable until the patron responds. No?
Would love to discuss this further. At least flesh out an idea or workflow that we can eventually work towards.
Coming here from the thread "gmail account disabled - how to proceed?" on the koha mailing list, where someone posted that they where blocked by Google because of a high number of bounced messages. In another non-Koha project I have to send a lot of mail and we're using self-hosted mail infra. We learned that we have to very closely monitor bounces and do not send further mails to users that have permanent bounces. We do this by actually handling the incoming bounce mails, extracting the bounced email and setting the users to "blocked". And then we don't send them any more mails (at least until they change their email or we manually unblock them after inspecting the cause) I'm not sure how and if something like this would make sense to add to Koha. It would be rather complex, because getting the bounces greatly depends on the mail infra you use. We found that a web-hook / API-Endpoint that takes the email address and message id and then find the mail and set the user to "bounced" works quite well: Some of the bigger transactional mail providers will hit the web-hook; and for self-hosted mail infra we wrote an incoming mail parser that extracts the info and then hits the web-hook. BTW, regarding the original question: There is no way to check if a mail exists except sending a mail and checking for a bounce. Which is NOT RECOMMENDED!!
(In reply to Thomas Klausner from comment #13) > Coming here from the thread "gmail account disabled - how to proceed?" on > the koha mailing list, where someone posted that they where blocked by > Google because of a high number of bounced messages. > > In another non-Koha project I have to send a lot of mail and we're using > self-hosted mail infra. We learned that we have to very closely monitor > bounces and do not send further mails to users that have permanent bounces. > > We do this by actually handling the incoming bounce mails, extracting the > bounced email and setting the users to "blocked". And then we don't send > them any more mails (at least until they change their email or we manually > unblock them after inspecting the cause) > > I'm not sure how and if something like this would make sense to add to Koha. > It would be rather complex, because getting the bounces greatly depends on > the mail infra you use. We found that a web-hook / API-Endpoint that takes > the email address and message id and then find the mail and set the user to > "bounced" works quite well: Some of the bigger transactional mail providers > will hit the web-hook; and for self-hosted mail infra we wrote an incoming > mail parser that extracts the info and then hits the web-hook. > > BTW, regarding the original question: There is no way to check if a mail > exists except sending a mail and checking for a bounce. Which is NOT > RECOMMENDED!! I'm with Thomas here... I think that a means of parsing bounces, flagging the relevant accounts, and disabling notifications for those patrons is a great idea. That keeps the process internal and effective. Using an external service to check address validity would pose issues of privacy, among other things.
(In reply to Thomas Klausner from comment #13) > BTW, regarding the original question: There is no way to check if a mail > exists except sending a mail and checking for a bounce. Which is NOT > RECOMMENDED!! Well, in all the testing I've done through Verifalia, to my knowledge it does not send emails to the user. I just tested it on myself and no email. There are several of these testers out there, and they verify information with the server without sending email, as far as I understand. That said, at least an in-Koha verification process before sending out notices would be extremely helpful in protecting domain reputation. The welcome message could serve as this mechanism. It should just have a validation link back to Koha, and Koha should refrain from using that transport further (except for resending the welcome message) until the link is used and reported as valid. (It would also be wise to do this with SMS as well, as well as having the option to send the welcome through SMS.) As for bounces do to inactive, deactivated, or full accounts, that is another matter, and it WOULD be great if Koha could receive and scrape the relevant address and error messages and act accordingly. I imagine that would take much more work, but really is crucial to maintaining domain reputation without it relying on specific people to address each bounce individually. Email has been getting stricter, and I do think Koha needs to keep up with the email practices that have changed in the last 5 years or so.