james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Bester (JIRA)" <server-...@james.apache.org>
Subject [jira] [Updated] (JAMES-2519) Duplicate entries in sent items
Date Fri, 03 Aug 2018 09:59:00 GMT

     [ https://issues.apache.org/jira/browse/JAMES-2519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

John Bester updated JAMES-2519:
-------------------------------
    Description: 
To get around issues where remote delivery does not work (relay denied), I have configured
email clients to use the SMTP server directly and move sent items to James SENT folder. While
this works, it does have a strange side effect. If you send an item to an external recipient
and CC to a recipient in the domain handled by James, then multiple copies of the sent item
ends up in SENT folder. While this might look like a email client problem, I would have expected
this to have happened before switching to James. So, my guess is the following happens:

1. You send a message to external recipient and CC to internal recipient (email client uses
external SMTP server)
 2. Email client copies mail to SENT folder 
 3. Fetchmail retrieves a copy from external POP3 server
 4. Fetchmail interprets "FROM" address and stores it in SENT folder of sender

Possible solution (if my interpretation is correct):
When fetchmail interprets the FROM address, it first checks whether a duplicate already exists
before adding it to the SENT folder. The fields to use for checking whether or not it is in
fact a duplicate might or might not be trivial.

  was:
To get around issues where remote delivery does not work (relay denied), I have configured
email clients to use the SMTP server directly and move sent items to James SENT folder. While
this works, it does have a strange side effect. If you send an item to an external recipient
and CC to a recipient in the domain handled by James, then multiple copies of the sent item
ends up in SENT folder. While this might look like a email client problem, I would have expected
this to have happened before switching to James. So, my guess is the following happens:

1. You send a message to external recipient and CC to internal recipient (email client uses
external SMTP server)
 2. Email client copies mail to SENT folder 
 3. Fetchmail retrieves a copy from external POP3 server
 4. Fetchmail interprets "FROM" address and stores it in SENT folder of sender


> Duplicate entries in sent items
> -------------------------------
>
>                 Key: JAMES-2519
>                 URL: https://issues.apache.org/jira/browse/JAMES-2519
>             Project: James Server
>          Issue Type: Bug
>          Components: Remote Delivery
>    Affects Versions: 3.0.1
>         Environment: Ubuntu 18.04 Server (James)
> Postgresql 10 (message store)
> Ubuntu 16.04 (Desktops) with Evolution (Email client)
>            Reporter: John Bester
>            Priority: Major
>
> To get around issues where remote delivery does not work (relay denied), I have configured
email clients to use the SMTP server directly and move sent items to James SENT folder. While
this works, it does have a strange side effect. If you send an item to an external recipient
and CC to a recipient in the domain handled by James, then multiple copies of the sent item
ends up in SENT folder. While this might look like a email client problem, I would have expected
this to have happened before switching to James. So, my guess is the following happens:
> 1. You send a message to external recipient and CC to internal recipient (email client
uses external SMTP server)
>  2. Email client copies mail to SENT folder 
>  3. Fetchmail retrieves a copy from external POP3 server
>  4. Fetchmail interprets "FROM" address and stores it in SENT folder of sender
> Possible solution (if my interpretation is correct):
> When fetchmail interprets the FROM address, it first checks whether a duplicate already
exists before adding it to the SENT folder. The fields to use for checking whether or not
it is in fact a duplicate might or might not be trivial.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message