Choose a help topic from this list:
(or use the Master Help Index)
FAQsNeed more help? Click Here
Test your network connection
Software Setup Instructions
New to SFF Net?
Your SFF Net Account
About the Newsgroups
About SFF Net Email
People Pages & Hosted Domains
Your SFF Net People Page
Your People Newsgroup
Frequently-Asked QuestionsCommon Email Errors
- What does "553 needs authentication" mean?
- I tried to send someone email but got a bounce message. Is
something broken on your server or with my machine?
Email error messages usually mean what they say. For example,
if your bounce message says "Email box is full," the mailbox of
the person you're trying to contact is probably full. If the
message says "Invalid TO: header," then there is probably
something wrong with what's been entered in the TO: field, etc.
Take a good look at the headers in your bounce message to see if you
can spot the problem before asking for help or assuming something is broken.
Most email problems are simple typos or are caused by someone putting
something that's not a real email address in the TO:, CC: or
FROM: address fields.
- My email program is set to use SFF Net's mail servers, but I just can't
send any mail. What's strange is I can download any new mail sent to me with no
problem. When I try to send, I get a timeout or sometimes an error saying
the "Server has unexpectedly terminated the connection," or "Connection Refused,"
or sometimes nothing happens at all. What's wrong?
Due to the growing flood of spam, many ISPs are blocking all SMTP (outgoing)
mail sent to TCP/IP port 25 except mail sent to their own servers.
This is to prevent their members from sending spam directly to external servers.
Set your mail client to use smtp.sff.net over port 587 instead of port 25,
and you should be able to get through. See the
How to Set Up Your System pages for instructions on how to do this for your
- I use SFF Net's SMTP server to send mail, but I use the email
address "firstname.lastname@example.org" instead of my SFF Net address.
Now I'm getting error messages like "553 relay from
<email@example.com> to <firstname.lastname@example.org>
forbidden." What's up?
Your email address must match the server you use to send your
email. If you are sending email with your email address set to
@home.com, then your SMTP server should be your home.com server.
If your email address is set to your SFF Net address, then you
should use smtp.sff.net as your SMTP server.
N.B. You may set your reply-to address to be anything you want.
For example, if your email address here is email@example.com and you
want to use SFF Net's servers, you might set your reply-to
address to firstname.lastname@example.org. This way anyone who responds
to your letter will write to email@example.com, and your
outgoing email will work correctly, too.
- I'm not using SFF Net's SMTP server to send mail, but suddenly
I can't send mail to my own box at SFF Net or to other SFF Net
email addresses. The error message is something like
"553 needs authentication" or "the return address was refused." What gives?
You have your email address set to your SFF Net address, but
are using your ISP's servers to send mail. This is one of the
more common types of the famous "forged header" problem with email.
In short, you are trying to lie to the email system. If you
say you are "firstname.lastname@example.org", but are actually coming from
hotmail.com or home.com, most servers will think you are
spamming (since that's what spammers do).
On systems where such spam quietly disappears, your email will
simply vanish. On other systems, your email may or may not
make it through. One thing's certain - if you send it here
addressed this way, it definitely won't get through.
The domain portion (the part after the @ sign) of your email
address should always match the domain of the service you are
using to send the email. If you are using SFF Net's servers,
use your @sff.net email address. If you are using myisp.com's
servers, use your @myisp.com email address. Even if your email
seems to go out okay without following this rule, chances are
good it won't make it to its destination. You may or may not
get a bounce message depending on how the various servers
through which your email passes are configured.
There's another good reason for this rule -- imagine if anyone
anywhere in the world could send email out with YOUR name on
it. SFF Net's servers prevent this by insisting that anyone
who claims to be sending email from SFF Net prove his/her
identity by authenticating. It won't be long before all
legitimate email services require this. More do every day.
- I've got my email from my ISP mailbox forwarded to my SFF Net mailbox and
I'm getting bounce messages that say "553 needs authentication." How come?
This is the basically same problem as the one described above, but in
this case it is your ISP's mailserver that is the culprit. Anyone
with an @sff.net address who sends to your ISP email address will have their
email automatically forwarded on to your @sff.net mailbox. Even though the
original email may have started from an @sff.net user, from our server's
perspective, it looks as if it is your ISP's server that is sending us a new message.
If your ISP's mailserver
doesn't rewrite the envelope FROM: address correctly, the email will arrive
at the SFF Net mailserver from your ISP but claiming to be from an
@sff.net user (i.e. the forged header problem described above).
A quick fix is for your correspondents with an @sff.net address to send directly
to your @sff.net address instead of to the forwarded address.
The best way to solve this problem is to not forward email between different
email boxes. This is also good Net citizenship, since it avoids sending and storing multiple
copies of the same email. Most modern email clients can be configured to pick up mail
directly from each mailbox automatically. See your mail client's help file
on using multiple accounts or personalities.
You may also try to inform your ISP that they should update their mailserver
to rewrite envelope FROM: addresses correctly for forwarded mail. Most
mailservers should already be doing this, as it is now widely considered
best practice for forwarded mail.
- People have been telling me they've sent me email that bounces with
error messages like "451 Mailbox Temporarily Unavailable" or "555
x delivery attempts in x minutes - please fix your MTA."
What's going on?
These messages indicate the sender is using a mail server that is
misconfigured in how it handles normal SMTP control messages,
in particular, the standard "451 Mailbox Temporarily Unavailable,
try again later" message.
According to the RFCs (the "rules" of Internet communications),
a mail server is not supposed to generate a bounce message when it
receives a 451 response. It is supposed to try the message again
15-30 minutes later, and if the server is still busy, again at
ever-increasing intervals for up to several days. This is to allow busy
servers to avoid being overwhelmed by thousands of simultaneous connections
If a sending server just ignores a 451 message and tries to send the email
anyway, or if it simply retries over and over within a short period of time,
our server will hang up on the sender with a more permanent "555" message that
indicates how often they tried and that their MTA (Message Transfer Agent,
a.k.a. email server) is broken and needs to be fixed.
This incorrect behavior is identical to what spamware does (hammering away
at a server regardless of the control messages). SFF Net will not accept mail
from any mail source that does not handle 451 messages correctly.
You will need to contact the sender of the email and have them contact their
email administrator to fix their server. It may help to pass on the information
that their server must comply with Section 188.8.131.52 of RFC 1123 (http://www.faqs.org/rfcs/rfc1123.html).
- My friend got a bounce message that said "554 We do not accept unauthenticated email
from hosts without reverse DNS" How come?
The error message means what it says - the email is arriving from a machine
that does not have a properly configured reverse DNS (PTR record) set up.
SFF Net prefers to not accept mail from systems without a proper reverse DNS lookup.
This most likely occurs because either the sender is running their own
mailserver and hasn't properly configured their DNS records, or they are
sending through another SMTP server (such as the one from their ISP) whose
DNS is not properly configured.
They will want to correct this or have their email provider correct it.
Having a proper reverse DNS lookup is basic, required DNS configuration for
any system acting as an SMTP MTA (Message Transfer Agent). A quick search of
the web for "configure reverse DNS" will provide sufficient information for
any system administrator to address this issue.
You can configure your mailbox to accept mail from such senders by changing the
Refuse email from servers that do not have reverse DNS setting in your WebMail
Spam Filter Options. Note that even if you configure
your mailbox to accept the mail, it will be flagged and processed as spam.
- Someone sent me an email and got a bounce that said "554 We do not accept unauthenticated email
from dialup or DSL --send through your ISP" Whazzup?
By far the largest sources of spam today are end-user machines compromised by viruses/trojans
that send spam without their owner's knowledge. The vast majority of those machines are on
dial-up or broadband connections that are assigned their IP address dynamically by their ISP.
Since legitimate mailservers use static (or fixed) IP addresses, SFF Net always flags email
coming from a server with a dynamic IP address as spam.
This error usually occurs when the sending SMTP server is run by someone running their own
email server on their home network (often in violation of their ISP terms of service).
Since more and more email providers are rejecting dynamically-assigned servers, the sender would be
well-served to either configure their system to use a static (fixed) IP address or send their outgoing
email through their ISP's email servers (a process known as "Smarthosting").
In the meantime, you can configure your mailbox to accept mail from such senders by changing the
Refuse email from servers that do not appear to have static IP addresses setting in your WebMail
Spam Filter Options. Note that even if you configure
your mailbox to accept the mail, it will be flagged and processed as spam.
- A friend is trying to send me an attached file and he's getting a bounce message that says
"554 Found multiline worm ID:" Hunh?
One of the trickier methods virus/worm authors use to fool people into running their malware is to
have their program pretend to be something benign, like an image file. One way they do this is to name
the worm executable file with a .JPG (or .GIF, .BMP, etc.) extension so that the user feels they can
safely click on the attachment. In order to cause Windows to actually execute the file (even though it
has a.JPG extension), worms will send their payload with an incorrect MIME type (application/octet-stream)
instead of the correct MIME type for .JPGs (image/jpeg). This will cause Windows to think the attachment is
an executable program instead of a display-only image and Windows will run the worm.
To prevent this kind of changeling chicanery, our system rejects any image attachment that has an incorrect
MIME type. In other words, if the attachment is named .JPG but it has a MIME type of
application/octet-stream, it is rejected. This is almost always because it actually is a worm, but
not always. Why? Continue on, oh faithful reader.
Unfortunately, some unhelpful programs and spyware change the default MIME type for images on Windows
systems without your knowledge. They almost always change the .JPG settings from image/jpeg to
application/octet-stream, but sometimes they change .GIF and .BMP as well. If changed, this causes
Windows to happily send .JPGs with the incorrect MIME type, even if they're not a worm.
Also, in rare occasions, some email programs that can't determine what kind of file you're sending as an attachement will send them erroneously as application/octet-stream.
There is a solution for Windows users (preferred) or workarounds for non-Windows users. Also, Eudora users
have their own solution (see below).
First, the workarounds for non-Windows users:
- Try zipping up the file and sending that.
- You can also change your attachment sending method from MIME to UUENCODE.
This requires making a few small changes to the system registry. Don't let that freak you out, the
changes are simple and straightforward.
- Click Start Button --> Run. Enter REGEDIT in the Run box to start the Registry Editor.
- On the left-hand pane of the Registry Editor program, click the HKEY_CLASSES_ROOT folder item to
expand it to show all of the extension types (they start with a period, i.e. .avi).
- Scroll down the list of extensions until you find the .jpe entry.
Highlight the .jpe item, which will then show the various values for it in the right-hand pane.
- Double-click the Content Type value in the right-hand pane and change the entry to image/jpeg
- Make the same change to the Content Type for the .jpeg and .jpg extensions as well. They should
also be set to image/jpeg.
- Find the .gif extension and be sure its Content Type is set to image/gif.
- Restart Windows for the changes to take effect.
Eudora keeps its own MIME settings in the EUDORA.INI file found in the Program Files\Qualcomm\Eudora folder
(Windows) or Esoteric Settings folder (Mac). Open the file and scroll (or search) through it to find the
existing JPEG entries in the [Mappings] section. Edit the file so those lines read:
Close Eudora and restart it for the changes to take effect.
List of FAQs