Frequently Asked Questions
Details of email app configuration are on the E-mail settings page. It is important to select an encryption option and SSL/TLS is recommended.
The following apps are most popular with our users:
- Thunderbird (PC/Linux/Windows)
- Outlook (Windows)
- Apple mail (MacOS)
- K9 Mail (Android)
- Bluemail (Mobile devices)
Forwarding email to external ISP's creates risks of generating junk mail relays.
This is because it is not feasible to check in real-time if the address at the destination ISP is valid or not. If our servers accept the message, and then are unable to send it on, we are stuck with the message.
Spammers may use false senders, and the bounce message becomes the spam (known as backscatter).
Therefore we don't allow offsite forwarding to high-volume ISP's.
We do offer custom forwarding to enterprise email servers. Please get in touch to discuss.
This is because it is not feasible to check in real-time if the address at the destination ISP is valid or not. If our servers accept the message, and then are unable to send it on, we are stuck with the message.
Spammers may use false senders, and the bounce message becomes the spam (known as backscatter).
Therefore we don't allow offsite forwarding to high-volume ISP's.
We do offer custom forwarding to enterprise email servers. Please get in touch to discuss.
The root cause is that the specification for the SMTP (email sending) protocol (RFC 5322) is such that any line of an email MUST NOT exceed 1000 characters.
The problem is, despite it being a 'MUST NOT' in the specifications, it appears that Microsoft clients (eg. Outlook, IIS, etc.) ignore this part of the specification. It is uncommon for a line in an email to get this long, so it is not all Microsoft-based mail, but if it does occur, those emails will be invalid SMTP messages.
Lines that are too long can be built up when there are many messages in a thread. The mail client should fold these lines tro be within the specification.
Many modern mail servers enforce this limit and will reject the message. The solution is to create a new email which then should be deliverale.
The problem is, despite it being a 'MUST NOT' in the specifications, it appears that Microsoft clients (eg. Outlook, IIS, etc.) ignore this part of the specification. It is uncommon for a line in an email to get this long, so it is not all Microsoft-based mail, but if it does occur, those emails will be invalid SMTP messages.
Lines that are too long can be built up when there are many messages in a thread. The mail client should fold these lines tro be within the specification.
Many modern mail servers enforce this limit and will reject the message. The solution is to create a new email which then should be deliverale.