Packet loss

Packet loss occurs when one or more packets of data travelling across a computer network fail to
reach their destination. Packet loss is typically caused by network congestion. Packet loss is
measured as a percentage of packets lost with respect to packets sent.

The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to
ensure reliable messaging. Packet loss in a TCP connection is also used to avoid congestion and
reduces throughput of the connection.

In streaming media and online game applications, packet loss can affect the user experience.

Contents
[hide]

 1 Causes
 2 Effects
 3 Measurement
 4 Acceptable packet loss
 5 Diagnosis
 6 Rationale
 7 Packet recovery for reliable delivery
 8 Impact of queuing discipline
 9 See also
 10 References
 11 External links

Causes [edit]
Packet loss is typically caused by network congestion. When content arrives for a sustained
period at a given router or network segment at a rate greater than it is possible to send through,
then there is no other option than to drop packets.[1] If a single router or link is constraining the
capacity of the complete travel path or of network travel in general, it is known as a bottleneck.

Packet loss can be caused by a number of other factors that can corrupt or lose packets in transit,
such as radio signals that are too weak due to distance or multi-path fading (in radio
transmission), faulty networking hardware, or faulty network drivers. Packets are also
intentionally dropped by normal routing routines (such as Dynamic Source Routing in ad hoc
networks, [2]) and through network dissuasion technique for operational management purposes.[3]

Packet loss can also be caused by a packet drop attack.

Effects [edit]
Packet loss can reduce throughput for a given sender, whether unintentionally due to network
malfunction, or intentionally as a means to balance available bandwidth between multiple
senders when a given router or network link reaches nears its maximum capacity.[4]
When reliable delivery is necessary, packet loss increases latency due to additional time needed
for retransmission. Assuming no retransmission, packets experiencing the worst delays might be
preferentially dropped (depending on the queuing discipline used) resulting in lower latency
overall at the price of data loss.

During typical network congestion, not all packets in a stream are dropped. This means that
undropped packets will arrive with low latency compared to retransmitted packets, which arrive
with high latency. Not only do the retransmitted packets have to travel part of the way twice, but
the sender will not realize the packet has been dropped until it either fails to receive
acknowledgement of receipt in the expected order, or fails to receive acknowledgement for a
long enough time that it assumes the packet has been dropped as opposed to merely delayed.

Measurement [edit]
Packet loss may be measured as frame loss rate defined as the percentage of frames that should
have been forwarded by a network but were not.[5]

Acceptable packet loss [edit]

Packet loss is closely associated with quality of service considerations, and is related to the
erlang unit of measure.

The amount of packet loss that is acceptable depends on the type of data being sent. For
example, for Voice over IP traffic, one commentator reckoned that "[m]issing one or two packets
every now and then will not affect the quality of the conversation. Losses between 5% and 10%
of the total packet stream will affect the quality significantly."[6] Another described less than 1%
packet loss as "good" for streaming audio or video, and 1-2.5% as "acceptable".[7] On the other
hand, when transmitting a text document or web page, a single dropped packet could result in
losing part of the file, which is why a reliable delivery protocol would be used for this purpose
(to retransmit dropped packets).

Diagnosis [edit]
Packet loss is detected by application protocols such as TCP, but when a person such as a
network administrator needs to detect and diagnose packet loss, they typically use a purpose-
built tool. Many routers have status pages or logs, where the owner can find the number or
percentage of packets dropped over a particular period.

For remote detection and diagnosis, the Internet Control Message Protocol provides an "echo"
functionality, where a special packet is transmitted that always produces a reply after a certain
number of network hops, from whichever node has just received it. Tools such as ping,
traceroute, and MTR use this protocol to provide a visual representation of the path packets are
taking, and to measure packet loss at each hop.

In some cases, these tools may indicate drops for packets that are terminating in a small number
of hops, but not those making it to the destination. For example, routers may give echoing of
ICMP packets low priority and drop them preferentially in favor of spending resources on
genuine data; this is generally considered an artifact of testing and can be ignored in favor of
end-to-end results.[8]
Rationale [edit]
The Internet Protocol (IP) is designed according to the end-to-end principle as a best-effort
delivery service, with the intention of keeping the logic routers must implement as simple as
possible. If the network made reliable delivery guarantees on its own, that would require store
and forward infrastructure, where each router devoted a significant amount of storage space to
packets while it waited to verify that the next node properly received it. A reliable network
would not be able to maintain its delivery guarantees in the event of a router failure. Reliability is
also not needed for all applications. For example, with a live audio stream, it is more important
to deliver recent packets quickly than to ensure that stale packets are eventually delivered. An
application may also decide to retry an operation that is taking a long time, in which case another
set of packets will be added to the burden of delivering the original set. Such a network might
also need a command and control protocol for congestion management, adding even more
complexity.

To avoid all of these problems, the Internet Protocol allows for routers to simply drop packets if
the router or a network segment is too busy to deliver the data in a timely fashion, or if the IPv4
header checksum indicates the packet has been corrupted. Obviously this is not ideal for speedy
and efficient transmission of data, and is not expected to happen in an uncongested network.[4]
Dropping of packets acts as an implicit signal that the network is congested, and may cause
senders to reduce the amount of bandwidth consumed, or attempt to find another path. For
example, the Transmission Control Protocol (TCP) is designed so that excessive packet loss will
cause the sender to throttle back and stop flooding the bottleneck point with data (using
perceived packet loss as feedback to discover congestion).[9]

Packet recovery for reliable delivery [edit]

The Internet Protocol leaves responsibility for any retransmission of dropped packets, or "packet
recovery" to the endpoints - the computers sending and receiving the data. They are in the best
position to decide whether retransmission is necessary, because the application sending the data
should know whether speed is more important than reliability, whether a message should be re-
attempted in whole or in part, whether or not the need to send the message has passed, and how
to vary the amount of bandwidth consumed to account for any congestion.

