Changes between Version 24 and Version 25 of TracDev/Proposals/EmailValidation

Timestamp:

Dec 15, 2010, 12:30:25 AM (13 years ago)

Author:

Carsten Klein <carsten.klein@…>

Comment:

—

TracDev/Proposals/EmailValidation

@@ -5 +5 @@
 == The Context ==
 
-User enters a new or changes an existing email address in the general preferences tab or a different tab from a different contributor.
-Under all circumstances, a verification email must be sent to the user containing a link that will validate the email address to the system, so that the 
-change will come into effect and the email address will be considered safe for sending notification emails to.
+User enters a new or changes an existing email address in the general preferences tab.
+Under all circumstances, a verification email for confirming the address must be sent to the user, containing a link that will validate the email address with the system. Only when confirmed, the change of the e-mail address must come into effect, otherwise, the change will be rendered invalid and the e-mail address entered will be discarded/ignored.
 
 However, the general preferences tab may not be the only place where user's might enter an email address. Similar input fields exist in the ticket system where
 one can add email addresses for ticket change notification. Other such possibilities for input of an email address might exist, given the wide range of available
 plugins making use of the notification subsystem.
+
+Additionally, in TracIni there exist some configuration entries which might contain email addresses. Should these be validated too by the system or should these be taken for already having been validated by the administrator who defined the configuration?
 
 == Requirements ==
@@ -55 +56 @@
  - hashes made up from the e-mail address and a timestamp are being used for validation purposes and communicating the validation links to the user.
  - for renewal of validation requests, email addresses will be url encoded.
- - feel free to move it back up to requirements once we have finalized this issue, thanks.
+ - as for email addresses entered not matching the given production rules set forth in RFC822, these should definitely be rejected until successors of that RFC, namely those which support UTF-8 encoding of smtp headers, have become widely accepted, see #9085 for more information
+ - '''feel free to move it back up to requirements once we have settled on this issue, thanks.'''
 
 ==== Proposed Solution ====