GNOME Bugzilla – Bug 210960
Non-Qualified Email Addresses no longer work
Last modified: 2013-09-10 14:02:43 UTC
Send an email to a local user name without giving a domain name. Actual Results: Dialog box saying the address is invalid. Expected Results: Accepting it if it's a valid mail name within the local email domain of the machine it's being sent on. Note that the submission is through Sendmail - were the mailer to be configured to use SMTP, it MIGHT make sense to enforce a domain name being added. For example, you can't just email "root" or "j.doe" etc. How often does this happen? All the time... Additional Information: This used to work just fine in earlier releases of Evolution. At the least there should be a setup option along the lines of "allow unqualified email addresses". For a dial-up ISP user, forcing the domain is a good idea. For users on a local network, it's extremely annoying to have to fully qualify email addresses all the time. Regards, Bevis.
The problem is that we have no idea (it's all abstracted) which method it will be sent with, therefore it is logical to enforce qualified email addresses. The only reason it worked before was because we didn't do any checking. Now, for the sake of the addressbook code, we need to. I'm not closing this because we may at some point decide to append @domainname to non-qualified email addresses, but this can be tricky since god knows if that's who you really meant to send it to or not. Since we've been flamed for making Evolution "too smart" in the past, I hesitate to even consider implementing this. Marking as Future for now...we can make up our minds later about this I guess.
I think it would be good to have a default domain for each identity (or SMTP server) that is defined. If the default domain is not specified and no domain is set in the recipient's e-mail address, Evolution should complain. If a default domain is specified but no domain is set in the recipient's address, the default domain should be appended. The main problem is for users in large organizations: we often send e-mails to peoples we have never talked to before (=> the username is not in our addressbook) and when we are in disconnected mode or working from our lab (behind a firewall), we can not access the LDAP server.
Setting this to 1.1.
Default domain per account sounds reasonable to me, i've seen it in other mailers.
This is really fairly easy to implement, but would involve breaking feature freeze, UI freeze, and probably a few other freezes to boot. I see no problem with doing this for 1.1.
*** bug 208826 has been marked as a duplicate of this bug. ***
*** bug 214635 has been marked as a duplicate of this bug. ***
Because of the decision to remap 1.1->1.2 and 1.2->1.4, I'm going to be moving a large number of bugs around in the bugzilla. You can just search on 'body contains' 'Because of the decision to remap' and mark all as read. Please direct all questions about this change to evolution@ximian.com, not the bug. Luis
*** bug 209689 has been marked as a duplicate of this bug. ***
this is kinda a feature because it requires adding new functionality.
anyone know why this is marked as 40 hours? that seems excessive for this but maybe the person who marked this for 40h knows something I don't.
fixed in CVS
Uh, it has been a while since I worked on this stuff, so the details are a bit fuzzy in my mind --- but this fix will break some of the autocompletion magic, and I'd encourage you to revert it. When you move out of the address entry window, it scans for invalid entries and tries to resolve them to nicknames. So nickname stuff is probably now broken. This is also the mechanism by which we "re-complete" names. So if I auto-complete an address to (underlined) "Jeff Stedfast", and if I then delete the last character, I'm left with an un-underlined "Jeff Stedfas". If I then leave that entry, it re-completes it back to (underlined) "Jeff Stedfast", and the e-mail will go to the right place. If e_destination_is_valid is made too lax, this will not work. (This is a bad example, since "Jeff Stedfas" probably would get flagged as invalid due to the whitespace... but you get the idea.) I don't remember if the 40 hour estimate was mine, but multiple things like this are based on the premise that an EDestination is valid iff it contains an ECard or is obviously an e-mail address, and then we try to do automagical stuff with the invalid addresses. Allowing local delivery breaks this simpifying assumption, so part of that estimate no doubt involved working around these issues.
ah, suckage.
*** bug 218383 has been marked as a duplicate of this bug. ***
I ran into this problem in the context of sending to a local sendmail alias. My patch was simply to not do the *check* for invalid recipients in composer_get_message(). That way, all the completion tricks still do whatever they do now, but whatever's in the address fields when I hit "send", Evolution will believe, and not try to outguess the transport. [The patch I submitted only skipped the check if you're using sendmail, because I was dealing with sendmail aliases, but arguably it should always be skipped, because delivering to local users for SMTP should also work.]
Hmmm... the idea of not doing the validity check doesn't exactly thrill me. At the very least, we should warn the users if they are trying to send e-mail to something totally absurd. Jeff and I were discussing this on IRC last night, and the current plan is to allow users to specify a default fallback domain which would get attached to things that look like local delivery addresses. So for example I could set my fallback domain to ximian.com, and then if I just typed 'fejj' and didn't have Jeff in my addressbook, that recipient would get converted to 'fejj@ximian.com' when I focused out of the recipient entry. Ian: What kind of stuff are you doing with sendmail aliases? Fancier stuff that wouldn't be covered by this approach?
But if they *do* do something absurd, the transport will give them an error message. You really want Evolution to be responsible for knowing what's absurd? I reverted Jeff's patch, and applied this one. I tried it with both sendmail and smtp transports and it seems to do the right thing whether I give it a full address, a local address, or garbage.
Created attachment 40970 [details] [review] Simple patch that seems to work
> Ian: What kind of stuff are you doing with sendmail aliases? Fancier > stuff that wouldn't be covered by this approach? Well, I'm actually using premail in the place of sendmail, but I don't think that matters for these purposes. I use multiple mailers, not just Evolution, since sometimes I need access via a remote login. So my addressbook is stored in premail (equivalently, sendmail). That way, I can use addressbook nicknames (think sendmail aliases) from whatever mailer I use. It just doesn't seem right to me to automatically append a domain. As far as I know, <foo> and <foo@localhost> and <foo@my.real.fqdn> are *not* always equivalent addresses. If I want to address the recipient that my MTA knows as "foo", I should be able to send to that. As another example, my main SMTP mail machine hosts many email domains. To it, it is almost always the case that <foo> and <foo@cypherpunks.ca> resolve differently.
Sounds reasonable to me I guess. I agree that it would be better for Evolution to not try to out-guess the user with appending domains and to just leave it up to the transport (whether it be sendmail or an SMTP server). If the mailbox fails, then the server will error out and we just pop up an error dialog like we already do. trow: I'll hold off on this until you get to Boston and then maybe we can talk it over with ettore and see what he thinks.
I'm fairly convinced by Ian's argument, however: (1) I think it still would be nice to give the user the option to specify a "fallback" domain. (2) I don't agree that we should drop _all_ of our attempts to validate the recipients and leave it all to the SMTP server, if for no other reason than that SMTP error messages can be pretty cryptic at times, and Evolution is probably in a position to give the user some more constructive feedback. Surely there must be _some_ stuff that we can recognize as obviously broken and warn the user about.
(1) Sure, options are (almost) always good. (2) I agree that the SMTP error messages could *definitely* be improved. As to "obviously broken", I guess there are some characters it makes no sense to have in a local part (like space or comma), and RFC822 defines a handful of other chars that can't be in the local part of an *Internet* routable address, but that doesn't say anything about what sendmail (or whatever MTA you're using that's masquerading as sendmail) might accept or reject. It's better to not reject things that could be valid, I'd say. Do you have some "obviously broken" strings in mind?
yea, I agree. Plus writing a validator will almost certainly just cause more problems than it's worth. I've seen mailboxes containing 8bit chars and that's just NOT supposed to be legal. But if we wrote a validator, then we wouldn't let it through and we'd be back here at square 1. commas aren't a problem, I think the addressbook entry widget handles commas as address separators so that's ok.. spaces... well, no idea about that. iirc: "my name"@host.com could be considered a valid address? anyways, imho - we just pass the crap along to sendmail/smtp as if it were an address and let the transport complain about it being invalid.
this is fixed now
The arguments here a bit a bit fuzzy. SMTP *does* have defined 'valid addresses', its nothing to do with other address formats/etc. Either the address is local, or remote, or its just not a valid address, end of story.
*** bug 220207 has been marked as a duplicate of this bug. ***
Is it too late/too much to get this fix into the 1.0.x branch? If so, close the bug again. (Sales/potential big customer wants this).
not worth spending the time to backport this
*** bug 229402 has been marked as a duplicate of this bug. ***
*** bug 229441 has been marked as a duplicate of this bug. ***
*** bug 231036 has been marked as a duplicate of this bug. ***