Some network transport protocols such as TCP provide endpoints an easy way to ensure reliable
delivery of packets, so that individual applications don't need to implement logic for this
themselves. In the event of packet loss, the receiver asks for retransmission or the sender
automatically resends any segments that have not been acknowledged.[10] Although TCP can
recover from packet loss, retransmitting missing packets causes the throughput of the connection
to decrease. This drop in throughput is due to the sliding window protocols used for
acknowledgment of received packets. In certain variants of TCP, if a transmitted packet is lost, it
will be re-sent along with every packet that had been sent after it. This retransmission causes the
overall throughput of the connection to drop.

Protocols such as User Datagram Protocol (UDP) provide no recovery for lost packets.
Applications that use UDP are expected to define their own mechanisms for handling packet
loss.

Impact of queuing discipline [edit]

There are many queuing disciplines used for determining which packets to drop. Most basic
networking equipment will use FIFO queuing for packets waiting to go through the bottleneck
and they will drop the packet if the queue is full at the time the packet is received. This type of
packet dropping is called tail drop. Other full queue mechanisms include random eviction or
weighted random eviction. Dropping packets is undesirable as the packet is either lost or must be
retransmitted and this can impact real-time throughput; however, increasing the buffer size can
lead to bufferbloat which has its own impact on latency and jitter during congestion.

In cases where quality of service is rate limiting a connection, packets may be intentionally
dropped in order to slow down specific services to ensure available bandwidth for other services
marked with higher importance (like those used in the leaky bucket algorithm). For this reason,
packet loss is not necessarily an indication of poor connection reliability or a bottleneck.

Traffic shaping
From Wikipedia, the free encyclopedia
Jump to: navigation, search

Traffic shaping (also known as packet shaping) is a computer network traffic management
technique which delays some or all datagrams to bring them into compliance with a desired
traffic profile.[1][2] Traffic shaping is used to optimize or guarantee performance, improve latency,
and/or increase usable bandwidth for some kinds of packets by delaying other kinds. It is often
confused with traffic policing, the distinct but related practice of packet dropping and packet
marking.[3]

The most common type of traffic shaping is application-based traffic shaping.[4] In application-
based traffic shaping, fingerprinting tools are first used to identify applications of interest, which
are then subject to shaping policies. Some controversial cases of application-based traffic
shaping include bandwidth throttling of peer-to-peer file sharing traffic. Many application
protocols use encryption to circumvent application-based traffic shaping. Another type of traffic
shaping is route-based traffic shaping. Route-based traffic shaping is conducted based on
previous-hop or next-hop information.[5]

Contents
[hide]

 1 Functionality
 2 Uses
 3 Implementation
o 3.1 Overflow condition
o 3.2 Traffic classification
o 3.3 Self-limiting sources
o 3.4 Relationship to traffic management
 4 ISPs and traffic management
o 4.1 Benefits to the ISP
 5 Enterprises
 6 Traffic shaping detection
 7 See also
 8 References
 9 External links

Functionality[edit]
If a link becomes saturated to the point where there is a significant level of contention (either
upstream or downstream) latency can rise substantially. Traffic shaping can be used to prevent
this from occurring and keep latency in check. Traffic shaping provides a means to control the
volume of traffic being sent into a network in a specified period (bandwidth throttling), or the
maximum rate at which the traffic is sent (rate limiting), or more complex criteria such as
GCRA. This control can be accomplished in many ways and for many reasons; however traffic
shaping is always achieved by delaying packets. Traffic shaping is commonly applied at the
network edges to control traffic entering the network, but can also be applied by the traffic
source (for example, computer or network card[6]) or by an element in the network.

Uses [edit]
Traffic shaping is sometimes applied by traffic sources to ensure the traffic they send complies
with a contract which may be enforced in the network by a police.

It is widely used for network traffic engineering, and appears in domestic ISPs' networks as one
of several Internet Traffic Management Practices (ITMPs).[7] Some ISPs may use traffic shaping
against peer-to-peer file-sharing networks, such as Bit Torrent.[8]

Nodes in an IP network which buffer packets before sending on a link which is at capacity result
in an unintended traffic shaping effect. This can appear at for example a low bandwidth link
(such as dial-up), a particularly expensive WAN link or satellite hop.

Traffic shaping is often used in combination with:

  Differentiated services, Integrated services—including traffic classification and
prioritization.
 Weighted round robin (WRR) scheduling
 Random early detection (RED) queuing, Weighted RED (WRED) and RED In/Out
(RIO)—Lessens the possibility of port queue buffer tail drops and this lowers the
likelihood of TCP global synchronization.
 A number of port queue buffers.
 VLAN tagging IEEE 802.1q

Implementation [edit]
A traffic shaper works by delaying metered traffic such that each packet complies with the
relevant traffic contract. Metering may be implemented with for example the leaky bucket or
token bucket algorithms (the former typically in ATM and the latter in IP networks). Metered
packets or cells are then stored in a FIFO buffer for each separately shaped class, until they can
be transmitted in compliance with the prevailing traffic contract. This may occur immediately (if
the traffic arriving at the shaper is already compliant), after some delay (waiting in the buffer
until its scheduled release time) or never (in case of buffer overflow).

Overflow condition[edit]

All traffic shaper implementations have a finite buffer, and must cope with the case where the
buffer is full. A simple and common approach is to drop traffic arriving while the buffer is full
(tail drop), thus resulting in traffic policing as well as shaping. A more sophisticated
implementation could apply a dropping algorithm such as Random Early Discard; a crude
alternative would be to allow overflowing traffic through unshaped.

Traffic classification [edit]

Simple traffic shaping schemes shape all traffic uniformly by rate. More sophisticated shapers
first classify traffic. Traffic classification categorizes traffic (for example, based on port number
or protocol). Different classes can then be shaped separately to achieve a desired effect.

Self-limiting sources [edit]

A self-limiting source produces traffic which never exceeds some upper bound, for example
media sources which cannot transmit faster than their encoded rate allows.[9] Self-limiting sources
shape the traffic they generate to a greater or lesser degree. Congestion control mechanisms can
also affect traffic shaping of sorts - for example TCP's window mechanism implements a
variable rate constraint related to bandwidth-delay product.

