On 2010-09-16 at 14:00 -0400, W B Hacker wrote:
> No: It won't make a change in the case I cited. Check the full headers of this
> post. It is tahini adding that last header that ID's my server by Exim version
> (and OS). (tahini is running Exim 4.72 and AFAIK on Linux, not BSD)
>
> I don't control tahini, and would not alter that line (at tahini) if I did do.
>
> Maybe: We are all looking in the wrong place.
>
> - telnet will show my smtp greeting banner as bland
>
> - tahini sees the full info anyway
>
> - Ergo, I suspect it is my 'outbound' handshake when submitting TO tahini that
> is providing the info.
No, this is not what's happening. Let's look at the headers of the mail
I'm replying to:
Received: from conducive.org ([203.194.153.81]:49599)
by tahini.csx.cam.ac.uk with esmtp (Exim 4.72)
(envelope-from <wbh@???>) id 1OwIki-0004g0-IU
for exim-users@???; Thu, 16 Sep 2010 19:00:10 +0100
Received: from pool-108-56-164-186.washdc.fios.verizon.net
([108.56.164.186]:51515 helo=pb.local)
by conducive.net with esmtpsa (SSLv3:AES256-SHA:256)
(Exim 4.69 (FreeBSD)) (envelope-from <wbh@???>)
id 1OwIke-000Bto-FO
for exim-users@???; Thu, 16 Sep 2010 18:00:05 +0000
The second header was added first, by your system, and shows that you
used authenticated SMTP/TLS to submit the mail from your Verizon FiOS
connection in the Washington DC area of the USA (derived from the
reverse DNS provided by your ISP). Your client is violating the HELO
part of the standard by sending "pb.local". Fortunately, you're sending
this to a server under your control so can exempt it, which is very wise
when dealing with MUAs that often have strange ideas of what's
appropriate to put into SMTP transactions.
Your server is claiming to be running Exim 4.69 on FreeBSD.
You then send on to Tahini, since this copy was received via the
mailing-list recipient, which is running Exim 4.72. Tahini received the
mail approximately 5 seconds after you sent it, assuming synchronised
clocks, which leads me to suspect that you are dropping ident traffic
instead of returning RST so that the mail was only received after timing
out on the ident check against the sending server. This is speculation,
not fact.
The only trace of the version of your MTA here is from the Received:
header which your MTA added. The MTA-MTA traffic did not involve your
MTA advertising its own version.
On the debate of version numbers: my own server tends to not reveal
this, because I'm willing to accept that I have to debug my own problems
as a result of choosing to not reveal this data. I have reason to
believe that I'm capable of doing so. The default reveals version
numbers and this is good, as it helps with diagnosis. Those who have
pointed out that attackers don't trust claimed version numbers are
making claims which match my understanding of what happens, but my
understanding is only based on third-hand information.
My own server uses a greeting banner of the form:
220 smtp.spodhuis.org ESMTP - NO UCE NO UBE 2010-09-17 04:14:44 (UTC)
delayed by a few seconds, when on port 25. For MTA-MTA traffic, I think
it appropriate to break the broken clients that are uniformly spammers.
I do not impose a delay on the submission port. Key points from the
banner:
* ESMTP for the remote clients that look for this to trigger use of
EHLO
* "NO UCE NO UBE" -- not because I expect this to be honoured, but so
that the "i"s are dotted and the "t"s are crossed and to be acting in
good faith accordance with whichever piece of legislation it was that
suggested this to keep away spam (I forget which). Perhaps one day
it will help in a class action suit ...
* The time, which might theoretically help an attacker by exposing the
clock information, which weakens the pseudo-security of anything
which is seeding randomness of the clock and believing this to be
sufficient as a security measure. In practice, it means that others
can confirm the sync of my clock and helps others to diagnose
problems interoperating with my system.
I also strip down received_header_text; for instance, if the session is
authenticated, then the Exim message-id in my Received: header will be
sufficient to identify the account in use by correlating with logs. I
don't care if the format of my Received: header causes my mails to be
marked by some others as spam -- it's everyone's right to make such
decisions, for themselves, as they see fit and if someone has decided
that restricting header text to only match the common cases somehow
helps them, that's their call to make. I think it unwise and it won't
keep me from setting received_header_text.
Thus:
timezone = UTC
smtp_banner = "${smtp_active_hostname} ESMTP - NO UCE NO UBE ${tod_log} (UTC)"
# We don't want software or version
# We don't want the intended recipient
# We don't want the sender_ident
# We don't want to leak HELO from internal networks with Thunderbird using
# its local IP as HELO, so we trim the results further for authenticated.
received_header_text = "Received: \
${if def:authenticated_id {from authenticated user }{\
${if def:sender_rcvhost {from $sender_rcvhost\
${if def:sender_helo_name { (helo=$sender_helo_name)}}\n\t}}}}\
by ${primary_hostname} \
${if def:received_protocol {with $received_protocol}} \
${if def:tls_cipher {($tls_cipher)}}\
\n\tid $message_exim_id"
If you use these, you should be very sure of your ability to debug mail
problems with minimal assistance from others.
Regards,
-Phil
