As an anti-spam provision, each web site has a dynamic email limit called its "email bank." This represents the amount of email that a site can send before it is rate-limited. By default, the email bank can hold a maximum of 100 "points," each of which can be used to send one message. Points accrue at the rate of one per minute, starting from 0 when the site is created.
Each site's email bank values are shown on the Site Information page as a fraction on the "Email Sending" line. The first number indicates the current size of the email bank, and the second number indicates the maximum size. For example, if it shows 75/100, it means the site's email bank currently contains 75 out of a maximum of 100 points. If it shows 100/100, it indicates that your bank is full, implying that the site has not sent any email recently.
Each time your site sends a message, the email bank will be debited one point. As long as your site's current email bank size is positive, it should be able to send 30-60 messages per minute. If your site's email bank reaches zero (e.g. 0/100), additional messages sent will be queued until more points are available, effectively rate-limiting additional messages to one per minute. If your site has queued outbound messages, this information will also be visible on the Site Information page.
If a message bounces or is blocked by our outbound spam filters or for noncompliance with best practices, then an additional point will be debited from the bank.
You can see information about your email bank, current queue size (if any), and counts of messages sent, bounced, or dropped (in the format today/yesterday) on the Site Information panel for your site.
If your site generates a large mail queue, usually the result of a vulnerable email form, we will automatically investigate. If we believe there is an issue, we will remove spam, disable any exploited sites, and contact you about the problem.
If the messages are not spam, they will be cleared to send, and if it happens frequently, your maximum bank size may be raised to accommodate the typical volume of email that your site sends. If you have an increased bank size, you will both send messages and recover bank points more quickly. We do not make changes to the automatic email volume limits based on member inquiry, only based on actual, reoccurring conditions detected and observed by us. Most reviews of the queue take place during our standard support hours, so if you have a large volume of mail to send, please try to avoid sending it in the middle of the night or it may get delayed until the following morning.
The email bank and sending/bounce/drop statistics apply only to emails sent by your web site. Email forwarding is an entirely separate service and has no connection to any site's email bank.
We do not currently offer email hosting, nor do we offer any reseller arrangements in this area at the present time.
Some of the paid services that we see our members using most frequently include Proton Mail, FastMail, and Google Workspace. But it's not lost on us that this list is getting short. We've had to remove entries from this list more often than we've been able to add them. Please choose your email provider carefully.
Our theory is that Gmail does not like "duplicate" messages. Because there is a copy of this message already in your "Sent" folder, it appears that gmail will ignore the copy that has made the round trip through our server and back.
If you try your test from some other Gmail account (one other than the one the message will ultimately be delivered to) then it should arrive normally.
Gmail also filters spam and viruses fairly vigorously, and sometimes test messages blend in, so don't forget to check your "Junk" folder if you're expecting a message that hasn't arrived. We also have some reported cases that messages sent to Gmail sometimes simply don't arrive (whether forwarded through our system or not).
This is one of the great scourges facing the Internet today. Anyone can forge email to make it look like it came from anyone, and spammers do. They don't need anything special, no passwords, no special access, nothing. They pick domains at random in order to help obscure who they are and where they are coming from.
If this happens to your domain, the symptom will be that you will receive a large number of bounce messages for messages you never sent. If you investigate further, you will generally find that the From: addresses of the messages are either fake names (frank@example.com, bob@example.com) or gibberish addresses (2nkdklwejw@example.com).
When you configure your mail client to send mail from your domain instead of your ISP's, it's completely between you and your mail client. Everybody else has to trust that you told your software the truth. Nobody can stop you from putting "president@whitehouse.gov" as your sender address. Spammers abuse this trust to send out their messages.
Messages like these never pass through our system, so we can't help you figure out where they are coming from or help stop them. In general, messages of this type are sent through hacked machines belonging to residential cable modem Internet subscribers, or they are sent through unprotected servers in developing countries like China.
This happens sooner or later with every registered domain and, at present, there is unfortunately nothing that can be done to stop it. This is true no matter what domain registrar or hosting company is used, and is even true if the domain isn't used for web hosting.
If you use your domain for email, setting an SPF record in your DNS that lists servers that legitimately originate email from your domain may help. We do offer an SPF option for domains not used for sending email, which is a helpful step if it applies.
While you cannot prevent this from happening, you can diminish its effects on you. Most of the people who get buried in bounce messages have "catch-all" email forwarding enabled. You can disable this and set up only specific email forwards, and this will dramatically decrease the number of bogus bounce messages you receive.
If you prefer a free, web-based solution, Gmail is one of the most popular, although some of our members find trusting Google with such sensitive information difficult. However, it can be tricky to get Gmail to send email from a non-Gmail address and Google is slowly removing the options for doing so.
In addition, most mail programs, such as Outlook, Outlook Express, and Thunderbird, have the ability to do this with just a few minutes' worth of configuration. However, you must have an SMTP email server that you can use to send these messages; we do not provide that service.
In almost all cases, the SMTP server you should use to send mail from your domain is run by your ISP, and it is the same server you would use to send mail from your regular ISP email account. Since ISPs vary widely, we cannot provide more specific guidance than this. However, they should have their own technical support that can help you get this set up.
For many reasons, we cannot provide this service to you. Most ISPs block access to outside mail servers by their users because of the email problems created when one of their users' computers gets a virus. Even if yours doesn't (and they probably should), you cannot use our servers to send mail as this is a technique called "relaying" that is used by spammers to conceal the origin of their messages. As a result of that, the practice of relaying is now deprecated and is not supported.
In order to fight spam, our email servers have very high standards for accepting email. Occasionally, this may cause someone who wants to send you email from a misconfigured email server to run into problems. If you can get a copy of the bounce message and forward it to us, we may be able to point the server operators in the right direction as far as fixing their problem, but since it is their problem, it will be up to them to fix it.
Since most of the inquiries about this come from people who are not members but have email problems and don't know what to do about them, most of our documentation of this subject can be found on our public Email Acceptance policy page in an attempt to help them.
We need you to have a current, working email address at all times in case we need to contact you about problems. If anything important to your contact email address is hosted here (DNS, domain registration, or email forwarding) and there's a problem with your service, we might not be able to contact you. That's bad.
For example, suppose your domain is registered here and it expires. And suppose that you forgot your password and need a new one mailed to you to fix things. But you can't get that message because your email doesn't work when your domain is expired. In cases like that, our Privacy Policy turns from a critically-important protection into a colossal roadblock; you'll wind up giving us a DNA sample and fingerprints to get your access back. (Well, not really, but it'll feel like that, especially if you're in a hurry.)
These types of circular dependencies create a lot of headaches, so we simply don't allow them.
If you don't want to have multiple email boxes to keep track of, there is a workaround. If your primary email address is in the domain that you want to host here, you can create a special alternate email address somewhere else, for example at a reasonably reliable provider of free email accounts, and set it up to forward copies of all the messages it receives to your normal mailbox. That way, you'll get all the messages, but if there's ever a problem, you can fall back on the alternate mailbox, secure in the knowledge that it's got copies of any recent messages we've sent you to work from.
Just be sure that you don't need your primary email address to reset your alternate one, in case you forget both. A bigger circular dependency is still a circular dependency. Whatever setup of forwarding and responsibility you set up should be able to be represented with a directed acyclic dependency graph.
If you want to originate mail from your site that uses a sender address in a domain name of yours, to help prevent your messages from being marked as spam, you should publish an SPF record incorporating our sending servers. This can be easily done without the need to check for periodic updates by using the SPF include facility. Just add include:sites.nearlyfreespeech.net to your SPF record.
For example, if you send email from your site, such as forum registrations from forum@example.com, but most of example.com's email is handled by Google apps, you would add a TXT record for example.com like:
This will tell the world that mail from example.com may originate from either Google or our sending servers, and that anything that comes from elsewhere is probably (but not definitely) a forgery.
Because of the very different usages and sending profiles, we have three completely different sets of email servers: one for NearlyFreeSpeech.NET service-related email, another for email forwarding, and a third for mail originating from member sites. Thus it is very important that you do not put include:nearlyfreespeech.net in your SPF record. We also strongly recommend against hardcoding specific servers into your SPF records. We may change them from time to time without notice.
If your site runs PHP, you should use the mail() function.
For all other languages, you should use /usr/bin/sendmail.
These are the only supported methods to send email from sites hosted on our service.
You may not connect to SMTP ports 25 or 465 on other networks' servers; these are SMTP MTA (mail transfer agent) ports used by full-time email servers to exchange existing messages with each other. Your web site is not an email server, so it is not appropriate for it to use these ports. Therefore, to prevent spammers from abusing our service, we actively block such connections.
Some email services offer authenticated SMTP MSA (mail submission agent) services on port 587 that may be appropriate for accepting new email messages from your site. However, doing so is unsupported by us and we do not guarantee it will be a suitable option for your circumstances; contact your email service if you need any assistance with this.
Greylisting is a technique we use in conjunction with email forwarding designed to help differentiate misconfigured servers from spammers and virus-writers.
A variety of standards and best practices exist around the protocols used to send emails and identify their senders (SMTP and DNS). Most servers follow these standards very closely. Spammers and email virus writers, on the other hand, are just as uninterested in standards as they are in the laws against what they do.
If (and only if) a standards compliance problem is detected with a sending server, the message it's sending is refused by us, and the sending server is added to the greylist. If the server tries to send that same message again a little later (one to four hours, depending on how messed up the server is), the message will be allowed and that server will be automatically added to a whitelist of servers that have passed the test.
Legitimate mail servers are required to queue messages and try them again later, so to them greylisting is a temporary inconvenience (plus it puts messages in their logs telling them to fix whatever problem(s) got them on the list). Viruses, on the other hand, have to fit their SMTP engines into small spaces; even if they wanted to implement a system that retried messages, they typically have no place to queue them. Greylisting is thus very effective against viruses in general, even new viruses that standard virus scans don't know to detect. Spam senders are somewhere in the middle; many use poorly-written software that simply sends out as much as it can as fast as it can, ignoring errors, and greylisting can be a pretty effective barrier to those.
The greylist (and the associated auto-whitelist) is on a per-sending-server basis and is shared by all of our email forwarding domains. Once auto-whitelisted, a legitimate server stays there until it goes 32 days without sending any mail; every time a message goes through, the clock resets. So as long as a server sends a message to someone using our email forwarding service at least once per month, it will stay in the clear.
In the event of a conflict, the spam blacklist (a list of known spam sources) overrides the auto-whitelist, so if a sending server is identified as a spam source sometime after being auto-whitelisted, its messages will still be thwarted.
The defining characteristic of any email forwarding service is that it forwards the email it receives on your behalf to some other mail server. When it comes to spam, this is a problem.
If we forward spam to other mail servers, those other mail servers don't know we didn't originate it. ("Hey, I really got this message from that other guy!" is a common spam sender trick.) If we forward enough of it, they will assume we are spammers and block our forwarders from delivering email to their mail servers entirely. Doing our best to prevent spam is the only way we can assure our continued ability to provide this service.
For that reason, we cannot honor requests to bypass our filtering mechanisms under any circumstances. To do so would threaten not only our ability to forward email to the member requesting it, but also our ability to forward email at all.
This is an unfortunate circumstance, but it's a necessary evil and is true for all viable email forwarding services, not just ours. If you have some special circumstance that requires you to receive spam, spam-like email, or viruses, or if you simply want to exert maximum control over how your email is handled, you will need to eschew the use of any type of forwarding and arrange for a direct-delivery email service that provides that level of control.