TCP Nice, a modified version of TCP developed by researchers at the University of Texas at
Austin, allows applications to request that certain TCP connections be managed by the operating
system as near zero-cost background transfers, or "nice" flows. Such flows interfere only
minimally with foreground (non-nice) flows, while reaping a large fraction of spare network
bandwidth.[10]

Relationship to traffic management [edit]

Traffic shaping is a specific technique and one of several which combined constitutes Bandwidth
management.[11] Current common usage, particularly in discussion of domestic Internet service
provision, frequently confuses traffic shaping with traffic management and traffic policing, with
classification policies and in general with any measure deliberately taken by an ISP which is
detrimental to some user's IP traffic performance.

ISPs and traffic management [edit]

See bandwidth throttling, bandwidth management, and also Teletraffic engineering in
broadband networks

Traffic shaping is of interest especially to Internet Service Providers (ISPs). Their high-cost,
high-traffic networks are their major assets, and as such, are the focus of all their attentions.
They sometimes use traffic shaping to optimize the use of their network, sometimes by
intelligently shaping traffic according to importance, other times by discouraging uses of
applications by harsh means.[12] There are those who believe it is not the ISP's place to decide
what is "important"; in such cases per-client traffic shaping is more effective without creating
potential controversies about what traffic is being controlled.

Benefits to the ISP[edit]

This section needs additional citations for verification. Please help improve this
article by adding citations to reliable sources. Unsourced material may be challenged
and removed. (August 2009) (Learn how and when to remove this template message)

To ISPs, mere protocol identification (classification) gives the intangible yet significant benefit
of seeing what internet traffic is flowing through the network. From this they can see which
subscribers are doing what on their network and can target services to the subscriber base they
have attracted. However, as time progresses, more and more protocols are using tunneling and
encryption to defeat these methods. Also, many protocols are very difficult or impossible to
detect. In such cases, per-client shaping is more effective. By establishing policies based on the
IP or IP grouping of a client, ISPs ensure that end users cannot defeat shaping by disguising
protocols or encrypting their traffic.

In addition, intelligent shaping schemes can guarantee a particular Quality of Service (often
measured in jitter, packet loss, and latency) for an application or a user while still allowing other
traffic to use all remaining bandwidth. This allows ISPs to offer Differentiated services and to
upsell existing services to subscribers (such as offering minimum-latency computer gaming for
an additional fee on top of basic internet).

More importantly, shaping allows ISPs to tier their services using software, reducing their costs
and increasing the menu of products they can offer.

For Wireless ISP's, particularly those who use Wifi-based protocols, Congestive collapse is a
serious problem. Due to the unfortunate nature of Wifi when several stations are all trying to
access a single access point at once, once the load is past roughly 95% channel load, the
throughput starts to drop dramatically. Whilst the channel stays at the same usage (roughly 99%),
the throughput just gets slower and slower due to the number of retries. TCP performance may
be greatly impacted by the long delay over the wireless link caused by the congestion at the
access point. A long delay can cause expiration of the TCP RTO timer at the sender's side and
then force TCP into slow-start. On the other hand, if the long delay is experienced on the ACK
path, it could cause the so-called "ACK compression", which will disturb the synchronization
between the TCP sender and the TCP receiver. Multiple compressed ACKs if passing through
the wireless access point all together can clock-out the same amount of large packets from the
TCP sender and all of them may arrive at the wireless bottleneck in a short time and further
worsen the congestion there. Therefore, traffic shaping should be seriously considered on a
WISP in order to avoid these possible performance impacts.

Enterprises[edit]
Most companies with remote offices are now connected via a Wide area network (WAN).
Applications tend to become centrally hosted at the head office and remote offices are expected
to pull data from central databases and server farms. As applications become more hungry in
terms of bandwidth and prices of dedicated circuits being relatively high in most areas of the
world, instead of increasing the size of their WAN circuits, companies feel the need to properly
manage their circuits to make sure business-oriented traffic gets priority over best-effort traffic.
Traffic shaping is thus a good means for companies to avoid purchasing additional bandwidth
while properly managing these resources.

Alternatives to traffic shaping in this regards are application acceleration and WAN optimization
and compression, which are fundamentally different from traffic shaping. Traffic shaping defines
bandwidth rules whereas application acceleration using multiple techniques like a TCP
Performance Enhancing Proxy. WAN optimization and compression (WOC) on the other hand
would use compression and differential algorithms and techniques to compress data streams or
send only differences in file updates. The latter is quite effective for chatty protocols like CIFS.
TROUBLESHOOTING COMMON
ISSUES WITH EMAIL

Overview
Email covers a broad category of services. Some errors are easy to diagnose while others require
a bit of investigation. This article is intended to help with that investigation. Skim through the
topics in this section to see if your specific issue is addressed. If you're not sure where to start or
if the article you first click on doesn't resolve the issue, please go through our practical guide to
troubleshooting walkthrough in the next section for further assistance.

New domain and DNS

If you've recently added your domain to your (mt) Media Temple server, start here. This section
also covers basic DNS settings.

 Email Troubleshooting - New Domain Checklist and DNS

Bounceback
If you or your contacts are receiving bounceback, start here:

 Email Troubleshooting - Bounceback

I can't send or receive

First, check the DNS section here:

 Email Troubleshooting - New Domain Checklist and DNS

You may also have the wrong settings in your local email client. You can double-check your
email client settings here:

 Third-party email applications

You can also test the POP/IMAP services running on your server. The following article has more
information on this.

 Email Troubleshooting - Testing POP/IMAP

If that doesn't resolve your issue, please see the practical guide to troubleshooting below.
I can receive, but I can't send
Make sure that Port 25 isn't blocked on your network.

Also, make sure that you are using authentication in your outgoing email settings. Apple Mail
and related products (iPhone, iPad) tend to skip this during initial setup. Here's a list of walk-
throughs for a variety of email clients:

 Third-party email applications

For a larger and more specific list of errors, please see:

 Troubleshooting SMTP problems

I can send, but I can't receive

Make sure that your mail service is enabled.

Also, check to make sure that you don't have a forwarder set up for the account that is sending all
your email to a different email address. If you do have a forwarder set up, make sure it also
keeps a copy in the original account.

 Creating an email alias/forwarder

