You will normally not need to change any settings on this page unless VPOP3 technical support have suggested it.
If you do make changes, and want to go back to the original settings, the Restore Defaults button will restore the settings to their defaults.
If you have any VPOP3 plugins installed, then VPOP3 will usually access them as necessary, possibly with multiple processing threads at once. Correctly written plugins should be able to cope with this, however, in case you are using a plugin which crashes if it is multithreaded, you can check this box, to make VPOP3 only call the plugin once at a time.
In email, a 'hop' is when a message is passed from one mail server to another.
When a message is received, most mail servers will count the 'hops' which a message has already made (done by counting the number of 'Received:' header lines). If this number of hops exceeds a specified value, the message will be rejected. This is because it suggests that the message may have got stuck in a loop somewhere - eg if a mail server is misconfigured, a message may be sent back and forth between two mail servers. Without the 'max hops' check, the message would go back and forth forever.
The Max Hops value tells VPOP3 what the maximum number of hops to be allowed is when checking a new message. If the number of hops ('Received:' header lines) exceeds this number, then VPOP3 will reject the message with a 'Too many hops' error message.
Values of 20 or higher are usually sufficient, but in a few cases, eg if all your mail passes through many mail servers (spam filtering services, archiving services etc) on the way to you, you may wish to increase this number. Do not increase it too high, or you will unnecessarily waste resources if something is misconfigured. Sensible values are between about 20 and 100.
When VPOP3 downloads messages from a remote POP3 server, one of the things it does is to retrieve a list of message sizes from the remote server (using the POP3 LIST command). This is so that maximum size checks will work, and so that progress bars can be scaled appropriately.
If you check the Use Fastest POP3 Download method option, then VPOP3 simply skips this step, and assumes that each message is an arbitrary size. Nowadays, the time saved by skipping this step is negligible - eg if there are 1000 messages on the ISP, this step should take much less than 1 second, but in the days of slow modems, or if the ISP's POP3 server was not very fast, this option could be useful.
In computer terms, a 'daemon' is an automated process. VPOP3's 'Mailer Daemon' is the entity which will send you emails from VPOP3 - such as error messages or other notification messages.
Usually these messages will come from mailer_daemon@<your domain>.
Some people have wanted to change this name for various reasons, so the option to change it is here. Be aware that if you change the name, it may make technical support harder, unless you notify the support technicians of the change, as they won't be expecting the new name you have used.
Also, VPOP3 can process some control messages if you send messages with a particular format to the 'mailer daemon' address.
Because the VPOP3 'mailer daemon' (see above) will send users emails, it's not unknown for some users to reply to these messages for some reason. Also, people can misformat control messages to the mailer daemon.
VPOP3 will reply to the sender telling them it did not understand the message in these cases. If you check the Report bad mailer_daemon messages option, then the VPOP3 main administrator will be informed of the message, in case they want to train the user how to use it correctly.
By default, if a local user sends a message to <a local username>@<a local domain>, VPOP3 will put the message directly into the target user's local mailbox. This is usually the expected behaviour.
If you check this option, then all messages which VPOP3 receives by SMTP will be sent out to the Internet, regardless of whether they are for a local user or not. Depending on your configuration, VPOP3 may then download the messages from a remote POP3 mailbox and distribute them to the local users.
Use of this option is strongly discouraged, as it can cause strange effects and is not a standard test use-case. Things such as BCCs, mailing lists, fax, SMS, monitoring, archiving, spamfiltering, etc are all affected if you use this option.
When VPOP3 downloads messages from a remote POP3 mailbox, it keeps track of which messages it has downloaded by remembering the UIDs (Unique ID) of the messages it has downloaded. If VPOP3 sees a UID which it has not seen before, then that message will be downloaded, and if it sees a UID which it has seen before, the message will be ignored.
Because VPOP3 has to handle situations where other software may be deleting messages from the same POP3 mailbox which VPOP3 uses, it has to handle cases where UIDs disappear when VPOP3 has not deleted messages. Also, it is possible for the ISP to undelete messages which VPOP3 has asked to be deleted.
The Hold Obsolete UIDLs option tells VPOP3 how long to remember UIDs after they seem to have disappeared.
So, if VPOP3 deletes a message on 2 April, it will remember that message's UID until 5 April. If a message appears in the POP3 mailbox with that UID before 5 April, VPOP3 will assume that the message has been undeleted somehow, so it will not download it again.
Some ISP POP3 servers have been known to 'lose' messages for a period, and then have them reappear, so this facility in VPOP3 stops those messages from being downloaded a second time.
Most POP3 servers will never re-use message UIDs, as this is easy to achieve, and is the safest option. In this case, the default Hold Obsolete UIDLs setting of 3 days is safe.
However, a few ISPs will re-use message UIDs, sometimes quite quickly. For instance, it isn't unknown for a POP3 server to give the first message which arrives in a mailbox the UID of 1. Then, if you delete that message, the next message which arrives will be given the UID of 1 again. In this case, you should set the Hold Obsolete UIDLs to 0 days to try to reduce problems with messages not being downloaded. Note that it is impossible to be perfectly safe in this situation, because if VPOP3 downloads message with UID 1, then some other software deletes that message (so VPOP3 doesn't know it has been deleted) and a new message arrives, the next time VPOP3 connects, it will see the message with UID 1, and assume it is the one it has seen before, so it will not be downloaded again. This is why most POP3 servers do not re-use message UIDs.
If the VPOP3 Download Rules or Maximum Message Size To Download settings tell VPOP3 to ask the user whether or not to download a message, the Query Download Delay tells VPOP3 how long to leave the message on the ISP's POP3 server before deleting it. This gives the user chance to respond to request the message before it is deleted.
For instance, the POP3 mail collector may be configured to delete messages after 1 day, which may not be time for the user to respond if the message in question arrives at a weekend, so VPOP3 will leave those messages in the ISP mailbox for longer (default 14 days).
When a message is sent using SMTP, the sending email client will specify the sender's address in the SMTP envelope, and also, specify the sender in the From: line in the message header.
If this option is checked, then VPOP3 will take the email address from the From: header line, and use it as the sender's address in the SMTP envelope. This should not be needed, and may break some things, so usually this option is turned off.
However, in some old versions of Pegasus Mail, this option was necessary, as the SMTP envelope sender address specified would be invalid, so using the From: header address would fix problems with sending mail.
In email, all lines must strictly end with a CR/LF pair (ASCII codes 13 + 10). Any other combinations of these characters (CR, LF, or LF/CR) are not interpreted as line endings.
Usually VPOP3 will follow the standards, however, it isn't unknown for other software which VPOP3 may communicate with not to follow the standards, and to use incorrect line endings. In this case, you can check this option to tell VPOP3 to interpret any of the four possible combinations of line endings as ending a line (CR, LF, CR/LF, LF/CR).
Note that doing this can cause problems, so do not enable this option just in case.
For instance, in emails, the message is usually terminated by the character sequence CR LF '.' CR LF. We have seen cases where a message body (usually spam or a virus) has contained the sequence CR '.' CR in the middle. By telling VPOP3 to allow any line endings unnecessarily, this would make VPOP3 assume that the message had finished when it saw the incorrect sequence. This would cause errors subsequently as the remainder of the message is received when it is not expected.