Weblogs for Dimon
#2
Posted by Dimon on Tue 15 May 2007 at 09:16
I'm using postfix (2.3.7 on debian sarge) as my smtp server with tls
encryption and plain authentication.
However, the mail sent to some domains is returned with the
"Considered UNSOLICITED BULK EMAIL" message. It seems to happen
because my original IP that is recorder into the first Received header
hasn't corresponding dns record.
Return-Path: <user@domain.com>
Received: from domain.com (domain.com [xxx.xxx.xxx.xxx])
by mail.somesite.ru (Postfix) with ESMTP id 056107E82B
for <user@somesite.ru>; Tue, 15 May 2007 12:35:38 +0700 (OMSST)
Received: from localhost (localhost [127.0.0.1])
by domain.com (Postfix) with ESMTP id 1E7F011201DA
for <user@somesite.ru>; Tue, 15 May 2007 12:35:56 +0700 (NOVST)
X-Virus-Scanned: Debian amavisd-new at domain.com
Received: from domain.com ([127.0.0.1])
by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1GYG1hdCuSdR for <user@somesite.ru>;
Tue, 15 May 2007 12:35:53 +0700 (NOVST)
Received: from user (unknown [xx.xx.xx.xx])
by domain.com (Postfix) with ESMTP id E0F4911201A6
for <user@somesite.ru>; Tue, 15 May 2007 12:35:52 +0700 (NOVST)
(I replaced my hostname with domain.com, it's ip with xxx.xxx.xxx.xxx;
my email with user@domain.com, my original ip with xx.xx.xx.xx and
recipient email with user@somesite.com)
So as it's written in the bounced email:
First upstream SMTP client IP address: [xxx.xxx.xxx.xxx] domain.com
According to a 'Received:' trace, the message originated at: [xx.xx.xx.xx],
user (unknown [xx.xx.xx.xx])
The question is: is there any way to skip adding first Received: header;
the best will be if it will be looking like I'm sending emails
directly from the domain.com server? I found something that seems to
be related to this configuration but couldn't point out right way to
do this this.
encryption and plain authentication.
However, the mail sent to some domains is returned with the
"Considered UNSOLICITED BULK EMAIL" message. It seems to happen
because my original IP that is recorder into the first Received header
hasn't corresponding dns record.
Return-Path: <user@domain.com>
Received: from domain.com (domain.com [xxx.xxx.xxx.xxx])
by mail.somesite.ru (Postfix) with ESMTP id 056107E82B
for <user@somesite.ru>; Tue, 15 May 2007 12:35:38 +0700 (OMSST)
Received: from localhost (localhost [127.0.0.1])
by domain.com (Postfix) with ESMTP id 1E7F011201DA
for <user@somesite.ru>; Tue, 15 May 2007 12:35:56 +0700 (NOVST)
X-Virus-Scanned: Debian amavisd-new at domain.com
Received: from domain.com ([127.0.0.1])
by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 1GYG1hdCuSdR for <user@somesite.ru>;
Tue, 15 May 2007 12:35:53 +0700 (NOVST)
Received: from user (unknown [xx.xx.xx.xx])
by domain.com (Postfix) with ESMTP id E0F4911201A6
for <user@somesite.ru>; Tue, 15 May 2007 12:35:52 +0700 (NOVST)
(I replaced my hostname with domain.com, it's ip with xxx.xxx.xxx.xxx;
my email with user@domain.com, my original ip with xx.xx.xx.xx and
recipient email with user@somesite.com)
So as it's written in the bounced email:
First upstream SMTP client IP address: [xxx.xxx.xxx.xxx] domain.com
According to a 'Received:' trace, the message originated at: [xx.xx.xx.xx],
user (unknown [xx.xx.xx.xx])
The question is: is there any way to skip adding first Received: header;
the best will be if it will be looking like I'm sending emails
directly from the domain.com server? I found something that seems to
be related to this configuration but couldn't point out right way to
do this this.
#1
Posted by Dimon on Sun 18 Mar 2007 at 11:30
I'm using Debian 3.1 with 2.6.8-2-386 kernel and experience the following problem: my /dev/null permissions are 0600; if I set permissions to correct 666, something is changing them back to 0600 after some time :(
Is it some process that changes /dev/null permissions?? I don't run any 'unusual' program, just a basic set like apache, exim4, imapd etc
Is it some process that changes /dev/null permissions?? I don't run any 'unusual' program, just a basic set like apache, exim4, imapd etc