-----BEGIN PGP SIGNED MESSAGE-----
On Feb 29, 2004, at 11:32 AM, Alex van den Bogaerdt wrote:
On Sun, Feb 29, 2004 at 10:59:14AM -0500, Theo Schlossnagle wrote:
4.1.4 Order of Commands
[Paragraph 6]
An SMTP server MAY verify that the domain name parameter in the
EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about
verification
failure is for logging and tracing only.
Note the MUST NOT actually means a lot here. I personally think it
should be a "SHOULD NOT", but I didn't write the scripture. So,
adding
this into SPF would make SPF explicitly break RFC 2821 which I don't
believe it currently does.
This section forbids to reject messages when hostname->IP->hostname
does
not match. For instance, multi-homed hosts could use the name
associated
with one interface while connecting to you using another interface.
The section does _NOT_ forbid you to reject period.
You're right, I think I misinterpreted it a bit. But, it says nothing
about hostname->IP->hostname. It says "correspond" and that is seems
open to interpretation to me. As the rest of the RFC is very clear,
and this doesn't spell out a typical "paranoid IP check" I interpreted
it to mean: you can do checking, but the results of said checks should
just show up only the logs or the trace headers.
When it says: "the information about verification failure is for
logging and tracing only" lead me to believe that the "failure to
verify" will be evident in the trace headers as what we are discussing
here as a "spoofed ehlo". In other words, the failure to verify (do to
a broken EHLO or a spoofed one) would just be evident to an educated
reader in the trace headers.
I agree that you could reject the parameter to EHLO based on an
SPF-style TXT record lookup for the domain used as an argument. But it
doesn't buy you anything as I see it. You are ultimately attempting to
keep it out of the Received headers path, but the spoofing (or one like
it) could have been easily inserted into the current RFC2822 payload
already by the sender.
Maybe someone can explain to me why this is an issue at all. If we are
in here mucking with the MTA anyway (for SPF) why don't we just mandate
that the MTA does away with putting the domain in the Received header
like that. It seems to me (looking at the ABNF for trace headers in
RFC 2821) that we could be completely compliant by _always_ using the
IP address that connected:
On page 51, we see:
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
Why not just always use the last alternative form when _generating_
Received headers? It is compliant and does not expose whatever crap
(be it legitimate, spoofed, or just junk) that the remote client put as
an argument to EHLO. You still have the problem of pre-existing trace
headers being "spoofed", but that is simply unsolvable by looking at
the EHLO argument in the current session.
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Postal Engine -- http://www.postalengine.com/
// Ecelerity: fastest MTA on Earth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)
iQEVAwUBQEJU3lwyh8czExtlAQEbEgf+K7MnhpM9NOGY+SgmKlRVm4dDwZo2LtIe
xFY7V1mZYP4kYqgSMpYczkWkQiaX4l/wzLs60lL5sRD4ABVki1hSFjeJkHizdx97
LPpxcP6hkcjQ4y0dxl0kdRUILcD+SJBdkABBEVSKci/lmrkUUa5CQJF4yMrE/VJM
FHOca9U38uMXBKsT3dW0BEfafv69tbTKPoC4Q0JnUtmcZYFUAwJc3ZwADyEV/Wa0
jdzhZmAOtPZ4xeVrF6RPZ89CiWddHzdGq2HrXtZbtl3S5s1D8CCC+hDnjscTDIrg
V5Fh2nm+PmG5G38M1BEDyl/+oBM27ZcD2J95RZMfVMMUwVP0eoDqtQ==
=vrtm
-----END PGP SIGNATURE-----