Missing emails
If you are missing one or more email messages, or you never received an email you were
expecting, start here. Check the third-party hosting section if you don't host your email with (mt)
Media Temple.

 Email Troubleshooting - Missing Emails

Slow email and Disk Quota errors

If your inbox loads very slowly, or it is extremely slow to send and receive, start here. A Disk
Quota Exceeded error is a definite indication of a mailbox size problem.

 Email Troubleshooting - Mailbox Size

 Also, check your mail queue.

I'm getting bounceback or complaints that I'm sending spam.

If you suspect that spam is being sent from your email address, you may need to add an SPF
record to your DNS zone file.

See this article for a detailed diagnosis:

 Email Troubleshooting - Spam From My Address

See this article to add your SPF record:

 How can I create an SPF record for my domain?

Duplicate emails, or old emails downloading again

If you have multiple copies of the same email, start here:

 Email Troubleshooting - Duplicate Emails

A practical guide to troubleshooting

This is a practical, step-by-step approach to troubleshooting email problems.

Is the problem on the server?

1. The best way to test server problems is to try to use your webmail. Webmail is hosted on
the server itself, and so bypasses your network and your local email client. This makes it
ideal for troubleshooting.
2. Visit your webmail URL.
o http://webmail.example.com: Please replace example.com with your own domain
name.
3. Log into webmail with your full email address and email password.
o If you CAN'T log in, please try to reset your password.
 If you still get an authentication error, this is most likely a server issue.
 If you don't get an error, but it takes a very long time to log in and/or times
out, please skip to Email Troubleshooting - Mailbox Size.
o If you CAN log in, proceed to the next step.
4. Send yourself a test message. You can send to this same email address, or to an external
email address (such as a Hotmail or Gmail account). Reply to the message to test both
sending and receiving.
o If you get an immediate error when attempting to send or receive, note the exact
error. This is a server issue.
o If you get a bounceback, please skip to Email Troubleshooting - Bounceback.
o If you get no error, but the message has not delivered for at least five minutes,
please skip to Email Troubleshooting - Missing Emails.
o If you can successfully send and receive from webmail, this indicates that the
server is fine. Proceed to the next step, then the next section, to troubleshoot
possible network problems.
5. There are a small number of server problems that might not be "caught" by the webmail
test. If you notice one of the following, please first continue with the next troubleshooting
sections, because these problems are just as likely to be caused by a network or email
client problem. If you finish troubleshooting and are still having one of the problems
described below, continue to the final step.
o If you have SMTP or Outgoing mail server connection problems, the mail server
may be configured incorrectly.
o If you have problems with POP but not IMAP, webmail uses IMAP only, so
again, the mail server setting in your email client may be configured incorrectly.
Is the problem with the network?
Some email problems can occur between your computer and the (mt) Media Temple server.
There are dozens of connection points between your computer and the server. There's a
connection from your computer to your local network, from your local network to your Internet
Service Provider, from your Internet Service Provider to the next Internet Service Provider down
the line, and so on. A problem with one of these connection points is a network problem.
Follow the steps below to continue troubleshooting:

1. Run a telnet test to the server for the appropriate port. You can run this test from your
command prompt (Terminal on Mac or Run > cmd on Windows). Click on the link for a
step-by-step walkthrough. The general format of the test is as follows:
2.
3. telnet example.com 25

You should replace example.com with your own mail server name (the same as your
domain name in most cases), and 25 with the port number you are try to test. Here's a
summary of port numbers related to email:

o 25 - standard outgoing SMTP port

 Note - this port is consistently blocked by Internet Service Providers in an
effort to prevent spam. See the special Outgoing mail blocked on Port 25
section below for further assistance.
o 587 - alternate outgoing SMTP port
o 465 - SSL encrypted outgoing SMTP port
o 110 - incoming POP port
o 995 - SSL encrypted incoming POP port
o 143 - incoming IMAP port
o 993 - SSL encrypted incoming IMAP port
4. Examine the results of your telnet test. A response of "220" or "Connected" indicates
connection success - continue on to the email client troubleshooting below. A timeout or
"Unable to connect" message indicates that you have a network problem.
5. While a problem on a specific port may not show itself in a generic traceroute, it doesn't
hurt to try. For detailed instructions, on running a traceroute, see Using the traceroute
command. For quick reference, run one of the following from your command prompt:
Windows:

tracert example.com

Mac:

traceroute example.com

A timeout, or a few hops with only asterisks (*), may indicate a problem with the
connection hop listed before or after the timeout.
 6. If you have identified a network problem, you will need to contact your local network
administrator, or your Internet Service Provider, for further assistance. Even if the
problem is downstream from your local Internet Service Provider, they may be able to
reroute traffic for your domain through a different network path, so that you don't run
into the bad network connection beyond them.

Outgoing mail blocked on Port 25

It is becoming more and more common for Internet Service Providers to block outgoing SMTP
traffic on Port 25. This is part of their effort to block spam. There are two ways to get around
this:

1. Use Port 587 for outgoing email instead. You can switch your local email client to use
Port 587 by following the appropriate guide here:
o List of third-party email clients

You will also need to make sure that your server supports Port 587 for outgoing mail.

o Enable Port 587

2. Use your Internet Service Provider's outgoing SMTP server. You can contact your
Internet Service Provider for the server name, username, and password. Your email will
still be coming from your own email address at your own domain name; it will just be
delivered by their server.

Is the problem with my local email client?

If your webmail test and your telnet tests from the previous section haven't turned up any server
or network problems, this indicates that the problem is most likely with your local email client.
The suggestions go in order from least to most changes required for your current setup.

1. The best thing you can do for your email client is to double-check all of your settings.
Even if they are correct, sometimes re-typing them can jog your email program into
functioning correctly. We have a list of articles with the correct settings here: Third-party
email applications.
2. If that doesn't resolve the issue, you may want to try recreating the email account. Again,
that can jog your software into using the correct settings. See the link above for helpful
walkthroughs.
3. Perform an online search for any specific error messages that you see in the email client.
You can also search in that email program's help forums specifically.
4. Contact the support team for your specific email application. Check their website for
instructions on how to receive support.
5. Reinstall the email client - note that this will delete any existing downloaded emails and
custom settings!
6. Try a different email client. Thunderbird is free and works on both Mac OS X and
Windows.

