SMTP vs Memory

  • SMTP gateway servers use memory primarily for maintaining connections and keeping track of vital information about messages in the queues.
  • The memory used to store message properties on queued e-mail can be significant.
  • SMTP stores messages in the queue in two states:

1. opened (that it, it keeps a handle open) or

2. closed (that is, it closes the handle).

  • The maximum number of messages that an SMTP gateway queues before refusing new messages is 90,000.
  • SMTP can keep 1,000 messages in the queue open at any particular time, closing old messages as new ones arrive.
  • An open message in the queue consumes approximately 10 KB of memory in the Inetinfo process, and a closed message consumes approximately 4 KB of memory in the Inetinfo process.
  • The maximum number of messages that an SMTP gateway queues before refusing new messages is 90,000.
  • A simple calculation that explains this,

1,000 open messages = 10 MB of Inetinfo memory

1,000 open messages + 20,000 closed messages = 80 MB of Inetinfo memory

1,000 open messages + 89,000 closed messages = 366 MB of Inetinfo memory

Traffics:

  • Low-traffic SMTP gateway servers can perform adequately with 256 MB of RAM.
  • In high-traffic data centers, where large queues are common and large distribution lists are expanded, at least 512 MB of RAM is preferred.
  • Generally, an SMTP gateway server does not benefit by having more than 1 GB of memory.

Which means that at any given point of time, any Exchange server with basic configuration is capable of handling emails of any size.

Slow Mail flow?

Would the Disk bottleneck affect the mail flow?

As well all know, yes that will “affect the slow or affect” the mail flow

Reason:

Every message that is received by an SMTP gateway is saved to a disk.

  • With a default message size of 50 KB, about 7 to 8 disk writes occur for each message processed by the SMTP gateway.
  • This behavior is expected. Generally, SMTP performs 7 disk writes for every message queued that is smaller than 32 KB.
  • An SMTP gateway’s write buffer is 32 KB. Therefore, messages that are larger than 32 KB require an additional disk write for every 32 KB.

For example, a 100-KB message requires 10 disk writes to save the message in the queue.than 1 GB of memory.

it is good to run EXTRA to check the disk bottleneck and blame the “Third party” with a proof J

X:400 NDR Error when sending emails to E2K7 Server

I’ve recently come across a problem where, For Exchange 2003 and 2007 co-existence environment, When an mail-enabled object is created, the x:400 address will not be stamped.

This would result in an NDR’s with the recipient name “BsB57FD40C9308F7479BF159E9F227E5DD_

cn=E5D7F3DC762455418BB3D96C1B7C13BC@domain.edu

Reason:

This would happen because of mission X:400 address

Fix:

  • The Exchange 2003 RUS is responsible to update the object attributes in a co-exist Environment.
  • The Recipient Update Service has three System Policies that are installed by default when you install Exchange 2003. They are “Mail Enable Recipient”, “Mailbox Enable User” and “Hidden DL membership”.
  • If the recipient update service identifies than a new entry was added (or modified), and it does have the mailNickname to be considered mail-enabled.  Therefore, by default, the purportedsearch attribute should be below:

(|(&(objectCategory=person)(objectClass=user)(mailnickname=*)

(targetAddress=*))(&(objectCategory=person)(objectClass=contact)

(mailnickname=*)(targetAddress=*))(&(objectCategory=group)

(mailnickname=*))(&(objectCategory=publicFolder)(mailnickname=*)))

  • You can locate the “Mail Enable Recipient” object by using Adsiedit.msc tool:

CN=Mail Enable Recipient, CN=System Policies, CN=ORG_NAME, CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=DOMAIN_NAME,DC=com

  • The user, contact and public folder object which have mailnickname and targetaddress (not for public folder) attributes.

No-Listing

I found interesting concept somewhere in the web  to  reduce the spam that comes in to the organization.

As we all know mx record plays a major role for receiving email.  And it is also the entry point for the spam to enter into the organization.

“Nolisting” is a concept of creating more than two mx records, and setting the primary mx record to “nowhere”(ie 0.0.0.0).

As per RFC-(forgot the number), a genuine email from a genuine sender should try the secondary if the primary is not available or invalid.

Spammers won’t strain much to try to resend the email to the secondary mx record.  This way you can reduce the spam coming into your organization