Scalix Forums

I have the following problem with Scalix 11.
For testing spam/virus scanning I send some prepared mails via
"sendmail -i user@domain.de < message.txt.

However some of these messages are no longer delivered to the user.
Trying the same with a different user works correct.
Sendmail log show that sendmail successfully delivers the mail.
After "omconfaud ld 9" the audit log shows the following strange entry
for that mail:

[snip]
duplicate_message_count 1
delivered_count 0

Any idea what is wrong and how to fix it?
Thanks a lot

Regards,
grubi

Theres nothing wrong. It works as designed.
You are trying to send the same message with the same msg-id to one user.
The local delivery will check for duplicate messages, thats why you see that log entry.

When you send a message to several groups (distribution-lists) and mailboxes it may happen that one mailbox is adressed more than once. Without the duplicate message check the message would be delivered more than once.
I think thats a very useful feature.

For your tests you might think of altering the message-id in your source message.

Best Regards, Dirk

ls-al wrote:Theres nothing wrong. It works as designed.
You are trying to send the same message with the same msg-id to one user.
The local delivery will check for duplicate messages, thats why you see that log entry.

When you send a message to several groups (distribution-lists) and mailboxes it may happen that one mailbox is adressed more than once. Without the duplicate message check the message would be delivered more than once.
I think thats a very useful feature.

For your tests you might think of altering the message-id in your source message.

Best Regards, Dirk

Hi Dirk.
Thanks for your answer.

I agree that this is a useful feature. However what makes me wondering is that this happens even if the message was deleted from the user's mailbox. Where does scalix store this information. I can't imagine that scalix records all msgids for every mailbox it has ever been received. Or does this info timeout on time. I would be interrested to get some insight how this works.

Anybody here who wants to share his knowledge?
Thanks

Regards
grubi.

Anybody here who wants to share his knowledge?

I'll try.
By default the last 256 msg-ids are stored in the 000002q file which is located in the users g-directory (have a look at omshowu -n .. -f).

It looks like the number of stored msg-ids is configurable through a general.cfg-tweak, but we should be aware that increasing this has side-effects on the performance of the delivery.

Maybe this is the reason why the tweak is not officially documented. I dont want to publish unofficial informations in a public forum, as I know that all undocumented features can be changed without notice.

Hope that helps.
Dirk

ls-al wrote:I'll try.
By default the last 256 msg-ids are stored in the 000002q file which is located in the users g-directory (have a look at omshowu -n .. -f).

Exactly what I was looking for.
Thanks a lot.

Regards.
grubi

Thank you. This information helped to successfully resend a message from the message log on our Barracuda Spam Firewall.