#
# The failure template is used when mail is returned to the sender;
# either the destination rejected the message, or the destination
# could not be reached before the message expired in the queue.
#

failure_template = <<EOF
Charset: utf-8
From: MAILER-DAEMON (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
Postmaster-Subject: Postmaster Copy: Undelivered Mail

这里是 $myhostname 邮件服务器。
This is the mail system at host $myhostname.

很抱歉通知您，你的邮件无法投递到一个或者多个地址，

如果需要更多帮助，请将此邮件转发给邮件管理员。

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system
EOF

#
# The delay template is used when mail is delayed. Note a neat trick:
# the default template displays the delay_warning_time value as hours
# by appending the _hours suffix to the parameter name; it displays
# the maximal_queue_lifetime value as days by appending the _days
# suffix.
#
# Other suffixes are: _seconds, _minutes, _weeks. There are no other
# main.cf parameters that have this special behavior.
#
# You need to adjust these suffixes (and the surrounding text) if
# you have very different settings for these time parameters.
#

delay_template = <<EOF
Charset: utf-8
From: MAILER-DAEMON (Mail Delivery System)
Subject: Delayed Mail (still being retried)
Postmaster-Subject: Postmaster Warning: Delayed Mail

这里是 $myhostname 邮件服务器。
This is the mail system at host $myhostname.

####################################################################
# 这只是一条警告信息，你不需要再次发送你的邮件 #
# THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################

你的邮件发送不成功，系统会在$maximal_queue_lifetime_days day(s)内每$delay_warning_time_hours hour(s)再次重新发送

如果需要更多帮助，请将此邮件转发给邮件管理员。
Your message could not be delivered for more than $delay_warning_time_hours hour(s).
It will be retried until it is $maximal_queue_lifetime_days day(s) old.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system
EOF

#
# The success template is used when mail is delivered to mailbox,
# when an alias or list is expanded, or when mail is delivered to a
# system that does not announce DSN support. It is an error to specify
# a Postmaster-Subject: here.
#

success_template = <<EOF
Charset: utf-8
From: MAILER-DAEMON (Mail Delivery System)
Subject: Successful Mail Delivery Report

这里是 $myhostname 邮件服务器。
This is the mail system at host $myhostname.

你的邮件已经成功投递到目标地址。
Your message was successfully delivered to the destination(s)
listed below. If the message was delivered to mailbox you will
receive no further notifications. Otherwise you may still receive
notifications of mail delivery errors from other systems.

The mail system
EOF

#
# The verify template is used for address verification (sendmail -bv
# address...). or for verbose mail delivery (sendmail -v address...).
# It is an error to specify a Postmaster-Subject: here.
#

verify_template = <<EOF
Charset: utf-8
From: MAILER-DAEMON (Mail Delivery System)
Subject: Mail Delivery Status Report

这里是 $myhostname 邮件服务器。
This is the mail system at host $myhostname.
你请求的邮件投递报告随此邮件附上。
Enclosed is the mail delivery report that you requested.

If you want to deliver 1000000 queue files in 3 hours, that is 10
milliseconds per file. That seems a bit optimistic to me, considering
the latencies of real disks (every file needs to be read from disk,
the cache is cold) and of real networks (having a local DNS server
should really make a difference).

Neither qmail nor Postfix currently has connection caching, which
can make a difference sending mail to sites that have slow servers.

0 - In the /etc/syslog.conf file, put a - in front of the maillog
filename, so that the stupid syslogd does not hammer the disk
after writing each logfile record.

1 - The default settings of two levels of directory hashing in the
queue should suffice. If you disagree, change this with:

postconf -e hash_queue_depth=3
postfix reload

2 - Configure an adequate number of delivery agents in the master.cf
file: 500+. On your typical Linux box, this will run the kernel
out of resources and Postfix will slam on the brakes until you
fix it.

3 - Test the setup with the smtp-source and smtp-sink programs.
For the test, specify a relayhost name that points to the
smtp-sink program, and send messages with thousands of recipients
into Postfix, and have Postfix perform one-recipient deliveries.

On the Postfix host:

postconf -e relayhost=smtp-sink.host:9999 \
smtp_destination_recipient_limit=1

On the mail sink host (can be same as postfix host, if you have
enough memory and process slots and space for open files):

./smtp-sink -c :9999 1000

On the smtp-source host (can be same as postfix host):

./smtp-source -c -m 1000 -s 10 -r 10000 -t foo@postfix.host postfix.host

Postfix breaks up the deliveries into transactions of 1 recipient
each, so one message with 10000 recipients will keep lots of
delivery agents busy.

4 - Before submitting the real mail:

postconf -e defer_transports=smtp relayhost= \
smtp_destination_recipient_limit=\$default_destination_recipient_limit
postfix reload

(and don't let anyone execute a "sendmail -q" command).

5 - SUBMIT THE MAIL VIA SMTP, not via /usr/sbin/sendmail. Otherwise
you are throwing away all the performance.

6 - On Doomsday,

postconf -e defer_transports=
postfix reload
sendmail -q

7 - From here on, do not touch the box. Each time you stop or reload
Postfix, or do a sendmail -q, it slows down dramatically.

Wietse

Alexander:
> (I've posted this message in QMAIL and EXIM mailing list.
> Many people say me that POSTFIX can do a good work)
>
> This is a case study and it's NOT for create a spamming system or other
> terrible mail bombing system.
> I HATE them !
>
> Title: the best mode to deliver 1.000.000 email messages (recipient are ALL
> different and email are ALL different) in few hours during a single delivery
> session.
>
> You suppose to have a SMP Linux server (i.e. dual P-III 800 Mhz, 512 MB Ram,
> SCSI Raid 5, kernel 2.4.9 and RaiserFS) and a good internet connection (4
> Mbit/sec full bandwidth) and a fast DNS server near me.
>
> During the night a program running on the same server creates 1 million of
> email (getting user data and infos data from a SQL DB).
> This process need about 3 hours. Meanwhile email are created, they are
> "injected" in MTA queue (i.e. using qmail-inject or
> exim -odq -t) and they are NOT delivered: they stay in queue.
> The email are all different but short: about 800-1000 bytes each and the
> recipients are all different and are all remote.
> Yes, we can have a vary big number of different recipient domain but
> statistically we also have a large number of email directed on mass email
> system (Hotmail, Yahoo...)
>
> So 1.000.000 x 1.000 bytes = 1 GBytes data. Yes, like a technical
> information email system with personalized info for each recipient.
>
> Then every day at 8.00 AM the remote delivery needs to start (exim -q ,
> qmail-remote) and delivery is done once per day.
>
> Target: send 1 million of email in a very short time, shortest as possibile,
> it must end as soon as possibile. Bandwidth occupation is not a problem: we
> can use all 4 Mbit/sec (about 1 GB / 500 Kbytes/sec = about 2000 seconds , 1
> hour and few minutes. 2 or 3 hours are ok anyway).
>
> And now the questions:
>
> 1) QMAIL vs EXIM vs POSTFIX: which is the best MTA to manage 1.000.000 email
> in queue ?
> (EXIM with option "split_spool_directory" and QMAIL patched to have a more
> "deep" in queue tree, POSTIFIX ??)
>
> 2) EXIM can deliver all messages during a single SMTP session to the same
> email system (useful for mass system like HOTMAIL,YAHOO, ....), QMAIL no.
> Is it faster to have either for example 300 (more or less) qmail-remote
> process running and sending 1 messages each or for example 20 (more or
> less) "exim -q" process running sending more messages in a single SMTP
> connection ? Remember: the target is to use less time than possible.
>
> Thanks for any suggestion about.
> POSTFIX ,I've never used it, can be an alternative ?
>
>
>