Why the check user patch?

From Qmailwiki
Jump to: navigation, search

The stock qmail source code treats incoming email on the domain level when deciding to accept the mail. This results in server inefficencies. In some servers this inefficency can be enough to heavily load the system and cause additional problems, like all the phones ringing for support.

The solution is to treat incoming email on the user and domain levels and to reject email for invalid accounts during the SMTP conversation.

This may become clear with this example of an email delivery using the smtp protocol.

  • 'sender connects to qmail server'
  • qmail sends: 220 hostname ESMTP
  • 'HELO hostname'
  • 250 hostname
  • 'MAIL FROM: <postmaster@example.com>'
  • 250 ok
  • 'RCPT TO: <baduser@test.com>'
  • 550 sorry, no mailbox here by that name (#5.1.1 - chkusr)

The email is rejected at this point. So we save

  • receiving bandwidth for the body of the email
  • qmail disk i/o
  • local delivery and user validation
  • bounce processing
  • transmission bandwidth of the bounce
  • queue space
  • possible redelivery attempts (this is the killer)

What usually tips off the system administrator is the queue size. It will grow to hold the repeated bounce delivery attempts to phony senders. By default qmail attempts to deliver the bounces for seven days. We ususally turn this down to three days. But even this is not enough sometimes.

Usually a medium email server will have about 500 or less emails in the queue from real users to other real users that can't be delivered at the moment for some reason. Some of these resons will be typo's on email addresses and some will be because the remote site is having problems.

So if your queue is say, 74,000, it means your email server could benefit from the efficencies of having the qmail-smtpd server treat emails on the user and domain levels. Not just on the domain level.

One solution: The check user patch.

... More to come ...

Personal tools