Help Us

我们会继续保持 iRedMail 完全开源(Full Open Source)，为大家提供 强大而完善的邮件服务解决方案。并且努力营造活跃而有效率的社区，为大家提供友好的交流平台。但是，iRedMail 也需要您的支持和帮助。

如果您觉得 iRedMail 不错，希望您能通过以下途径帮助我们：

    * 告诉您的朋友，iRedMail 是什么，有什么功能和特性；
    * 在您的博客(Blog)上发布关于 iRedMail 的信息；
    * 向需要邮件服务器的网友推荐他们尝试 iRedMail；
    * 在您常去的论坛的邮件服务相关版块发布关于 iRedMail 的介绍和功能特性等信息； 

感谢您的帮助和支持，iRedMail 因为有你们的帮助才能够更完善。

Introduction

iRedMail，中文名为“艾瑞得邮件”，由 rhms 项目 更名而来。是针对 Red Hat(R) Enterprise Linux 和 CentOS 设计的邮件服务器解决方案，是在操作系统安装好后使用的一套 shell 脚本，用于快速部署一套功能完善的邮件服务器解决方案。

iRedMail 的主要特色及功能：
轻松、快速部署

    * 1分钟内即可完成安装与配置。 

支持多平台、多版本

    * 支持 i386, x86_64 平台。
    * 支持 Red Hat Enterprise Linux/CentOS 5.0 ~ 5.2 版本。 

安全传输

    * 为 Web 访问提供了 TLS/SSL 加密支持，有效保障您的信息安全；
    * 提供 SMTP，SMTPS 服务，为您发送的邮件提供加密支持，有效保障您的信息安全。
    * 提供 POP3，POP3S，IMAP，IMAPS 服务。您的用户可以使用 OutLook?, Foxmail, Thunderbird 等邮件客户端收发邮件，并且可以选择是否使用加密传输以保证信息安全；
    * 灵活的邮件备份与监控机制。可以监控、备份单个用户收发的邮件，也可以对整个域的用户进行监控和备份。 

有效抵挡垃圾邮件

    * 使用 SPF 技术识别邮件来源，有效防止假冒邮件。
    * 使用 DKIM 签名和校验技术。
          o 有效保证您的邮件顺利抵达收件人，并且收件方可以准确识别您的邮件，有效防止邮件被拒收等问题。
          o 有效验证接收到的邮件是否缺失来自发件的域，有效防止垃圾邮件、假冒邮件。 
    * 使用灰名单(greylist)技术，有效抵挡垃圾邮件。有许多系统管理员反馈，使用了灰名单技术后，垃圾邮件减少了 80% - 99%。
    * 黑、白名单技术。
    * 灵活的邮件收发控制。
    * 灵活的邮件收发频率控制。例如，限制某用户在一分钟内最多只能发送或接收 5 封邮件。
    * 灵活的邮件收发总容量控制。例如，限制某用户在一分钟内最多只能发送或接收 10M 的邮件。 

有效的病毒防护机制

    * 使用强大的开源查杀毒引擎 ClamAV 为您的邮件提供病毒查杀服务，并且定期更新病毒库，以保障您的邮件安全。 

Web Mail

    * 提供基于 AJAX 技术的 Web Mail 程序，易于操作，性能优异，速度快。也为您的移动办公提供极大的便利。
    * 您还可以选择其它 Web Mail 程序：
          o ExtMail?
          o Horde WebMail?
          o SquirrelMail? 

灵活的用户策略控制

    * 灵活的邮件收发控制。您可以实现以下策略：
          o 只能收，不能发。
          o 只能发，不能收。
          o 不能使用 POP3 服务；
          o 不能使用 IMAP 服务。 
    * 灵活的单封邮件大小控制；您可以为您的 Boss 设置单封邮件的大小为 20M，30M 等，而其他用户则只能是 10M。
    * 灵活的收件控制。用户可以屏蔽某个域的所有邮件，但允许接收其中某个用户的邮件。 

管理选项

    * 无限量的虚拟域和虚拟用户。
    * 为管理员提供了方便易用的管理后台，进行域、用户的添加删除等日常管理工作；
    * 详细的邮件流量分析。以图表的形式为您呈现邮件服务器的活动状况。 

您的任何意见和反馈对我们而言都是宝贵的，欢迎您下载使用，衷心希望能够帮助大家在 RHEL/CentOS 平台快速搭建好功能完备的邮件服务器。

Document

    * 完整的搭建过程
    * Bug 反馈 

您的任何意见和反馈对我们而言都是宝贵的，欢迎您下载测试，衷心希望能够帮助大家 在 RHEL/CentOS 平台快速搭建好功能完备的邮件服务器。

Services

    * 成功案例 

希望大家能够理解和支持我的做法：

    虽然我开发了 iRedMail，撰写了详细的实施文档，但是我没有义务为 iRedMail 提供技术支持。是否使用这套邮件服务器方案完全取决于您自己。所以 请允许我在此以个人身份提供 有偿 的邮件服务器搭建、迁移等技术 支持服务，欢迎您联系和咨询。 

服务器系统包括：

    * RHEL/CentOS
    * OpenBSD
    * FreeBSD 

另外，如果您在使用 iRedMail 时碰到以下情况，欢迎您联系我们，我们会尽力为您解决：

    * 使用 iRedMail 有困难
    * 对 iRedMail 有建议和意见
    * 发现 iRedMail 的 bug
    * 某些软件包版本太低 

Contact Us

联系方式：

姓名     E-Mail
张煌彬     michaelbibby <at> gmail.com

Community

iRedMail 及 Postfix 邮件服务器相关技术交流群：
论坛     http://www.osspinc.com/bbs/
MSN 群     msngroup7176 <at> hotmail.com
Google Talk 群     iredmailbot <at> gmail.com 加它为好友即可
邮件列表（技术支持）     http://groups.google.com/group/iredmail

注：
    邮件列表是我们为已经实际部署了 iRedMail 的系统管理员准备的。 所有软件包的更新、升级信息，详细的升级步骤都会发表在邮件列表里。 

List:       postfix-users
Subject:    Re: 1.000.000 email posted in a single delivery process
From:       wietse () porcupine ! org (Wietse Venema)
Date:       2001-09-26 21:14:15
[Download message RAW]

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 ?
> 
> 
> 

-
To unsubscribe, send mail to majordomo@postfix.org with content
(not subject): unsubscribe postfix-users