Re: sendmail, masquerading and HELO
Richard A Nelson (cowboy@debian.org) wrote on 21 May 2002 11:26:
>You do know why the Received lines are there right?
I thought I knew but after this remark I'm no longer sure :-)
>> What's annoying is that some sites are using the helo= field to check
>> the IP address via dns. Since in this case it's an internal addres
>> it'll obviously not work, and these sites are refusing to receive
>> email from us.
>
>Such sites are broken - apply cluex4 repeatedly until they understand
>that they are to verify *ONLY* the sending MTA... And they *HAVE* its
>IP, they check forward/reverse resolution on it, and only it.
I think I wasn't clear, sorry. In the headers below
>On Tue, 21 May 2002, Carlos Carvalho wrote:
>> The problem is that sendmail puts in the headers the internal host
>> name, as you can see from this message itself and here is another
>> example:
>>
>> Received: from fisica.ufpr.br ([200.17.209.129] helo=hoggar.fisica.ufpr.br)
>> **************************
>> by foo.bar.ufpr.br with esmtp (Exim 3.35 #1 (Debian))
>> id 17A8E9-0001mj-00
>> for <carlos@bar.ufpr.br>; Tue, 21 May 2002 08:54:53 -0300
>> Received: (from carlos@localhost)
>> by hoggar.fisica.ufpr.br (8.11.2/8.11.2/Debian 8.11.2-1)
>> ************************
the sending MTA is hoggar.fisica.ufpr.br, and that's what they're
trying to test. foo.bar.ufpr.br is the receiving MTA. So I think
they're doing right. I'm trying to stop hoggar's sendmail from telling
the world its hostname, and only announce its domain name.
>> Is there a way to make sendmail put the domain name in the helo field
>> and all the received headers?
>
>If you have administrative control over *all* boxen, yes - you can
>define your own Received: header format... I don't know if I had
>the file in 8.11.2, but in 8.12.3, check
>/usr/share/sendmail/cf/hack/virthost_by_ip.m4 for an example.
I don't think this is a problem of the header format, it's a problem
of the transmitted information. The Received: header format is up to
the receiving MTA, what ends up there is a problem of the sending MTA,
and this is what I'm trying to do.
--
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: