"Hector Santos" <spf-discuss(_at_)winserver(_dot_)com> writes:
----- Original Message -----
From: "David Mazieres (no direct replies)"
- Skip CBV on POSTMASTER return-paths
(must be accepted per spec)
Sorry, do you mean skips CBV for postmaster *recipient*, or mail-from
return path? I can understand skipping CBV if the recipient is
postmaster, but not the sender. After all, isn't the point of CBV to
check if the sender is following the spec by providing a valid return
address?
Example: incoming:
MAIL FROM: <postmaster @ somedomain.com>
Don't bother to do a CBV here because even if you do call it, the remote
domain hosting somedomain.com must accept POSTMASTER always per
specification RFC 2821 secton 3.6:
Right. So I *want* to do CBV so as to figure out if the
somedomain.com is 2821 compliant. Why should I accept mail from
someone who is not respecting RFC 2821? Especially if they don't even
have a working mail server.
| 3.6 Domains
|
| ...
|
| - The reserved mailbox name "postmaster" may be used in a RCPT
| command without domain qualification (see section 4.1.1.3) and
| MUST be accepted if so used.
At the remote site:
C: MAIL FROM: <>
S: 250 Ok
C: RCPT FROM: <postmaster @ somedomain.com>
S: 250 Ok
So it provides no feedback.
Of course it provides feedback! Specifically it tells me the other
side is obeying RFC 2821. Also it tells me the client's server is up
and running. It could be that their mail server always rejects
clients with "421 server too busy". In that case I want to defer the
message with a 400 error code.
Now, you could check to see if somedomain.com is a valid email domain. So
yes, that much can be done. But overall, skip it because it can create a
loopback and it provides no feedback since it must always be accepted
anyway. We ran into this problem early on with EXIM since it was using
PostMaster for its "Callout" as it calls it. Don't know if that was an
admin setup or built-in or default, but it was corrected once the admin was
informed so I guess it is configurable.
Unless I'm missing something, A) it provides feedback, and B) it can't
loop since the CBV's MAIL FROM is <>.
Now there's a good argument for saying if the *recipient* is
postmaster, don't use CBV. In particular, Exim should obviously do
this to avoid loops with itself.
2) During a CBV, we check two addresses:
- the original session return path
- a random address to check for open relay
Can you elaborate on the random address? This second check must be to
a separate IP address, namely that of the SMTP client, correct? (As
opposed to the first one which goes to the MX record of the envelope
sender.) How do you construct the random address? This seems
slightly dangerous in that the sender might happen to trust you
without being an open relay.
The standard "Rule of Thumb" in SMTP is:
- Local Domain recipients do not need authentication to relay
- Remote domain recipients need authentication to relay.
Since the CBV is an non-authenticated session, it provides an proper
opportunity to see if the target host is an open relay by checking to see if
it accepts "any random" domain email address that is not its own. If it
accepts it, then its considered an open relay and the CBV returns with a
negative response.
By random, we allow the admin to define some off-the-wall CBV OpenRelay
Check Address (a default is provided). But it is not a dynamic random
address for the reasons you pointed out. I did consider it, but to minimize
the problem with a remote tracking random addresses, I felt it was better if
it was constant.
Can you just give me an example, more specificly, of the second, open
relay CBV? Suppose client with IP address A is sending mail to server
with IP address B. The session begins:
A -> B: EHLO A
B -> A: 220 whatever
A -> B: MAIL FROM:<non-postmaster(_at_)some(_dot_)domain(_dot_)tld>
B -> A: 250 ok
A -> B: RCPT TO:<non-postmaster(_at_)some-other(_dot_)domain(_dot_)tld>
Now you are saying that at this point you start 2 CBVs?
1) A CBVs the mail exchanger for some.domain.tld to see if
non-postmaster(_at_)some(_dot_)domain(_dot_)tld is a valid address.
That's fine.
2) A CBVs machine B, to find out if it can send mail to some random
address.
#1 I have no problem with. Since you are probing based on Mail-From,
and since the CBV's Mail-From is empty, there is no possibility of a
loop.
#2 seems like a recipe for a loop. A probes B. Then what's to stop B
from again probing A, and so on? I mean does this not continue:
B -> A: EHLO B
A -> B: 220 what's
B -> A: MAIL FROM:<>
A -> B: 250 ok
B -> A: RCPT TO:<random(_at_)example(_dot_)com>
and now it's time to for B to verify that A is not an open relay...
One final point. I notice you don't make any effort to inform the CBV
site of what is going on. I would argue that may be bad practice. If
you are writing up an I-D about CBV, maybe you should suggest issuing
a NOOP operation.
We do use a NOOP to identify our CBV sections. It is optional for the sysop
to use. See the UseNoop Option above.
If you didn't see in our system, I must of turned it off... let me check...
No it is on. You should see something like so in our CBV sessions issued
before HELO/EHLO:
C: NOOP WCSAP v2.07 Wildcat! Sender Authentication Protocol
http://www.santronics.com
I think you should include the IP address of the client that caused
the probe, and the possibly forged Mail-From address. Otherwise, you
may know that people are forging mail from you, but have no way of
identifying who is doing it.
There another CBV product that also does the same thing but also includes a
HASH in the NOOP for some recording.
I don't see the need for a HASH. There is no privacy concern here.
Either the mail came from my domain (in which case I'm going to know
about it anyway), or it's forged, in which case I want to know who is
forging mail from me.
David
--
This message was sent from a non-repliable address for a closed mailing list.
If you wish to reply directly to me, you can use the following address, which
expires on 03 Mar 2006:
<mazieres-p6erb3qyfys9pjftj5ti3aisq2(_at_)temporary-address(_dot_)scs(_dot_)stanford(_dot_)edu>
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com