391760 - reply to local domain users does not auto complete domain name

Status: UNCONFIRMED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Anurag Tomar]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 Mnenhy/0.7.5.666
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2 Mnenhy/0.7.5.666

When replying to an email sent from local domain, only the userids are
shown in compose window addresses
To: <joel>
Cc: <anurag>

When you try to send this reply, a popup shows up saying:
"<joel> is not a valid e-mail address because it is not of the form user@host.  You must correct it before sending the e-mail."

This is a pain when the Cc-list is long, as you need to click on each recipient and add domain name - make it <[e-mail]>

As I have searched through buglist, and no one is complaining of this basic issue, I am wondering whether there is some setting that I am missing.  But
search in user group also does not reveal anything.

This is stopping me from switching from netscape 7.2 to
seamonkey - as I would like to have an integerated environment.
BTW, I have heard the same from others in my company who tried to
use seamonkey - and gave up because of this.

Thanks.

Reproducible: Always

Steps to Reproduce:
1. send email to yourself
2. try to reply back to the same.
3.


Expected Results:  
There should be an option to 'complete' the addresses using the local
domain name, or it should default to the above, as this is a received
email - which implies that as no domain name is there in address, it must 
have come from local domain.


This issue is different then when you are composing new email.  At that time, the
software does auto-complete using the address book.  This problem is only in replying to an existing email.  And happens on both linux and PC (winXP).

Comment 1

[WADA:World Anti-bad-Duping Agency]

What is set in mail.identity.default.autocompleteToMyDomain?
(default=false. Check via Tools/Options/Advanced/General/Config Editor)
Will toggling it to true be a workaround?
(Note: Even if this'll be a workaround, Bug 383739 can not be bypassed.)

Comment 2

[Anurag Tomar]

In seamonkey, I do not see 'Options' menu under Tools.

Also, auto-complete to my-domain (I don't remember how I got
to it) seems to work when composing new emails - type in a
userid, and it auto-completes with the local domain.  But,
this does not work when I reply to a received message.
Thanks

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> In seamonkey, I do not see 'Options' menu under Tools.
Sorry. about:config when Seamonkey(and Firefox)

> But, this does not work when I reply to a received message.
Auto-complete sounds to work when typed only, not when pre-filled.
When reply, "touch To: field"(e.g. add a space then remove) will invoke auto-complete?

Comment 4

[Anurag Tomar]

auto-complete works as you described, once I changed
the about:config entry.

However, I guess I had filed this enhancement request to get the 
functionality available in netscape 7.2 and old mozilla 
integrated mail+browser tool.  
In those 2 mailers, it is assumed that if I am relying to an email, 
and an address does not have @domain.com, then it must be myDomain, 
else I would not have received this email.  I am not sure what 
exactly happens - that is, whether they auto-fill myDomain.com, 
or do they allow sending without a '@domain.com' added to the 
userids. I suspect, the later.

Anyway, even with auto-complete working as you described, it is 
a pain to invoke it one by one for every one on the ccList - and 
this can run from 0 to 100 or more people.  On average 5-10 people
are on the list.

So is there a config setting to 'suspend' the '@domain' presence check
when replying.  Have that check only for new composed emails.

Thanks for looking at this, and answering my basic questions.

Comment 5

[WADA:World Anti-bad-Duping Agency]

"Rejection of sending to mail address without domain part" was done as enhancement for anti-spam or anti-phishing. And auto-complete of my-own domain was introduced.
But at leaset two problem seems to exist in this area.
 (A) Bug 383729 : Forget to support <postmaster> defined by RFC
 (B) Your case  : Lack of care on companies who use local-part only mail address
                  for internal use
Your case may be improved by enhancement by Bug 95631, but I'm not sure.
> Bug 95631 [RFE] Autocomplete could supply domain options after "@" in an unknown e-mail address   

Comment 6

[Tony Mechelynck [:tonymec]]

No significant activity in 8 months. I think this bug still applies but I can't test it - I'm not on an intranet.

Comment 7

[Anurag Tomar]

I am using 1.1.8, and the bug still exists.
Yes, you need a mail-server which will strip the domain
name if it finds the recipient's address is in local domain.
Then replying to that email will show you the problem.

Thanks,
- Anurag

Comment 8

[Anurag Tomar]

On to 1.1.9, and still no joy.  
Any suggestions as to what I can do to get some one interested 
in adding a config option for this feature.  

I do not want to move to outlook, but with netscape not being s
upported, I will get forced to if this issue is not fixed :-(

Thanks,
- Anurag

Comment 9

[David :Bienvenu]

mail.identity.default.autocompleteToMyDomain should work, at least on trunk builds.

Comment 10

[Mark Banner (:standard8)]

What I see happening here is the local intranet obviously contravenes RFC 2822 for sending messages. So whilst mail.identity.default.autocompleteToMyDomain would help with autocompletion, the problem is really in responding to messages - messages which have an email which is "foo" rather than "foo@intranet".

David, could a solution be to write an extension that would add the "@intranet" part onto the addresses when responding/forwarding? Have we got appropriate hooks for that? Although this would make email address matching harder, it would be a possibility.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Bbug number in comment #5 was wrong. Sorry for spam.
   (A) Bug 383739 : Forget to support <postmaster> defined by RFC