Hello,

As far as I know POP is only able to fetch mails from the Inbox. It doesn't handle any of the other folders and therefore these folders will be only local to the client.

You must switch your client to use IMAP for the mailbox if you want to sync other folders (Sent Items, Deleted Items, etc)

Kind regards.

The POP + SMTP protocol doesn't support SENT ITEMS sync, regardless what server or client software you are using (it's not a SmarterMail issue, every other mail software out there works the same way).

It only DOWNLOADS (fetch...) new mails present in INBOX. It doesn't care about other folders.
NOTE: "download" is not "sync"... And it only download NEW mails...

If you want to sync up with the mail server you MUST use one of these protocols (note that everyone have a slightly different way of syncing... You MUST study and understand how they work and what you want to achieve...):

Some other software may use a proprietary way to sync clients and servers.
For example, Kerio Connect uses a plug in called KOFF to sync the server with MS Outlook on Windows PC, but it needs to be installed and configured manually on every Windows PC that use MS Outlook...

Thank you for the responses.  

That however still doesn't explain why the Sent Items folder is not recording anything for the machine that is using that account for sending.

My understanding of POP is what both of you have listed out, hence why I'm confused about why the Sent Items is empty.  I was wondering if SmarterMail was doing something "out of the norm" with POP and hence the folder was being downloaded.  Since that is not the case... the empty Sent Items folder remains a mystery as to why.

I try to explain myself better by going down a little more in detail:

SmarterMail server and/or whatever other mail server you are using will never be aware or sync or save sent emails in the SENT ITEMS folder if you use POP3+SMTP protocols.

So you will never be able to see the sent mails in te SENT ITEMS folder on the webmail.

All mail server works this way.

However, the CLIENT software that you are using (Thunderbird, Outlook, EM Client or whatever...) should put sent mail in the LOCAL (of the software client...) SENT ITEMS folder.
So you should be able to see them ONLY in the software client on the PC that you have used to send every specific mail.

If your software on your PC where you have sent one or more mails doesn't have them in the SENT ITEMS folder, well, this is a client issue.
Whatever Email Server you are using has nothing to do with it.

Also, if you use another software (on the same PC or on another PC) or the same software on another PC with the same mail account in POP3 + SMTP, you will never be able to see the mail sent by the first software/PC on the second software/PC and vice versa.


This is the way POP3+SMTP protocol works.

I've got to be mis-explaining this... let's try again...

Machine 1:   NO INBOUND CLIENT OF ANY SORT ... not POP3, not IMAP, NOTHING, it is strictly sending email using the account on our SM server via SMTP.   So it isn't POP3+SMTP.  It is just SMTP.  It IS authenticating with the account in order to send.

