• they typed their email address correctly. (we've found that some people don't type anything).
• the email address exists exactly once in the database. Nothing will be sent if the email address:
  • does not exist, or
  • exists more than once under multiple patrons
  (see below to find these messages)
• the user checked their email program, including spam/trash folders, on all their devices or computers they can use for reading emails
• the email settings in company preferences are valid.
• and the email is not stuck in the pending email list due to some error

Otherwise they will receive nothing

If the patron types an email address that is not in the database, they WILL NOT RECEIVE A WARNING that the email address does not exist. This also occurs if the email exists more than once because it is an error condition. The reason: PCI compliance and privacy laws (like GDPR) require that a system does not divulge any identifying information like names, addresses, or validity of email addresses to anybody who might be trying to determine who or what is in a database. The sample message from web site clearly indicates they will only receive and email if what they type exists. This approach prevents 'bad guys' from scamming emails elsewhere and determine if an account exists on a second web site, where they could obtain products (Like reprinting tickets they could sell to others on the secondary market) should they be able to guess a login id. Error messages can be changed to divulge more information (like email address exists, but password is invalid). This is not recommended if you wish to implement TM in PCI manner for information security.

Finding requests for invalid/nonexistent email addresses

If a patron calls and says that they asked for their password to be reset and did not get an email, you can check to see what email address they used by looking at the web listener logs.

This window is opened from Patron Sales->Web Services->Web Listener Log. For criteria, you may want to use something similar to below:

• Date/Time to narrow things down to a range of days - searching for a month or two is not a problem
• Search within the message text for:
  • email does not exist - use Email Cannot to see those people who did not get an email because the email address does not exist.
  • email exists multiple times - use Email is linked to see those patrons whose email is in the database at least twice and need de-duplicated using the find duplicate email addresses

Looking for only Failed Password Requests

You can see that there are some attempts to request passwords that did not exist. To verify, first ask when the patron requested their password; then using this window, confirm that this is the reason that they received nothing from the system. If there is no message in the log for the email address they described using the day they had the problem, then you will need to check to see if the email is in the queue pending to be sent, or if it was sent.

Verifying all or Specific Password Requests

The following search might also be used to find both requested and failed password requests. it could also be tailored to only search for part of the email address such as 'artman.com' to see all requests from that one domain. The:

• request message will always appear
• failed message will only appear if there is a failure.