724342 - thunderbird doesn't allow local user names as email recipients (addresses without '@' on local server)

Status: RESOLVED WONTFIX

(Thunderbird :: Message Compose Window, defect)

Description

[Dirk Heinrichs]

Attachment: Screenshot of thunderbird error message.

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Ubuntu/11.10 Chromium/16.0.912.77 Chrome/16.0.912.77 Safari/535.7

Steps to reproduce:

Tried to send an email to a local user by using the username.


Actual results:

Attached window popped up, telling me the email address was invalid.


Expected results:

It should have sent the mail, just like Claws does.

Comment 1

[rsx11m]

As it appears, only "postmaster" is permitted to be specified in this way.

The check and message are on purpose, but obviously causing issues if used with a server that's strictly in a local context. I could imagine a "Send Anyway" button but that would pop up with every message sent and may not be optimal either.

I don't see any way to switch off that message, maybe CheckValidEmailAddress() could be overlayed in an add-on to always return true, thus bypassing the check.

Comment 2

[Dirk Heinrichs]

(In reply to rsx11m from comment #1)

> I don't see any way to switch off that message, maybe
> CheckValidEmailAddress() could be overlayed in an add-on to always return
> true, thus bypassing the check.

But, isn't it a task of the MTA and not of the MUA to decide what is a valid email address and what is not?

Comment 3

[rsx11m]

David, any opinion where and how this is supposed to be done the right way?

I'd agree with Dirk that the SMTP server should reject such an address if it doesn't resolve to anything or forward it to the intended mailbox if known where it's supposed to go. Thus, the check appears redundant to that extent.

But then, looking at RFC 5321 Section 4.1.2, it defines a mailbox specification as Mailbox = Local-part "@" ( Domain / address-literal ) thus always with a '@' except for the case in 4.1.1.3 using "postmaster" without any domain given.

Comment 4

[David :Bienvenu]

We have a hidden pref that autocompletes to your current domain - the default is mail.identity.default.autocompleteToMyDomain, and you can override the default on a per-identity basis, using the config editor. This allows you to type just the username, and we will automatically fill in your domain. We added this pref a long time ago, because a mailbox really MUST contain a domain.

Comment 5

[WADA:World Anti-bad-Duping Agency]

Same issue as bug 391760?
Or your local/internal SMTP server requests mail address without domain part?
(i.e. autocompleteToMyDomain can't be used)

Comment 6

[David :Bienvenu]

(In reply to WADA from comment #5)
> Same issue as bug 391760?
> Or your local/internal SMTP server requests mail address without domain part?
> (i.e. autocompleteToMyDomain can't be used)

that would seem like a fairly broken server - does that situation happen in the real world?

Comment 7

[:aceman]

What about user@localhost ?

Comment 8

[WADA:World Anti-bad-Duping Agency]

(In reply to David :Bienvenu from comment #6)
> (In reply to WADA from comment #5)
> > Same issue as bug 391760?
> > Or your local/internal SMTP server requests mail address without domain part?
> > (i.e. autocompleteToMyDomain can't be used)
> that would seem like a fairly broken server - does that situation happen in
> the real world?

It doesn't mean "broken". It's never SMTP RFC violation. It's never POP3/IMAP RFC violation. It violates RFC 5322 only. Because Intranet, any company is free from "Internet Message Format" -:)
It means "a company requests his employees not to put domain part if internal mail". It's local rule to avoid that internal mail is sent to external. This kind of company actually exists, although few.
And, in this case, autocompleteToMyDomain is not always usable, if the company has multiple mail domains for his employees.

It's to avoid next (d), and autocompleteToMyDomain is not usable in (e). 
 local  part == company wide unieque name
 domain part == depends on devision, sub company, ...
 Call user1@D1.P.Q, user2@D2.P.Q.
             Front end SMTP     
(a) user1 -> RCPT: user2@       -> SMTP for internal -> POP3/IMAP for internal.
                                                        As server for internal,
                                                        knows about domain part. 
(b) user1 -> RCPT: user2@x.y.z  -> SMTP for external -> external POP3/IMAP
(c) user1 -> RCPT: user2@D2.P.Q -> SMTP for internal -> POP3/IMAP for internal
(d) user's typo
    user1 -> RCPT: [e-mail].Q   If Px exists and is owned by other company,
                                   mail is sent to external.
(e) autocompleteToMyDomain
    user1 -> RCPT: user2@A1.P.Q    Non-existent mail address is generated by Tb.
And, even if autocompleteToMyDomain is usable, it works only when typed. As seen in bug 391760, it doesn't automatically work when reply to mail of "From: userX" message header.

"From:/To:/CC: userX", "From:/To:/CC: userX@" is apparent RFC 5322 violation.
> http://tools.ietf.org/html/rfc5322#section-3.4.1
> addr-spec       =   local-part "@" domain
"Valid non-group mail address in message header without @ and domain part" is "postmaster" only.

To support such local rule, per SMTP setting is needed.
(1) Per SMTP server setting for intentional RFC 5322 violation.
    - Always requests @domainpart except postmaster as current(no RFC violation.)
    - autocompleteToMyDomain = true/false for user's convenience.
    - permit message header without @domainpart and without domainpart.
      (RFC 5322 violation. FROM: user1@, RCPT: user2@ is requested in SMTP send)
    In any case, there is no RFC 5321 violation.
(2) Enhancement of autocompleteToMyDomain = true
    Execute autocompleteToMyDomain automatically in Reply.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to Dirk Heinrichs from comment #2)
> But, isn't it a task of the MTA and not of the MUA to decide what is a valid
> email address and what is not?

"Valid" of CheckValidEmailAddress() means "validity check of mail address syntax based on RFC 5322". If "To: userX" passes the validity check, Tb's SMTP code requests "RCPT: userX@" to SMTP srver as expected based on RFC 5321. After it, all is up to SMTP server.

Comment 10

[Magnus Melin [:mkmelin]]

(In reply to WADA from comment #8)
> It doesn't mean "broken". It's never SMTP RFC violation. It's never
> POP3/IMAP RFC violation. It violates RFC 5322 only. Because Intranet, any
> company is free from "Internet Message Format" -:)
> It means "a company requests his employees not to put domain part if
> internal mail". It's local rule to avoid that internal mail is sent to
> external. This kind of company actually exists, although few.

This is not a behavior we should support.

Comment 11

[WADA:World Anti-bad-Duping Agency]

(In reply to Magnus Melin from comment #10)
> This is not a behavior we should support.

INVALID? (because Tb should always be RFC 5322 compliant)
WONTFIX? (intentional violation of RFC 5322 is not acceptable)

Comment 12

[Magnus Melin [:mkmelin]]

->WONTFIX