POP3 mail parser does not use MAIL date

[NC Software]

We had a blockage and didn't receive e-mail for about two weeks thanks to a bug in your code writing to the log parser table, which we turned off, and a stale lock file which I understand is a serious bug in the current stable.

After moving mail around to isolate the large files or bad attachments you all were having a problem with all e-mail that came in from the two week backup all had the same date, the date of import. That is NOT correct. You should not be changing the date, you should be using the date from the e-mail header. I believe you also have or had this problem with the IP address being used as the mail server and not from the message itself.

Please fix all of the above.

P.S. I'm not sure why e-mail importing is so slow. We have a GigE network where mail is retrieved from the internal high speed network yet it is a slow code process for retrieving attachments that you're using.

[craigbrass]

These are bugs. Submit them to Kayako Bug Tracker - Issue List

[John Haugeland]

Originally Posted by NC Software

We had a blockage and didn't receive e-mail for about two weeks thanks to a bug in your code writing to the log parser table

Please explain this bug that you repaired in more detail, so that I can repair it in the main line.

Originally Posted by NC Software

After moving mail around to isolate the large files or bad attachments you all were having a problem with all e-mail that came in from the two week backup all had the same date, the date of import. That is NOT correct.

Quite a few of our users require times to be set according to import, in order to support their SLAs. This is the first time I've heard of anyone wanting the opposite.

I will file this (namely the ability to choose which behavior is best for you) as a feature request.

Originally Posted by NC Software

I believe you also have or had this problem with the IP address being used as the mail server and not from the message itself.

I have never heard of such a defect. Can you provide concrete steps to replicate? This doesn't seem to happen on local desks.

Originally Posted by NC Software

Please fix all of the above.

Once the two possible defects are explained, I may be able to locate and repair them; at this time I don't know enough about them to reproduce. The feature request will go into the tracker, and will be handled in due order.

It would be appreciated if you'd begin to open bug reports in tickets, so that they would be handled in our standard process.

Originally Posted by NC Software

P.S. I'm not sure why e-mail importing is so slow. We have a GigE network where mail is retrieved from the internal high speed network yet it is a slow code process for retrieving attachments that you're using.

There are several possibilities. We might be able to track down the problem if we had shell access to your desk; very few people have problems with the speed of importing attachments.

Please do not provide shell access on the forum, obviously, since it's public; if you'd like us to take a look, the best thing to do would be to open a support ticket.

[dweyer]

I agree with Neal, i.e. the date should be the date of the email header and not the date/time the email was downloaded. The effect this haves for us is that as the fetch email schedule only seems to work while member are logged in, no emails are downloaded over night which means in the morning we receive 300 emails all with virtually the same time which means there is no way to prioritise in received order.

I would suggest that rather than offering this as a choice an additional field should be offered namely email date and download date.

Dill

[craigbrass]

Answered in your other thread. Ticket Date