Why am I getting an email rejection sending me to this page?
Virus protection & Spam Filtering
- What does it mean when someone says I sent a virus to them and I didn't?
- Most viruses these days use spoofed (made-up) email addresses. As such, using an Anti-Virus product
which automatically notifies the perceived sender of a message (you) it believes is
infected may well cause more harm than good. Our servers do not send these notifications. We
suggest that if you receive a message saying that you are responsible for a
virus that you simply reply and let the sender know that your messages are all
virus-free and that many viruses now make up email addresses and that you are
not the sender.
Many viruses can send messages without any help from a mail server as well - they have a built-in server that does the job. Because of this they don't follow regular methods of delivery and can sometimes circumvent the virus scanning server by sending directly to the mail server that holds your mail. We are looking for methods to prevent this from happening but for now, just be aware that it is still possible to receive a virus-ladden message even with the virus protection service.
- How does this whole email thing work?
- Email is sent using the following method:
- The sender creates the message in their email client program
- They send the message using their mail server (SMTP server)
- Their mail server looks up the destination of the message (the To: and CC: addresses)
- Their server then looks up what mail server is responsible for each address (your POP3 server most likely)
- Their server then sends the message to each recipient.
- When it connects to a server to send a message it sends a 'HELO' message saying what server the message is from
- It then states who the message is to and from and sends the body of the message and any attachments there might be
- How is the message checked for spam content and filtered for viruses?
- When a mail server connects
to our scanning server it performs a number of checks and tests. If a message
fails any test it is rejected at that point. Here are the tests that are
performed:
- reject_unauth_pipelining: Reject the request when the client sends SMTP commands ahead of time without knowing that our server actually supports SMTP command pipelining. This stops mail from bulk mail software that improperly uses SMTP command pipelining to speed up deliveries.
- reject_non_fqdn_sender: Reject the request when the address in the client MAIL FROM command is not in fully-qualified domain form. (i.e. the FROM: address is user@domain not user@domain.com)
- reject_non_fqdn_recipient: Reject the request when the address in the client RCPT TO command is not in fully-qualified domain form. (the same as #2 but for the TO: address)
- reject_unknown_recipient_domain: Reject the request when the recipient mail address has no DNS A or MX record. (this looks up to see if it know where the TO: address goes and rejects if it doesn't know)
- to_recipients_bw: Looks in the black/white list to see if the TO: address is allowed or disallowed. If it's not in here it keeps going. If it's in here it either allows, skipping the rest of the tests, or disallows, rejecting the message
- reject_unknown_sender_domain: Reject the request when the sender mail address has no DNS A or MX record. (the same as #4 but for the FROM: address)
- permit_mynetworks: Allows any mail server or client to send a message that are on the allowed network list
-
reject_unauth_destination
: Reject the request unless one of the
following is true:
- the resolved destination address matches an allowed relay domain or a subdomain thereof, and the address contains no sender-specified routing (user@elsewhere@domain),
- Our server is the final destination.
- check_sender_access from_senders: if the sending domain contains '@b.' such as user@b.domain.com the message is rejected.
- check_sender_access from_senders_bw: this checks to see if the sending domain is on a black/white list and allows or disallows based on that
- check_helo_access helo_hostnames: blocks connections from mail servers saying that they are from the same domain as our mail server or from a local domain trying to trick our server into sending for them. Also checks for connections from domains with IP addresses in them (i.e. 192.168.1.10.dialup.att.net) which are typically subscriber based networks (dialup, dsl, and cable connections) and should be using the mail server from their ISP.
- check_sender_access from_senders_slet: quick check for old know spammer addresses
- check_sender_access from_senders_clueless: similar to #12
- check_sender_access from_senders_bogus: similar to #12
- check_sender_access from_senders_mybogus: checks for domains allowed to relay through this server to verifiy that the PTR and A records match on forward and reverse lookups to help prevent bogus servers from sending
- reject_rbl_client dnsbl.njable.org, cbl.abuseat.org, dul.dnsbl.sorbs.net, bl.spamcop.net, list.dsbl.org, relays.ordb.org, sbl.spamhaus.org, korea.services.net, opm.blitzed.org: rbl or real-time blackhole lists are lists of know spamming mail servers. This check looks up the IP address of the sending server against all of the listed blackhole lists and blocks if the address is found on one of them
- reject_rhsbl_client blackhole.securitysage.com: similar to #16 but it's a list of mail server domains
- reject_rhsbl_sender blackhole.securitysage.com: similar to #17
- permit: allows all messages that have not yet been rejected
After those series of checks the following checks are performed that have more to do with the message itself:
- header_checks: this checks for a number of offensive words and other odd spam-like things in the subject line and disallowed attachment types (i.e. pif, ini, cmd, reg, scr, bat, & others)
- body_checks body_checks: this checks for various offensive words in the body of the message as well as some basic virus signatures and disallowed attachments (i.e. htm, html, scr, pif, bat, com, exe & others)
- smtpd_helo_required: requires that a connecting mail server says 'HELO' when it connects, this will stop some spam software
- strict_rfc821_envelopes: this controls how tolerant our server is with respect to addresses given in MAIL FROM or RCPT TO commands. Being strict to the RFC not only stops unwanted mail, it also blocks legitimate mail from poorly-written mail applications.
If a message gets through all the previous checks it is then handed off to another program which scans for viruses using a virus signature file which is updated on a daily basis and then does more intensive scanning for spam using Spam Assassin. Spam Assassin scans for spam using an extensive array of tests. For a complete listing of these go to: http://useast.spamassassin.org/tests.html
- What are Rejected Messages and what causes them?
- Here is a list of
possible messages that someone sending to you may get if they send a message to
you and it is rejected:
- Helo command rejected: ACL from_senders_regexp The IP address of your sending machine is on a proscribed subscriber access network. Send from a non-subscriber network
- Helo command rejected: ACL helo_hostnames
- Recipient address rejected: Domain not found
- Recipient address rejected: Improper use of SMTP cmd pipelining
- Recipient address rejected: need fully-qualified address
- Relay access denied
- Sender address rejected: ACL from_senders_regexp
- Sender address rejected: Access denied
- Sender address rejected: Domain not found
- Sender address rejected: need fully-qualified address
- blocked using:
- bl.spamcop.net
- blackhole.securitysage.com
- cbl.abuseat.org
- dul.dnsbl.sorbs.net
- korea.services.net
- list.dsbl.org
- relays.ordb.org
- sbl.spamhaus.org
If someone sending to you gets a rejection message then have them forward that message to iasnet1@aol.com (to circumvent our spam protection system) so that we can investigate and respond as necessary.