After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 211096 - address validity checking seems to neither consult ldap nor smtp
address validity checking seems to neither consult ldap nor smtp
Status: RESOLVED DUPLICATE of bug 208826
Product: evolution
Classification: Applications
Component: Mailer
unspecified
Other All
: Normal minor
: ---
Assigned To: Evolution Triage Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2001-09-27 15:43 UTC by gisli
Modified: 2001-10-04 15:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description gisli 2001-09-27 15:43:50 UTC
Description of Problem:

Enhanced address validity checking no longer
accepts simple username.  I must now enter a full
address, username@localdomain.

Steps to reproduce the problem:
1. "New message"
2. To: <specify e-mail address of local user,
   without the local domain.>
3. "Send"

Actual Results:

A Warning message box pops up "This message
contains invalid recipients:"

Expected Results:

If the message were sent, my SMTP server would
know that this user exists in its domain.  At
least, this is how it worked with evolution 0.12.

How often does this happen? 

Always, since upgarding to 0.14

Additional Information:

I have been trying to figure out how Trow's
address validation might be occurring.  It 
seems that there are only three options, 
LDAP, NIS or SMTP.  Since I don't share an nis
domain with the rest of my organization, this
approach would definitely fail.  I have attempted
to tell the Evolution Contacts application about
my companies LDAP, but I have no evidence that
I have done this correctly.  SMTP would definitely
know the usernames in question, so it does not
appear that SMTP is being consulted about address
validity.
Comment 1 Heath Harrelson 2001-10-04 15:54:53 UTC

*** This bug has been marked as a duplicate of 208826 ***