What to submit if you need (mt) Media Temple help

 1. Exact email account that is experiencing the problem. Include two or three specific
examples if multiple accounts are affected.
2. Permission for (mt) Media Temple technicians to reset the email account password for
testing. You will have to reset your email password afterward to regain access.
3. All email clients used to check mail. Include whether you use POP or IMAP.
Example: I use Outlook (IMAP) at work, my iPhone (POP) when I'm at business
meetings, and webmail when I'm on vacation.
4. Include any error messages that you are getting from your email software. Please copy
and paste the exact error.
5. Include any bouncebacks that you receive when you try to send email, or that your
contacts receive when they try to send you email. Please copy and paste the entire
bounceback.
6. When did the problem start happening?
7. Does the problem happen all the time, or intermittently? Does it happen at a specific
time?
8. Describe what you do that triggers the problem.
Example: I get a popup error when I try to send an email; or, when I first connect to my
inbox, it takes 10 minutes to load.

If you are trying to investigate a specific email, please also include the following:

1. Exact subject line.

2. Sender and recipient.
3. Date and time email was sent, to within 15 minutes. Note that on the Grid, mail logs are
kept for only one week, so the email must also be recent.
4. Header information from the original email (may be located in your Sent folder). For
more information, please see: How do I view email headers for a message?

Please make sure that the spelling, capitalization, and punctuation for the subject line and the
sender and recipient are exactly correct. This is necessary for an accurate mail log search.

Email headers
Need all the details about a specific email? Every email comes with a header that includes
information like timestamps for when it was sent and received, exact names of the mail servers it
went through, and what elements triggered your spam filter. For instructions on how to find and
interpret your email headers, see these two articles:

 How do I view email headers for a message?

 Understanding an email header

Search
EMAIL TROUBLESHOOTING -
NEW DOMAIN CHECKLIST AND
DNS

Overview
If you've just pointed your domain over to (mt) Media Temple, please go through this article to
make sure everything is set up properly for your email. These are also valid troubleshooting steps
for existing domains.

DNS settings and MX records

Make sure your DNS settings are actually pointing your email traffic to your (mt) Media Temple
server. The DNS record that controls your email is called the MX record.

For (mt) Media Temple, your MX record will typically point to mail.example.com, (with your
own domain name instead of example.com). In that case, you will want to check your
mail.example.com A record also. Here is what the two records should look like - note that the IP
address should be your (mt) Media Temple server IP address:

example.com MX 10 mail.example.com

mail.example.com A 70.32.68.238

You can check your current DNS settings using an online tool like the one at MX Toolbox or
Kloth.net.

MX Toolbox automatically checks your MX record once you type in your domain name, so it's
great for quick DNS checks. However, if your result is something like mail.example.com you
should also do an A record check for that subdomain.

To check the A record for a subdomain, you can use Kloth.net. To test your MX record here,
type your domain name in the Domain field, then select MX (mail exchange) in the Query field,
and click Look it up. If the result is something like mail.example.com, you can then type that
exact same result into the Domain field for your next query. This time, leave the Query on A (IP
address). Look it up again, and make sure the IP address matches your (mt) Media Temple IP.

If your results show that your email is not currently pointing to your (mt) Media Temple server,
and you want it to, you will need to either a) Start using the (mt) Media Temple nameservers or
b) Update your existing zone file to include the correct MX and A record entries, shown above.
NOTE:

 If you have recently made a change to your DNS settings, it can take 24-48 hours to
propagate.
 (mt) Media Temple is not affiliated with the third-party websites above.

Make sure the email account is created

Make sure you have set up all of your email accounts on your new server.

 Creating a POP/IMAP email account

Enable mail
See for detailed instructions.

By default, email is enabled on the DV for all new domains. If it was disabled for some reason,
you can re-enable the mail service by following the instructions here: How do I enable or disable
local mail for my domain?

Re-enter mail settings in your email client

There may be a few settings in your local email client that need to be updated so that your
software can connect to the (mt) Media Temple server. Some email software, particularly Apple
Mail, require some settings to be reset. Otherwise, it won't recognize that it needs to connect to a
new mail server. For both of these cases, please review all of the appropriate settings in our
article: Third-party email applications.

EMAIL TROUBLESHOOTING -
BOUNCEBACKS

Overview
If you, or one of your contacts, have received a bounceback message when attempting to send
email, this article will help you. Go through these troubleshooting steps to further diagnose and
resolve the cause of your bouncebacks.
(mt) Media Temple bounceback
If you, or your contact who was attempting to email you, received a bounceback from (mt)
Media Temple, please see the article below for detailed instructions. It also includes an example
of what a (mt) Media Temple bounceback looks like:

Why is my email blocked by the (mt) Media Temple spam filter?

Third-party bounceback
If you were attempting to send to a third-party mail server, and received a bounceback from
them, please do the following:

1. Read the bounceback. Often it will state exactly why the email was blocked. Some
common reasons:
o Sending server's poor reputation: This means that your mail server here is on the
recipient's block list.
o Recipient does not exist: This means your target email address no longer exists.
Check your spelling, if you've been able to send to this person before.
2. If the bounceback message is easy to interpret, correct the issue that it mentions.
o Eliminate possible spam coming from your server, then contact the RBL (realtime
blacklist) that is mentioned in the bounceback to get your IP address removed.
3. If the bounceback seems difficult to interpret, it's possible that you may have been
blocked because of "spam-like" characteristics in the message. There may be a line in the
bounceback that starts with X-Spam Status which can give you more information. If the
elements in that line are unfamiliar, try searching for them, or contacting the third-party
spam filter that your recipient uses for further clarification. Our Email blocked by Media
Temple spam filter article has some excellent best-practice guidelines for avoiding spam-
like characteristics in your emails.
4. Certain servers require properly-configured DomainKeys and/or an SPF record in your
zone file to accept mail from your domain. See these articles for assistance:
o DV:Create DomainKeys
o How can I create an SPF record for my domain?
5. If you're still not sure what the bounceback means, feel free to submit a support request
and include the text from the bounceback. Please note that on the DV, you are
responsible for your own mail server reputation and configuration.

