----- Original Message -----
From: "Dave Crocker" <dcrocker(_at_)brandenburg(_dot_)com>
To: "Jon Kyme" <jrk(_at_)merseymail(_dot_)com>
Cc: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, March 09, 2004 11:28 AM
Subject: Re: [spf-discuss] Latest proposal re HELO checking: make HELO tests
optional
It is a simple fact of the real world that a handling return address is
not in any way required to specify the author or sender of the message.
Dave,
Does it really matter?
In the real world, it does originate as the sender of the message beginning
at the first-hop, otherwise the system would break down. Of course, there
are exceptions such as a mailing list, but that still a presumed verifiable
address to the owner/moderator of the list.
The key issue is validity and some of the arguments I hear which puts up a
barrier to "solving problems" is that the return path does not to be
consider until it is required. Of course, that is part of the problem and
in what the spammers rely on.
The fact is, RFC 2821 clearly requires all final destinations MTA to insert
a return path with the presumption it is a verifiable address and it is must
requirement that a system notification be sent for non-delivery. This
means the address must be valid.
In addition, RFC 2821 clearly allows for the validation of the return path:
3.3 Mail Transactions
If the mailbox specification is not acceptable for
some reason, the server MUST return a reply indicating whether the
failure is permanent (i.e., will occur again if the client tries to
send the same address again) or temporary (i.e., the address might be
accepted if the client tries again later). Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In those
cases, the server MAY reasonably accept the reverse-path (with a 250
reply) and then report problems after the forward-paths are received
and examined. Normally, failures produce 550 or 553 replies.
This opens the door for enforcement. In fact, IMO, the above suggested
method is the most ideal way to handle the new augmented technologies such
as SPF and others that do add "enforcement" to the SMTP structure.
Systems that perform dynamic RCPT validation will be more optimized than
post validation systems.
Also, just a side note, SPF does not validate an address. It validates the
domain part of the address. It is clearly possible for two addresses; one
bad user, one good user with a common domain to have to the same SPF result.
With that said, I find ironic, whether it is intentional or not to prove a
point, that the gatekeeper of the IMC, uses invalid return paths in a
mailing list!!
01:13:18 C: MAIL From:<phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>
SIZE=545
01:13:18 S: 250 <phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>...
Sender validation
pending. Continue.
01:13:18 C: RCPT To:<hsantos(_at_)santronics(_dot_)com>
01:13:27 ** WCX Process: wcsap ret: 552 (Rejected by WCSAP CBV)
01:13:27 S: 552 Return Path not verifiable.
The wcSAP log for this session is:
20040305 01:13:18 -------------------------------------
20040305 01:13:18 version : 1.55 / 1.54
20040305 01:13:18 calltype : SMTP
20040305 01:13:18 state : rcpt
20040305 01:13:18 cip : 208.184.76.39
20040305 01:13:18 cdn : above.proper.com
20040305 01:13:18 from :
<phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>
20040305 01:13:18 rcpt : <hsantos(_at_)santronics(_dot_)com>
20040305 01:13:18 srvdom : winserver.com
20040305 01:13:18 srvip : 208.247.131.9
20040305 01:13:18 sapfilter : pass (time:16)
20040305 01:13:18 saprbl : testing 39.76.184.208.sbl.spamhaus.org
20040305 01:13:19 saprbl : testing 39.76.184.208.list.dsbl.org
20040305 01:13:21 saprbl : testing 39.76.184.208.bl.spamcop.net
20040305 01:13:22 saprbl : pass
20040305 01:13:23 sapspf : none (time:1438)
20040305 01:13:24 sapcbv : total mx records: 0
20040305 01:13:26 try domain : above.proper.com ip: 208.184.76.39
20040305 01:13:26 # connecting to 208.184.76.39
20040305 01:13:26 S: 220 above.proper.com ESMTP Sendmail 8.12.11/8.12.8;
Thu, 4 Mar 2004 22:11:22 -0800 (PST) NO UBE
20040305 01:13:26 C: NOOP WCSAP v1.55 Wildcat! Sender Authentication
Protocol http://www.santronics.com
20040305 01:13:26 S: 250 2.0.0 OK
20040305 01:13:26 C: HELO mail.winserver.com
20040305 01:13:26 S: 250 above.proper.com Hello ntbbs.winserver.com
[208.247.131.9], pleased to meet you
20040305 01:13:26 C: MAIL FROM: <>
20040305 01:13:26 S: 250 2.1.0 <>... Sender ok
20040305 01:13:26 C: RCPT TO:
<phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>
20040305 01:13:26 S: 550 5.1.1
<phoffman(_dot_)org(_at_)above(_dot_)proper(_dot_)com>... User
unknown
20040305 01:13:26 C: QUIT
20040305 01:13:27 sapcbv : 550
20040305 01:13:27 result : reject (0)
20040305 01:13:27 smtp code : 552
20040305 01:13:27 reason : Rejected by WCSAP CBV
20040305 01:13:27 wcsap finish (8828 msecs)
I guess the question is, what comes first?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com