----- Original Message -----
From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Monday, July 04, 2005 1:01 PM
Subject: Re: Bounce/System Notification Address Verification
Again, another RFC violation because its not support to be your domain
there
with my machine as the client.
No. See RFC 2505 section 2.6 (and subsections). There are reasons
why BCP 30 saya that an MTA MUST NOT reject based on MAIL FROM being
within the server's local domain.
You believe you might have misunderstood the RFC 2505 recommendation as it
is consistent with the LMAP proposals, such as the pending standards in the
works
:
http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-02.txt
http://www.ietf.org/internet-drafts/draft-katz-submitter-01.txt
http://www.ietf.org/internet-drafts/draft-lyon-senderid-core-01.txt
http://www.ietf.org/internet-drafts/draft-lyon-senderid-pra-01.txt
RFC 2505 section 2.6, is consistent with LMAP IP::DOMAIN association
considerations.
A local domain identify thief is 100% detectable when he client IP address
does not comply with the policy of the server's local domains.
In other words, if the client IP is your address, then you have NO business
having my domain being used on your MAIL FROM, because I did not authorize
your IP address to use the return path with my email domain. However,
before you say "Gotcha!" see below on the LMAP forwarding issues.
The same is true with the client domain name (HELO/EHLO). If a server's
local domain name is used and the IP address is unrecognized, then this is
clear 100% detectable, indisputable SPOOF. There is no LMAP forwarding
issue here.
Bruce, if you believe you wish to debate this, then I suggest to read all
the LMAP proposals and pending standards listed above before continue. Then
I will more than happy to hear your "reasonable" issues with them. You
might find you will be spitting against the wind on this one regardless (not
only with me, but also with the drafts).
And again, I say "local domains" and in this example, the client domain name
(HELO/EHLO) where there is 100% trust in the result.
For MAIL FROM, you can run into forwarding issues, and if you like to argue
this, it is probably where you should get your comments in, in regards to
the above drafts. The PROs says its a remote configuration and
implementation issue, the CONs says otherwise. The SUBMITTER draft address
the forwarding issue. A non-IETF specification called SRS is another.
I'm on both sides of the fence on this one, but one thing is clear - its
time to move on and get out of the past. I don't need to reread RFC 2505 to
know what the issues are.
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com