Machine 2: This one is POP3+SMTP (but they don't use the SMTP portion).

Both machines are accessing the same account on my SM server.

If I connect to my SM machine via HTTP and login to the account in question, and then examine the Sent Items folder of that account, it is empty.  And yet I know for a fact that Machine 1 is sending out hundreds of emails daily using it.

So let's ignore the fact that machine 2 even exists.

Why are the emails sent by machine 1 not appearing in the Sent Items folder if I login to the HTTP interface for that account on my SM server ?

Follow up to this...

I just wrote my own little program to emulate what this customer is doing.

Connected to my own account on our SM server, and simply sent out a message.

It did NOT log that transmission in the sent items folder for my account either, but the message sent DOES appear in the logs of the server and it delivered just fine to its destination.

And tested the same program against our internal Exchange server.

It does the same thing.

So it appears when a program logs-in to the server that is NOT considered a "client" by the server.

All it is doing is authenticating the user and then allowing that user to (if they so desire) send outbound messages but does NOT associate those outbound messages with the account that has logged in.

This is a paradigm shift for me.

I've been doing this for 30 years, and never ever knew that.

Ah... a personal shot... perfect

Admins, lock it up.   Apparently I am the only one that didn't know this.

It is the mail client job to store a copy of the sent mail in the sent items folders, using IMAP or any other protocol that can handle it (Not POP). SMTP itself only relay the mail to the server for delivery.

Sorry Rod, I didn't mean to be a personal shot!

 Please, take it easy, I'm sorry if I offended you!

I was simply trying to explain something you apparently did not know.
Maybe I exaggerated in pointing out that you haven't documented yourself enough.

Excuse me if I exaggerated and was insulting.

Why dont you try using  "Plus Addressing"? All you have to do is Enable "plus Addressing" on the server. Then CC or Bcc the mailbox "sender email+SENT@yourdomain" This should solve your issue.

Thanks for the idea Matthew... unfortunately we have found that we cannot use the Plus addressing behind our anti-spam / gateway device.  I don't remember all the details for why off the top of my head, but I know it wouldn't work for us.

Rod, about the plus adressing, isn't your antispam gateway only used for incoming mails ?
When you send outgoing mails, aren't you using the smarternail server as SMTP Server (on Submission port 587)?
 In that case the plus adressing shouldn't be a problem if it is used to store a copy of the mail in a folder of sending user using for example sendinguser+sent@yourdomain.com as recipient of the mail ?

You might want to give it a try...

Both directions

So you mean you are using the SMTP Server of the spam filtering gateway in the smtp configuration of your mail client ? I don't understand the original question then.
If the SMTP Server used is not the smarternail server.

If you use smarternail as the SMTP Server for mail clients there should be no issue to use plus adressing as long as the target mailbox is a local domain as it won't use any gateway.

Clients still point directly at our SM server for SMTP.

However, the SM server outbound gateway is pointed at our hardware Gateway so that all outbound mail is double-scanned for Viruses (first by ClamAV on SM and then using the gateway's scanner).  

The only time we let SM send out "directly" (aka Bypassing the gateway) is if the gateway itself is having issues.  (Think that has happened a total of 3 times in the last 5 years).

Yes, then you should be able to use plus adressing when sending a mail from the client to a local mailbox, it will not use any gateway for local deliveries.

From: user@localdomain.tld 

To: user+sent@localdomain.tld

using your SM smtp server will not use the gateway... as it's not outbound but local delivery

Hmm... doesn't appear to be working.

I got the Gateway configured to allow the +* to pass on the mailbox I'm testing with (by declaring it as an alias...   mymailbox+*).

The message now arrives at the SmarterMail inbox, but does not do the folder creation and then storage into that folder that the documentation about plus addressing says it will do.   Yes, I confirmed that the mailbox has the plus address setting set to 'Move to folder'.

Also tried pre-creating the + folder and it still just arrives in the inbox and is not placed into the + folder specified.

I also tried this just internally without sending thru the gateway by setting up an event that adds a recipient to mymailbox@domain.dom for every thing it sends.  It adds the recipient mymailbox+test@domain.dom and that too is not doing any sort of folder create/store.  It in fact, that doesn't even land in the inbox.  So... something is amiss with + addressing (at least on my server).

I don't see anywhere this needs to be configured higher than the mailbox level (not at Domain, nor at server overall).

Hello Rob,

Strange. To check if it was maybe broken in latest builds I've did this test:

- Configured plus adressing for my mailbox.

- Sent a mail to my mailbox with "+testing" (it should create  testing folder and route the mail there)

- The folder was created and the mail was stored in it

Which build are you using ?

I don't see a global option to turn off/on the feature. It seems to be only at user level.

Kind regards.

We are on 7817.

My setup is identical.

Testing from the same account to itself with + addressing:  WORKS

Testing from account impersonation sending to self + addressing:  WORKS

Testing from another account on the same domain within the SM server to mailbox + addressing:  WORKS

Testing from different domain within the SM server to mailbox + addressing:  WORKS

Testing from OUTSIDE the Gateway device to mailbox + addressing:  Ends up in INBOX instead, does not create folder.

Testing as an added recipient via MAILBOX  EVENT for all outbound traffic from mailbox:  Does not arrive anywhere with regards to the added recipient... did arrive at main destination

Testing as an added recipient via DOMAIN EVENT for all outbound traffic from mailbox:  Does not arrive anywhere with regards to the added recipient... did arrive at main destination 

So, it looks like it doesn't like it being manipulated by the gateway box. and the plus addressing "Add a recipient" from the Events operations at a Mailbox nor Domain level will properly even deliver to a plus address even though they will allow you to set one up to try and do so.

Good info.  :)

Still need to run the test using my little SMTP program to see if it works from there. I would expect it will.  Stay tuned.

Confirmed... using the + addressing via the SMTP program works.  Thanks for the idea !!

Cool that you were able to find a workaround to store a copy of the sent mail only using SMTP. Congrats to Matthew for the original idea :)