Search

EMAIL TROUBLESHOOTING -
MISSING EMAILS
Browse by products and services

DV and VPS Hosting

Grid Shared Hosting

Legacy DV Hosting

 Applies to: All DV

o Difficulty: Easy
o Time Needed: 10
o Tools Required: None

Overview
This article covers several causes for missing email and links for instructions on adjusting your
spam filter (a common reason for missing emails).

Symptoms
You suddenly notice a large chunk of emails missing from your
inbox.
Likely cause: Have you recently checked your email from using POP on a computer or mobile
device other than your normal one? If so, you may have accidentally downloaded the emails to
that machine, pulling them off of the server.

Solution: Set up an IMAP account on that same device, then drag and drop the emails from the
POP inbox to the IMAP inbox. This should sync them up with the server again. Finally, disable
or reconfigure the POP inbox so it leaves a copy of each message on the server.

Folders from one email client are missing in webmail or a

second email client.
Likely cause: There are two possible causes of missing folders. The first is that your normal
email client is a POP client, and folders other than the inbox are only on your local machine -
they were never created on the server. The second is that you are using an IMAP client normally,
but you haven't subscribed to the additional folders in your webmail or new email client.
Solution:

1. Make sure the folders are actually IMAP folders. If they aren't, you may need to recreate
them in your original email client.
2. Subscribe to the additional IMAP folders in your new email client. Check your email
client's documentation for specific instructions.

Specific email(s) are never received.

Likely cause: The email may be triggering a spam filter.

Solution:

1. Check your Spam folder. If you haven't subscribed to your Spam folder locally, you can
check in webmail, at http://webmail.example.com/.
2. Check with the original sender to see if they received a bounceback. If so, take a look at
the Email troubleshooting - bouncebacks article.
3. If you can't locate the message anywhere:
o Check your mail log(s) for further insight. For instructions on how to do that,
please click here.

Emails to Yahoo or Hotmail disappear for a few days.

Likely cause: Some large mail providers implement a process called "gray listing" which delays
suspicious emails for a few days. The emails will eventually be delivered, but it may seem like
they've gone missing at first.

Solution: You should check to make sure that nothing in your email content might trigger a spam
filter. Unfortunately, without a solid bounceback, (mt) Media Temple cannot do anything
concrete about delayed email.

Spam filter settings

If you've discovered that your spam filter is either flagging desired messages, or letting spam
through, please see these articles for adjusting your spam filter settings:

Third-party hosting

If you don't host your mail through (mt) Media Temple, you will need to disable the email
service for that domain on your server. Otherwise, other domains that are hosted on that server
will try to send to your (mt) Media Temple mailbox, rather than your live third-party mailbox.
To see whether you are hosted with (mt) Media Temple or not, check your MX record settings
here:
• Email troubleshooting - new domain checklist and DNS: DNS settings and MX records

If you determine that you are hosting your email elsewhere, follow these steps to disable the mail
service for your domain:

• How do I enable or disable local mail for my domain?

EMAIL TROUBLESHOOTING -
SPAM FROM MY ADDRESS

Browse by products and services

DV and VPS Hosting

Grid Shared Hosting

Legacy DV Hosting

 Applies to: All DV

o Difficulty: Easy
o Time Needed: 10
o Tools Required: None

Overview
If you're getting a lot of bouncebacks and/or complaints that you are sending spam, one of two
things could be happening. You may be sending spam, in which case you will need to check your
server security. Or, you may be being spoofed.

Instructions
Follow these steps to identify and resolve this issue.

1. Check your email header to determine whether the spam is coming from your (mt) Media
Temple server or not.
2. Look at the very last Received: line in the header. Check the IP address or name of the server
that the message was sent from (NOT to, or "received by"). If it has the name of your server, you
may be sending spam, and this could indicate that you've been hacked. See Security resources for
further assistance. However, if the original server is an unknown server, it's likely that you are
being spoofed. i.e., someone is pretending to send emails using your email address, but they are
not coming from your server at all.

3.The best way to overcome this is to create an SPF record for your domain. This is not 100%
effective, but more and more mail servers check for an SPF record, so it should drastically
reduce the amount of spam sent out under your email address.

EMAIL TROUBLESHOOTING -
MAILBOX SIZE

Browse by products and services

DV and VPS Hosting

Grid Shared Hosting

Legacy DV Hosting

 Applies to: All DV

o Difficulty: Easy
 o Time Needed: 10
o Tools Required: SSH, root or sudo access

Overview
Having an over-full inbox can cause a variety of email problems, including slow performance,
timeouts, connection problems, and disk quota errors. Follow this article to diagnose and resolve
mailbox disk space issues.

Symptoms
Email takes a very long time to send or receive, email takes a
long time to connect, or doesn't load at all.
Likely cause: You have a very large amount of email stored in your mail account.

Solution: Remove or archive some email. See Reducing mailbox size below.

Disk Quota Exceeded error received.

Cause: You have exceeded the disk space either for this specific mail account, or for the server
as a whole.

Solution: Raise the disk space limit for the email account, upgrade your storage space, or reduce
the mailbox size.

 Disk Quota Exceeded error in email

Reducing mailbox size

The ideal size for a mailbox is 50 MB or less. However, many users will be very content with
email performance up until about 500 MB or so. At that point, or for accounts with greater than
500 MB of email, you should seriously consider removing or archiving some of the emails.
Otherwise, you will notice degraded performance for that mail account.

1. Diagnose that mailbox size is what is causing your problem.

Unfortunately, Plesk doesn't have an option to check individual mailbox size. The
simplest method to do this is as follows:

o Log into your server as a root or sudo user via SSH, then run the following
command (be sure to replace example.com with your domain name, and username
with the email user):

du -sh /var/qmail/mailnames/example.com/username/Maildir/
 2. Next, you need to access your email account. The best way to do this is to set up an
