On Wed, Oct 01, 2014 at 12:49:38AM -0700, euler wrote: > I'm pretty sure that you have encountered this kind of scenario especially if > you have enabled the item request feature where a user put a non existing > email address. You will later discover the "Delivery to the following > recipient failed permanently" message when responding to the users' > request/feedback. Although it is the user's fault for using an invalid/non > existing email address, we take our user's requests/feedback seriously and > as much as possible we want to make sure to respond or serve any of their > requests/feedbacks. Is there a workaround for this? Or is there some way to > check first and then enforce that the user will use a valid and existing > email address? Using some sort of verification link to be sent to the users' > email address like during self-registration might be overkill or a hassle to > them right? Any ideas?
We are up against fundamental characteristics of Internet mail. It's a store-and-forward system distributed over any number of links, across multiple administrative domains, with indefinite possible delays. I think the most that DSpace could reasonably do without human interaction is to verify that the address is syntactically correct. This is why you see that "we'll send you an email with a link in it" method so often: it's about the only thing that works. A possible heuristic approach: send a "we're working on it" email to the requester immediately, wait a moment for a bounce message and, if one arrives, tell the requester what the problem is and to try again. But, depending on your local network services and policies, DSpace might not be able to receive bounce messages (or any other messages) at all. Or it might take longer than the configured delay for any number of reasons. And meanwhile the user is sitting there waiting, wondering what is taking so long. (At first it seems simple: send an SMTP VRFY to the distant host and look at the response. But these days, you may not be permitted to open an off-site SMTP connection; the distant host may refuse to talk to you; the distant SMTP may be configured to deny the use of VRFY -- this is recommended practice. There are too many ways that this is commonly broken, for it to be very reliable.) -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
