跳至论坛內容
iRedMail 开源邮件服务解决方案
支持 Red Hat Enterprise Linux, CentOS, Scientific Linux, Debian, Ubuntu, FreeBSD, OpenBSD
您尚未登陆。 请选择登陆或是注册一个新账号。
热门主题 尚未回复的主题
iRedMail 技术交流 QQ 群:296792359。
Spider Email Archiver:由 iRedMail 团队开发的轻量级电子邮件归档软件。
搜索选项 页码 [ 第 148 页 共 190 页 ]
由 ZhangHuangbin 发表的主题 会员定义的搜索
搜索到的文章数 [ 第 3,676 至 3,700 则 共 4,728 则 ]
Authentication System: DomainKeys Identified Mail
Result: DKIM signature confirmed GOOD
Authentication System: Sender ID
Result: SID data confirmed GOOD
Authentication System: Sender Permitted From (SPF)
Result: SPF data confirmed GOOD
从这里看,你的 DKIM 设置应该是 OK 的。
由iredmail的文档成功将邮件服务器从qmail+vpopmail迁移到iredmail中来,在测试时发到gmail的邮件中的dkim标记是:dkim=pass,之后就一直是下面这条信息,不知是什么意思,请各位指点一下,谢谢!
dkim=neutral header.i=@example.com.cn
将完整的 DKIM 邮件头发上来看看。
OpenSSH 5.2 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.
OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.
We have also recently completed another Internet SSH usage scan, the
results of which may be found at http://www.openssh.com/usage.html
Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html
The focus of this release has been on bugfixes as the previous
openssh-5.1 release introduced many new features and made some
invasive changes.
Changes since OpenSSH 5.1
=========================
Security:
* This release changes the default cipher order to prefer the AES CTR
modes and the revised "arcfour256" mode to CBC mode ciphers that are
susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".
* This release also adds countermeasures to mitigate CPNI-957037-style
attacks against the SSH protocol's use of CBC-mode ciphers. Upon
detection of an invalid packet length or Message Authentication
Code, ssh/sshd will continue reading up to the maximum supported
packet length rather than immediately terminating the connection.
This eliminates most of the known differences in behaviour that
leaked information about the plaintext of injected data which formed
the basis of this attack. We believe that these attacks are rendered
infeasible by these changes.
New features:
* Added a -y option to ssh(1) to force logging to syslog rather than
stderr, which is useful when running daemonised (ssh -f)
* The sshd_config(5) ForceCommand directive now accepts commandline
arguments for the internal-sftp server.
* The ssh(1) ~C escape commandline now support runtime creation of
dynamic (-D) port forwards.
* Support the SOCKS4A protocol in ssh(1) dynamic (-D) forwards.
(bz#1482)
* Support remote port forwarding with a listen port of '0'. This
informs the server that it should dynamically allocate a listen
port and report it back to the client. (bz#1003)
* sshd(8) now supports setting PermitEmptyPasswords and
AllowAgentForwarding in Match blocks
Bug and documentation fixes
* Repair a ssh(1) crash introduced in openssh-5.1 when the client is
sent a zero-length banner (bz#1496)
* Due to interoperability problems with certain
broken SSH implementations, the eow@openssh.com and
no-more-sessions@openssh.com protocol extensions are now only sent
to peers that identify themselves as OpenSSH.
* Make ssh(1) send the correct channel number for
SSH2_MSG_CHANNEL_SUCCESS and SSH2_MSG_CHANNEL_FAILURE messages to
avoid triggering 'Non-public channel' error messages on sshd(8) in
openssh-5.1.
* Avoid printing 'Non-public channel' warnings in sshd(8), since the
ssh(1) has sent incorrect channel numbers since ~2004 (this reverts
a behaviour introduced in openssh-5.1).
* Avoid double-free in ssh(1) ~C escape -L handler (bz#1539)
* Correct fail-on-error behaviour in sftp(1) batchmode for remote
stat operations. (bz#1541)
* Disable nonfunctional ssh(1) ~C escape handler in multiplex slave
connections. (bz#1543)
* Avoid hang in ssh(1) when attempting to connect to a server that
has MaxSessions=0 set.
* Multiple fixes to sshd(8) configuration test (-T) mode
* Several core and portable OpenSSH bugs fixed: 1380, 1412, 1418,
1419, 1421, 1490, 1491, 1492, 1514, 1515, 1518, 1520, 1538, 1540
* Many manual page improvements.
Checksums:
==========
- SHA1 (openssh-5.2.tar.gz) = 260074ed466e95f054ac05a4406f613d08575217
- SHA1 (openssh-5.2p1.tar.gz) = 8273a0237db98179fbdc412207ff8eb14ff3d6de
Reporting Bugs:
===============
- Please read http://www.openssh.com/report.html
Security bugs should be reported directly to openssh@openssh.com
OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.
似乎是因为繁体中文翻译有问题导致的。你试着自己将它正确地翻译一遍试试?
他们都遵守标准的 IMAP 协议和 maildir 格式。
你只要管以下目录里的文件就可以了:
[*]以点开头的隐藏目录里的文件;
[*]cur, tmp,new 三个目录里的文件;
不是很清楚你的问题所在,是否可以截图做为辅助解释,或者贴邮件日志(/var/log/maillog, /var/log/dovecot.log)?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We are proud to announce the first stable release of the 2009 Q1
branch of MediaWiki, version 1.14.0.
We are also releasing MediaWiki 1.13.5. This is a maintenance release
which corrects some bugs in the installer, introduced during the hasty
security release of 1.13.4. It is not necessary to upgrade if you do
not intend on using the installer.
Thanks to our localisation community at translatewiki.net, MediaWiki
1.14.0 now has 311,000 localised interface text fragments spread
across 298 languages, that's 17% more than in 1.13.0.
MediaWiki is now using a "continuous integration" development model
with quarterly snapshot releases. The latest development code is
always kept "ready to run", and in fact runs our own sites on Wikipedia.
Release branches will continue to receive security updates for about a
year from first release, but nonessential bugfixes and feature
developments will be made on the development trunk and appear in the
next quarterly release.
Those wishing to use the latest code instead of a branch release can
obtain it from source control:
<http://www.mediawiki.org/wiki/Download_from_SVN>
Upgrade FAQ:
http://www.mediawiki.org/wiki/Manual:FAQ#Upgrading
Full release notes:
<http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_14_0/phase3/RELEASE-NOTES>
<http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_13_5/phase3/RELEASE-NOTES>
**********************************************************************
MEDIAWIKI 1.14.0
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.14/mediawiki-1.14.0.tar.gz
Patch to previous version (1.14.0rc1), without interface text:
http://download.wikimedia.org/mediawiki/1.14/mediawiki-1.14.0.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.14/mediawiki-i18n-1.14.0.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.14/mediawiki-1.14.0.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.14/mediawiki-1.14.0.patch.gz.sig
http://download.wikimedia.org/mediawiki/1.14/mediawiki-i18n-1.14.0.patch.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
**********************************************************************
MEDIAWIKI 1.13.5
**********************************************************************
Download:
http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.5.tar.gz
Patch to previous version (1.13.4), without interface text:
http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.5.patch.gz
Interface text changes:
http://download.wikimedia.org/mediawiki/1.13/mediawiki-i18n-1.13.5.patch.gz
GPG signatures:
http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.5.tar.gz.sig
http://download.wikimedia.org/mediawiki/1.13/mediawiki-1.13.5.patch.gz.sig
http://download.wikimedia.org/mediawiki/1.13/mediawiki-i18n-1.13.5.patch.gz.sig
Public keys:
https://secure.wikimedia.org/keys.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmhN3EACgkQ8F4kYQ4+MpMbYQCgmf6RwCUEo9RRw3hfzNz15B+a
MT0An1BqeA6wUOQnIFZJ4mRBjJJw37Gc
=ac1p
-----END PGP SIGNATURE-----
_______________________________________________
MediaWiki announcements mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce
贴一下 /etc/cron.daily/makewhatis.cron 的内容。
另外,我的没发现有问题,你看看这个文件属于哪个包,看是否可以将这个文件替换一下。
暂时没有自动化升级的办法,唯一的办法是找到问题所在,然后解决它。
另,你可以考虑自己安装一个最精简的 CentOS 5.x,然后下载 0.3.3-beta2 版本的 iRedMail,按照安装指南进行安装。
0.3.3-beta2:http://iredmail.googlecode.com/files/iR … a2.tar.bz2
安装指南:http://www.iredmail.org/wiki/index.php/ … tion_Guide
iRedMail 一直都用 Dovecot 的 SASL 认证。提问前请先搜索一下论坛。
两封邮件里的 From 和 Return-path 都是一致的。
看看是否经过传真机之后就改变了。
被拒收的邮件是退回到 Return-path 里的地址的,不是退到 From 里的地址。
原帖由 tiangangnet 于 2009-2-21 10:40 发表
是不是 Return-path 应该 和From 地址是一样的?
是的。
许多垃圾邮件就是这样伪造的,他发邮件用 user@example.com 这个账号发送,但是 Return-path 地址却写 postmaster@domain.ltd,如果被退信,是退到 postmaster@domain.ltd 去,导致 domain.ltd 受影响。
试想一下,如果你就是 domain.ltd,无缘无故收到一堆退信,你啥想法?
另外,请问一下:
由于上面的邮箱地址是依靠邮件的标题处理传真的,所有我去掉了{SPAM}标记.但是其他用户就分不出来了.
请问我该怎么办呢?有没有针对特殊地址进行处理的方法,还有能不能把垃圾邮件直接投递到[垃圾邮件]里呢?
iRedMail 使用 Dovecot-sieve 来处理邮件过滤,默认的全局过滤脚本的位置是 /home/vmail/.dovecot.sieve(请根据 /etc/dovecot.conf 里的 sieve_global_path 变量的值来确定),iRedMail 提供了模板文件,你可以下载后改名为 /home/vmail/.dovecot.sieve 就可以了:
# wget -O /home/vmail/.dovecot.sieve http://iredmail.googlecode.com/svn/trunk/iRedMail/samples/dovecot.sieve
# chown vmail:vmail /home/vmail/.dovecot.sieve
# chmod 0500 /home/vmail/.dovecot.sieve
出于安全考虑,iRedMail 默认禁止用户以 user@ 登录,但是却将邮件的 Return-path 改为 other@,因为这样有可能导致你的邮件系统被当做垃圾邮件中转站。你的问题就是由于这个导致的。
要解决这个问题,除了让对方不要修改 return-path 的邮件地址之外(这是推荐做法,因为没有理由修改或冒充),还有一个方法是你放宽限制,去掉 postfix main.cf 里的这个参数:
smtpd_sender_restrictions = permit_mynetworks, reject_sender_login_mismatch
去掉这里的 reject_sender_login_mismatch 即可。
注意:我已经说了,你的合法用户可以通过这样的方式将你的邮件系统当成垃圾邮件中转站,请自行考虑风险。
原帖由 tiangangnet 于 2009-2-20 21:20 发表
上面是我的邮件的一段日志.第一行的
Feb 20 18:27:58 mail amavis[3175]: (03175-08) Passed SPAM,
Passed SPAM 是不是判为垃圾邮件后在交给用户?
那 另一端有 Passed SPAMMY 又当什么讲呢?
是的,识别为垃圾邮件,但是仍然投递到用户的邮箱里了。
另外,我 将/etc/amavisd.conf 中的
sa_spam_subject_tag = "[SPAM] ";
改为了
$sa_spam_subject_tag ="";
请问是否会影响垃圾邮件的分类?
垃圾邮件的分类是通过邮件头里是否有 X-Spam-Flag 或 X-Spam-Status 来分辨的,如果是以下的邮件头,表示是垃圾邮件:
在邮件标题里加 [SPAM] 只是为了让用户更容易区分垃圾邮件而已。
roundcube 目前有多个 managesieve 插件可以使用。
google 一下就有:roundcube managesieve plugin
按照 RFC 规定,如果邮件主题、收件人、发件人都是英文字符(ascii),可以不使用 base64 进行 encode 处理。但如果包含有非 ascii 字符,必须使用 base64 encode 处理,而邮件客户端程序则使用 base64 进行 decode 处理,可以得到正确的内容,不会乱码。
处理过的内容类似你贴出来的那个正常的 Subject:
Subject: =?GB2312?B?c2FsZXMgyMvOxLuotcCjrNL9wey/qrS0xPq1xNXm0NTH6Q==?=
很明显,encode 处理过的内容会包含字符集(这里是 GB2312)。
所以,这是发邮件的那一方有问题,而不是你用的 Roundcube。
Am i clear?
原帖由 i659 于 2009-2-20 18:08 发表
所以我提议两方统一一下schema
各自按照自己的目标设计 schema,目前似乎没有统一 schema 的可能。
试试不要直接复制,而是用 imapsync 这类软件来同步邮件看看。
搜索到的文章数 [ 第 3,676 至 3,700 则 共 4,728 则 ]
页面生成时间 0.181 秒, 共执行查询 39 条