----- 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:
| 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.
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.
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.
So far, this has not been any concern whatsoever in the 3 years of usage
thousands of our customers.
However, during the early days, I personally heard it from one small sysop
"pundit" who intentionally blocked us out of spite just to prove his point,
but not because the CBV was doing its job.
Anyway, here are our admin options for the CBV:
;---------------------------------------------------------------------
; Wildcat! CBV Options:
;---------------------------------------------------------------------
Section CBV Options ; Callback Verifier
;---------------------------------------------------------------------
SkipPostMaster True ; If mail from postmaster, skip CBV
; cbv connect options
NoDomainReject True ; Reject if remote has no domain ip (A)
record
NoMXReject True ; Reject if remote has no mx record
NoMxTryDomain True ; if true, try to connect to domain ip
address
; cbv session options
SocketWaitTime 35 ; SMTP response wait time
UseNoop True ; Send NOOP to help identify WCSAP
UseEhlo False ; Try EHLO, fallback to HELO
UseVRFY False ; Try VRFY, fallback to RCPT TO
SapHost [serverdomain] ; ** USE YOUR WCSMTP MX DOMAIN! **
SapMailFrom <> ; address used for MAIL FROM
; cbv open relay options
UseRSET True ; Solves 1 RCPT limit for MAIL FROM: <>
OpenRelayCheck True
RejectOpenRelay True
OpenRelayAddress wcsap-openrelay-test-123sxa23(_at_)alqwejad(_dot_)com
The only contention issue is the short SocketWaitTime. It has not failed
us. There is a reason for this amount - average "Keep Alive" for sockets.
EXIM actually uses 30 seconds and the author has a good inline comment
explaining the reasons. I also had reasons in IETF-SMTP threads.
Bottom line, it isn't a show stopper and not something to throw out the
baby. If it was, I would of immediatelly pulled the CBV project from our
product. We don't need the customer hassles.
Interestingly, my server tries a CBV on verizon, and it immediately
rejects the connection with a 421, so maybe they track what CBVs are
in progress and don't let you connect back?
I am pretty sure it is, atleast it is what I concluded it was for the last
time I explored it. I intentionally forced a loopback to see how it
reacted. When we called back the address, it didn't check ours again.
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 like to think this has help minimized concerns of remote admins checking
logs over the years.
There another CBV product that also does the same thing but also includes a
HASH in the NOOP for some recording.
Anyway, 3 years of usage. No doubt, a major successful feature and I wasn't
surprise. Return Paths are bad. Its there to be checked and if done in the
most SMTP compatible and expected way, it worked pretty dawn well to remove
the obvious problematic transactions.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
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