[SFF Net Logo]
Home •  WebNews •  WebMail •  People Pages • Member Services 
    SFF Net FAQ

Choose a help topic from this list:
(or use the Master Help Index)

   Test your network connection
   Software Setup Instructions
   New to SFF Net?
   Your SFF Net Account


   About the Newsgroups
   Using WebNews


   About SFF Net Email
   Using WebMail

   People Pages & Hosted Domains

   Your SFF Net People Page
   Your People Newsgroup
   Blogging Tools
   Hosted Domains

Need more help? Click Here


    Skiffy, the SFF Net Wizard

Frequently-Asked Questions

Common Email Errors
  1. What does "553 needs authentication" mean?

    Skiffy says:

      SFF Net's outgoing (SMTP) servers require your email client to authenticate before you can send email. If you don't authenticate, the server will return a "553 needs authentication" error message to your email client and refuse to accept your email.

      See How do I enable SMTP Authentication? for more information.

  2. I tried to send someone email but got a bounce message. Is something broken on your server or with my machine?

    Skiffy says:

      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.

  3. 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?

    Skiffy says:

      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 email program.

  4. I use SFF Net's SMTP server to send mail, but I use the email address "so-and-so@myisp.com" instead of my SFF Net address. Now I'm getting error messages like "553 relay from <so-and-so@myisp.com> to <someone-else@somewhere-else.com> forbidden." What's up?

    Skiffy says:

      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 fred@sff.net and you want to use SFF Net's servers, you might set your reply-to address to wilma@flintstones.org. This way anyone who responds to your letter will write to wilma@flinstones.org, and your outgoing email will work correctly, too.

  5. 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?

    Skiffy says:

      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 "so-and-so@sff.net", 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.

  6. 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?

    Skiffy says:

      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.

  7. 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?

    Skiffy says:

      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 and re-tries.

      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 of RFC 1123 (http://www.faqs.org/rfcs/rfc1123.html).

  8. My friend got a bounce message that said "554 We do not accept unauthenticated email from hosts without reverse DNS" How come?

    Skiffy says:

      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.

  9. 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?

    Skiffy says:

      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.

  10. 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?

    Skiffy says:

      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:

      1. Try zipping up the file and sending that.
      2. You can also change your attachment sending method from MIME to UUENCODE.

      Windows solution:
      This requires making a few small changes to the system registry. Don't let that freak you out, the changes are simple and straightforward.

      1. Click Start Button --> Run. Enter REGEDIT in the Run box to start the Registry Editor.
      2. 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).
      3. 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.
      4. Double-click the Content Type value in the right-hand pane and change the entry to image/jpeg (see example)

        Changing JPEG MIME types

      5. Make the same change to the Content Type for the .jpeg and .jpg extensions as well. They should also be set to image/jpeg.
      6. Find the .gif extension and be sure its Content Type is set to image/gif.
      7. Restart Windows for the changes to take effect.

      Eudora users:
      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


      Home •  Help •  Search •  Contact Us

Copyright © 1996-2017 SFF Net(tm)  All Rights Reserved
We welcome your Feedback at any time.