> From: Jakob Hirsch
> To: dcc@???
> Cc: exim-dev@???
> > "IPv6:" tag. That NANOG thread seems to say that exim generates
> > Received: from s0.nanog.org (s0.nanog.org [2001:48a8:6880:95::20]) ...
> uhm... yes, that's true:
> Received: from calcite.rhyolite.com ([2001:4978:230::3]:30997)
> by ymmv.de with esmtps (TLSv1:AES256-SHA:256)
> (Exim 4.72)
> I (and obviously others) wasn't aware that should be a "IPv6:" prefix.
> Which "SMTP standards" say that?
Section 4.1.3 in RFC 5321 and section 4.1.3 in RFC 2821 are clear and
unambiguous about the form of IPv6 address literals.
Page 52 in Section 4.3.2 of RFC 2821 defines "TCP-info" in Received:
headers with "Address-literal". Page 60 in RFC 5321 says the same.
Daniel Mezentsev pointed out
http://www.mail-archive.com/exim-users@exim.org/msg03620.html
That seems to concern an exim bug parsing address literals in SMTP HELO
commands offered by SMTP clients (mail senders).
> Parsing Received headers is always dodgy, because it was never intented
> to be machine readable.
> The Right Way[tm] to do this is to tell the MTA to add a header line
> (X-Sender-IP or something).
The classic sendmail Received: header is easily parsed. Perhaps
it would be better if there were a standardized header carrying the
HELO string, SMTP client IP address, and client host name, along
with rules about when an SMTP relay should replace an existing
header, but there aren't.
In any case, even after exim is fixed, there might be DCC+exim
sites that use old exim versions and that don't tell dccifd or dccproc
the SMTP client IP addresss, name, or the HELO string,
or that are inside whitelisted mail forwarders and so need to look past
what the local MTA saw. So I do need to change the DCC code.
thanks,
Vernon Schryver vjs@???
