服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

Exim邮件列表与远程收件人

前提(虚构的名字) foo是一个外部域,其中MTA不在我的控制之下; @foo SPF设置,使mine服务器不能发送电子邮件作为@foo ; bar是另一个外部领域,其中的MTA也是我无法控制的; bar做SPF检查传入的邮件拒绝明确的失败(RFCbuild议和惯例); mine是一个本地域 ,其中MTA是我正在configuration的exim,它已经工作了好几年了,但是现在我们才注意到了一个不正常的行为。 List <list@mine>是Bob <bob@foo>是其成员的邮件列表 (注意:这也可能是一个“转发地址”,但用列表来思考它更简单)。 list@mine成员存储在一个mysql 数据库中 ,这个数据库是在别处pipe理的(这意味着它不是一个静态列表)。 Alice <alice@bar>想要发送一封电子邮件到 List <list@mine> 。 我需要的 简洁版本 如何configuration(无需重新编译)exim,以便Alice可以发送电子邮件到List将被redirect到Bob 。 长版 对于发件人是@mine或所有接收者都是@mine的情况,这种configuration已经工作了好几年了。 有了这样的configuration: open_lists: driver = redirect data = ${lookup mysql{…}}} forbid_pipe forbid_file no_more 什么不起作用 :发送者和接收者都是外部的情况。 为什么 :出于某种原因(这是我所说的不当行为),exim保留了原始的信封发件人 (又名邮件来自每个RFC),这是由于SPF失败而拒绝的。 我意识到SRS及其在exim上的实验性实施 。 然而,除了实验,它需要重新编译启用。 如果有一个更新的Ubuntu编译包准备好了,但是我还没有find一个。 我也知道exim的重写有一个标志F来改变信封发送者(From),但是这个标志不能和headers_rewrite一起使用。 它只在重写部分可用。 基本上我正在寻找一种方法来解决在这种情况下,希望是list@mine的信封发件人 ,通过重写或SRS,它只能维护。

由ansible创build的文件似乎具有损坏的权限

问题与Ansible创build的文件 我正在使用在新的ISP上设置一些新的服务器,我一直在做一些基本的testing步骤。 我是新的,但已经在另一个ISP的差异服务器上做了一些testing,似乎没有问题(我创build的文件没有问题)。 两者都是Unbuntu 12,但原来的testing已经在一个服务器上,它的内核已经更新到3.8.0-44-通用和其他maint补充。 这个新的服务器也是Ubuntu 12,但是来自ISP模板,并且使用Kernel 3.5(Ubuntu 12.04.2 LTS(GNU / Linux 3.5.0-23-generic x86_64)) 我的第一个testing是创build新用户并上传他们已经存在的SSH密钥以供将来login。 用户创build没有问题,文件创build在创build过程中没有提供任何错误的迹象,但是当我尝试使用它们时。 我尝试login(新用户)_使用密钥,但系统的行为就好像SSH密钥文件不存在。 因为这是我第一个以root身份login的新用户,并以root身份进行了第一次查看和创build 作为根一切看起来不错。 .ssh目录中的文件“authorized_keys”存在并且似乎具有正确的权限,并且具有正确的内容。 但是试图通过SSHlogin就好像它不在那里一样。 我从rootlogin并以新用户身份重新login(使用密码,因为密钥未被识别)。 我做了一个“ls -al”,并且看到.ssh目录,但是通过“ls -al .ssh”查看目录中的“authorized_keys”文件给了我一个非常奇怪的结果。 'ls'为目录中的每个项目输出“Permission denied”错误消息,然后显示应该是命令结果的内容,但是文件名是可见的,其他所有内容(权限,文件大小,用户/组,date)是取而代之的是问号。 首先作为用户 – myusername myusername@my-server:~$ ls -al .ssh ls: cannot access .ssh/authorized_keys: Permission denied ls: cannot access .ssh/..: Permission denied ls: cannot access .ssh/.: Permission denied total 0 […]