IMAP connection to the account with your favorite email program.
3. Then, delete and archive unneeded emails.

TIP:

Many email programs will let you create local folders that are stored on your computer,
rather than on the server. You can drag and drop messages from your inbox or Sent folder
on the server to your local folder instead. Then, if you ever need to reply to or forward
them, just drag them back to your inbox. Note that you should consider having a backup
option for your local computer if you do this, because the messages won't be on the
server.

4. If you can't get into your email account with IMAP, you have two options:
o Try to set up a POP account instead of IMAP. Make sure it is configured to
download your email and NOT leave a copy on the server. Note that all of your
email will now be on the machine you used for downloading, and not on the
server.

CAUTION:

The next option will delete all or some of your email, with no regard for individual
messages. Pursue these options at your own risk.

o Remove and then recreate the account on the server. You'll need to wait about
twenty minutes after removing the account before you recreate it. This will delete
all messages from all folders on the server.
5. Try to get your mailbox size down to 50 MB or less. Note that lots of small files are more
likely to slow down your email than a few large attachments.
6. When you're done, see if your email responds more quickly and/or stops giving you
errors.

Troubleshooting Mail Flow and SMTP

Topic Last Modified: 2005-05-24

Even after you have successfully configured Simple Mail Transfer Protocol (SMTP) in your
Microsoft® Exchange Server organization and taken every measure to secure it, you might
experience mail flow problems. This topic discusses many of the common problems that you
may encounter and methods to help resolve them.

Specifically, you will learn how to:

 Use Telnet
 Use the SMTP and X.400 queues
 Use Message Tracking Center
 Use Event Viewer
 Configure diagnostic logging for SMTP

However, before considering the troubleshooting recommendations in this topic, first ensure that
Exchange Server is configured correctly to send and receive mail. The lists below briefly
summarize the requirements for inbound and outbound mail to flow properly.

For incoming Internet mail to flow correctly:

 Your recipient policies must be configured correctly.

 Your SMTP virtual server that accepts Internet mail must be configured on port 25 and
allow anonymous connections.
 A mail exchanger (MX) resource record for your domain must exist on an internet DNS
server, and the MX record must point to the external or Internet domain of your mail
server.
 Your Internet mail server must be accessible to remote servers on the Internet.

For outgoing Internet mail to flow correctly:

 Your SMTP virtual server that sends Internet mail must be configured to use port 25.
 If you are using SMTP connectors, at least one connector must contain an address space
of *, which specifies all external domains.
 Your Exchange server must be able to resolve external DNS names. You can resolve
external DNS names in the following ways:
o Use an internal DNS server that forwards mail to an external DNS server.
o Configure your SMTP virtual server to use a specific external DNS server.
o Route mail to a smart host that performs DNS resolution.

For more information about how to configure Exchange Server to send and receive e-mail
messages, see Verifying DNS Design and Configuration.

For detailed information on how to use Telnet to test SMTP, see the following topic:

 How to Use Telnet to Test SMTP Communication

Using the SMTP and X.400 Queues

SMTP uses the SMTP queues to deliver mail internally and externally. Exchange Server
version 5.5 servers, MAPI clients (such as Microsoft Office Outlook®), and other mail
connectors (such as Microsoft Exchange Connector for Lotus Notes and Microsoft Exchange
Connector for Novell GroupWise) use the X.400 queues to send mail to and receive mail from
Exchange Server. The following sections explain how to use both the SMTP and X.400 queues
to troubleshoot message flow.

Understanding the SMTP Queues

During message categorization and delivery, the advanced queuing engine sends all mail through
the SMTP queues of an SMTP virtual server. If there is a problem delivering the message at any
point in the process, the message remains in the queue where the problem occurred.

Use the SMTP queues to isolate the possible causes of mail flow issues. If a queue is in a "Retry"
status, you should check the properties of the queue to determine the cause. For example, if the
queue properties display a message that is similar to "An SMTP error has occurred," you should
review your server's event logs to locate any SMTP errors. If there are no events in the log, you
should increase the SMTP Protocol logging level. For more information about how to increase
the SMTP Protocol logging level, see How to View the Application Log in Event Viewer and
How to Modify Logging Settings for MSExchangeTransport.

The following table lists the SMTP queues, including their descriptions, and troubleshooting
information for message accumulation in each queue.

Descriptions of SMTP queues and associated troubleshooting information

SMTP
Description Troubleshooting
queue
Messages can accumulate in this queue if the
Exchange server is not accepting messages for
local delivery. Slow or sporadic message
[Local Contains messages that are delivery can indicate a looping message or a
domain queued on the Exchange server performance problem.
name] (Local for local delivery to an Exchange
Delivery) mailbox or public folder store. This queue is affected by the Exchange store.
Increase diagnostic logging for the Exchange
store as described in How to Modify Logging
Settings for MSExchangeTransport.
Generally, messages accumulate in this queue
because the advanced queuing engine is unable
Contains messages to recipients to categorize the message. The advanced
that have not yet been resolved queuing engine may not be able to access the
Messages
against Microsoft Active global catalog servers and access recipient
awaiting
Directory® directory service. information, or the global catalog servers are
directory
Messages are also held here unreachable or performing slowly. Additionally
lookup
while distribution lists are the following may cause messages to
expanded. accumulate:

 Active Directory is unavailable (because

 the categorizer uses Active Directory to
categorize messages).
 Active Directory may be excessively
loaded (if many messages are queuing in
the pre-categorization queue).
 A failure in conversion. The categorizer
also handles content conversion.
 Message categorizer cannot find the
mailbox stores.
 If SMTP was reinstalled or removed,
that may invalidate the following IIS
metabase keys: /smtpsvc/DsUseCat and
/smtpsvc/vsi#/DsUseCat. Determine
whether SMTP was reinstalled or
removed.

The categorizer affects this queue. Increase

