Only admin can send email to Alfresco

[heike]

I set up a test user 'test' with email myaccount@mymaildomain.com. 'test' is in the EMAIL_CONTRIBUTORS group and also has writing access to the folder the mail is sent to.

Anyway, when I send an email from the above account, mail delivery fails: "554 The user 'anonymous' is not in the email contributor group". Somehow Alfresco doesn't recognize the email address as one of a known user. When I assign the same address  myaccount@mymaildomain.com to user admin, everything works fine.

alfresco-global.properties looks like this:

### INBOUND SMTP ###
email.inbound.unknownUser=anonymous
email.inbound.enabled=true
email.server.enabled=true
email.server.port=25
email.server.domain=myalfrescodomain.com

Any ideas? It seems to work for everybody else...

[mitpatoliya]

You have configured alfresco as inbound email server. Are you trying to send email from Alfresco? Yes then you need to configure it for outbound emails.

OutboundSMTP configuration properties | Alfresco Documentation 

[afaust]

I believe he is really trying to setup Alfresco as an inbound SMTP server.

So far I cannot see what you did wrong or missed. You are right that the user should have been identified by the email adress instead of using the anonymous sender. As long as you have not changed the mail.server.allowed.senders or mail.server.blocked.senders from the default values I cannot see a cause for this.

You may want to set the logger for org.alfresco.email.server.EmailServiceImpl to DEBUG to log any messages about issues resolving the user from the address.

[heike]

Axel Faust‌, you are right, I am trying to set up Alfresco as an inbound SMTP server. I use the default values for mail.server.allowed.senders and mail.server.blocked.senders. I set the logger for org.alfresco.email.server.EmailServiceImpl to debug as you suggested, this is the result:

2016-12-15 10:11:21,201 DEBUG [...] getUsername from: myaccount@mymaildomain.com
2016-12-15 10:11:21,286 DEBUG [...] unable to find user for from: myaccount@mymaildomain.com,trying message.from next
2016-12-15 10:11:21,286 DEBUG [...] getUsername from: myaccount@mymaildomain.com
2016-12-15 10:11:21,313 DEBUG [...] userName = : null
2016-12-15 10:11:21,314 DEBUG [...] unable to find user for from - return anonymous:

I looked at the source code for EmailServiceImpl, there the method getUsername is used to identify the user from the email address via the query: TYPE:cm\erson +@cm\:email:myaccount@mymaildomain.com

When I try this query in the node browser, I find user test. Somehow, getUsername doesn't find it.

[heike]

Funnily enough, if I try the query: TYPE:cm\erson + @cm\:email:adminaccount@whatever.com

where adminaccount@whatever.com is admin's email, the node browser doesn't find the node. Although it does find the node with the query: TYPE:cm\erson + @cm\:email:adminaccount*

When user test and user admin both have the same email address myaccount@mymaildomain.com, the query

TYPE:cm\erson + @cm\:email:myaccount@mymaildomain.com finds only test, not admin, although

TYPE:cm\erson + @cm\:email:myaccount* finds both.

[afaust]

That sounds very much like index + localization issues. When a node is created it is inherently assigned a "locale" based on the locale of the current user. This locale may be used during SOLR indexing to determine how property values are indexed, e.g. how tokens are built etc. During searching, the query will use the current user's locale to handle tokens, which may be different from the locale the node was indexed with (due to its locale assignment). This can have an impact on text similarity queries like your test cases with / without the use of wildcards.

Since you want to look for an exact match it is always recommended to use

TYPE:"cmerson" AND =cm:email:"myaccount@mymaildomain.com"

- quotation marks simplify text search by avoiding encoding for most characters (except quotation marks themselves)

- =myrop:value is the expression to look for exact matches - just myrop:value or @myrop:value are always locale-sensitive term / phrase queries

- the @ in @myrop:value is absolutely superflous in FTS query syntax - it is a remainder from the underlying Lucene query syntax and mostly relevant for backwards compatibility for Lucene queries before Alfresco introduced FTS (somewhere in Alfresco 2.x or 3.0 years ago). Unfortunately a lot of documentation / internet examples still include this

[heike]

I found the source code here: EmailServiceImpl.java, there I found the query used in the getUsername method (though with quotation marks, I admit). I just used the node browser to see what the query results are, but I obviously can't change the query in EmailServiceImpl. With the queries you suggest the node browser finds everything as expected...

[afaust · Accepted solution]

It may be that the service is running in a different default locale then the user was created in. Since the admin user was created with the system locale that would explain why it works with that user.

It would be great if you could create a ticket in the Alfresco JIRA system since this is likely a bug in core Alfresco and the query should really be updated (if only to support transactional queries in stead of index queries).

In your case you might be able to fix the problem by correcting the locale of the user. If you view the cmerson object for the user in the node browser you should see a sys:locale property. Simply set that to the same value as the admin user (e.g. via JavaScript Console).

[heike]

Yes, changing test user's locale did the trick. Thank you so much for your help!

(By the way: I installed Alfresco using a locale different from "en_US", never changed anything, so Alfresco is running in that locale ever since. Anyway, admin is the only user whose sys:locale property corresponds, all other users (like existing sample users abeecher etc. or new users created via Share) have locale "en_US" - although my browser's locale is the same as Alfresco's. So I'll have to find a way to make sure that all users supposed to be able to send emails to Alfresco have the same locale the server is running in.)

[douglascrp]

I had the same problem as   and your tip also did the trick for me.

Thank you.