diagnostic logging for the categorizer as
described in How to Modify Logging Settings
for MSExchangeTransport.
Messages accumulate in this queue if Exchange
Holds messages until their next-
Messages Server routing problems exist. Message routing
destination server is determined,
waiting to be may be backed up. Increase diagnostic logging
and then moves them to their
routed for routing as described in How to Modify
respective link queues.
Logging Settings for MSExchangeTransport.
Remote
delivery If messages accumulate in this queue, you must
Holds messages that are destined
first identify the status of the queue. If the queue
for remote delivery. The name of
[Connector is in "Retry," check the queue properties to
the queue matches the remote
name| determine the reason it is in this state. For DNS
delivery destination, which may
issues, use Nslookup and telnet to troubleshoot.
be a connector, a server, or a
Server name| If the host is unreachable, use telnet to ensure
domain.
Remote that the remote server is responding.
domain]
Messages can accumulate in this queue if no
route exists for delivery. Additionally, any time
a connector or a remote delivery queue is
unavailable or in "Retry" for a period of time,
The final destination server for
Final and no alternate route exists to the connector or
these messages cannot be
destination remote destination, new messages queue here.
reached. For example, Exchange
currently This allows an administrator to fix the problem
cannot determine a network path
unreachable or define an alternate route. To get new
to the final destination.
messages to flow to their remote destination
queue so you can force a connection and get a
Network Monitor (Netmon) trace, restart the
SMTP virtual server.
Holds messages that have been Messages that are accumulating constantly may
Pre-
acknowledged and accepted by indicate a performance problem. Occasional
submission
the SMTP service. The peaks in performance can cause messages to
 processing of these messages has appear in this queue intermittently.
not begun.
Contains delivery status
notifications, also known as non-
delivery reports that are ready to Messages can accumulate in this queue if the
be delivered by Exchange. Microsoft Exchange Information Store service
is unavailable or not running, or if problems
DSN
Note The following operations exist with the IMAIL Exchange store
messages
are unavailable for this queue: component, which is the component that
pending
performs message conversion.
submission
 Delete All Messages (no
NDR) Check the event log for possible errors with the
 Delete All Messages Microsoft Exchange Information Store service.
(NDR)

Possible causes for failed messages are:

 Corrupted messages.
Contains messages that failed  Third-party programs or event sinks may
some type of queue submission, be interfering with message queuing or
Failed
often before any other processing fidelity.
message retry
has taken place. By default,  Low system resources could cause the
queue
messages in this queue are system to respond slowly or cause other
reprocessed in 60 minutes. performance issues. Restarting IIS may
temporarily improve resource issues, but
you should determine the root cause.

Possible causes for message accumulation are:

Contains messages that are
queued for delivery at a later
 If a message is sent to a user's mailbox
time, including messages that
while the mailbox is being moved,
were sent by older versions of
messages can queue here.
Outlook. (You can set this option
 When the user does not yet have a
on Outlook client computers.)
mailbox and no master account Security
ID (SID) exists for the user. For more
Previous versions of Outlook
information, see Microsoft Knowledge
Messages depend on the message transfer
Base article 316047, "XADM:
queued for agent (MTA) for message
Addressing Problems That Are Created
deferred delivery. Now, however, SMTP
When You Enable ADC-Generated
delivery handles message delivery, not
Accounts."
the MTA. Therefore, messages
 The message may be corrupt or the
that are sent by older versions of
recipient may not be valid.
Outlook treat deferred delivery
 To determine if a message is corrupt,
differently.
check its properties. If a message is not
accessible, it may be a corrupt message.
These messages remain in this
You can also check that the recipient is
queue until their scheduled
valid.
delivery time.
For more information about troubleshooting mail flow and SMTP, see the following topics:

 How to View the Properties of a Queue

 How to View Messages in a Queue
 How to Check the SMTP Performance Counters
 How to Enable Message Tracking Center on a Server
 How to View the Application Log in Event Viewer
 How to View the System Log in Event Viewer
 How to Modify Logging Settings for MSExchangeTransport
 How to Set Logging at the Debug Level for the SMTP Protocol
 How to Enable Logging at the Debug Level for the Message Categorizer

How to Use Telnet to Test SMTP

Communication

Topic Last Modified: 2005-05-24

Telnet is an extremely useful tool for troubleshooting issues related to SMTP and mail flow. For
example, you can use telnet to:

 Verify that SMTP is installed properly, and that it has all the necessary commands.
 Ensure that your server is accessible over the Internet.
 Attempt mail delivery directly over the TCP port.
 Determine that all servers are accepting connections.
 Determine if a firewall is blocking a connection.
 Ensure that a single user can receive mail.
 Ensure that a specific domain can receive mail.
 Ensure that a specific user or domain can send mail to your domain.

Note:
The following procedure shows you how to test the process of an internal user sending mail to a
remote user when basic authentication is required for relaying mail outside your organization.

Before You Begin

Before you perform the procedure in this topic, read Troubleshooting Mail Flow and SMTP.

The following permissions are required to perform this procedure:

 Member of the local administrators group

Procedure
To use telnet to test SMTP communication

1. Open a telnet session: From a command prompt, type telnet, and then press ENTER.
2. Type set local_echo on a computer running Microsoft Windows® 2000 Server or SET
LOCALECHO on a computer running Windows Server™ 2003 or Windows XP, and
then press ENTER. This command allows you to view the responses to the commands.

Note:
For a list of available telnet commands, type set ?.

3. Type o <your mail server domain> 25,and then press ENTER.

4. Type EHLO <your mail server domain>, and then press ENTER.
5. Type AUTH LOGIN. The server responds with an encrypted prompt for your user name.
6. Enter your user name encrypted in base 64. You can use one of several tools that are
available to encode your user name.
7. The server responds with an encrypted base 64 prompt for your password. Enter your
password encrypted in base 64.
8. Type MAIL FROM:<[email protected]>, and then press ENTER. If the sender is
not permitted to send mail, the SMTP server returns an error.
9. Type RCPT TO:<[email protected]>,and then press ENTER.If the
recipient is not a valid recipient or the server does not accept mail for this domain, the
SMTP server returns an error.
10. Type DATA.
11. If desired, type message text, press ENTER, type a period (.), and then press ENTER
again.
12. If mail is working properly, you should see a response similar to the following indicating
that mail is queued for delivery: