Subject: [Asrg] 6. Proposals - DMP comments

From: "Hector Santos" <[email-masked]>
Date: Sat, 20 Dec 2003 12:09:34 -0500

I have some comments, experience info about our DMP implementation:

I've implemented DMP into our WCSAP system as an option.  WCSAP is called
from the MAIL FROM state:

The main input variables into WCSAP

-  Connection IP (cip)
-  HELO/EHLO domain name (cdn)
-  MAIL FROM: Return Path (rp)

Output Variables:

- Mail From: Response Code
- Optional Mail From: Response String

The SMTP compatible fallback logic flow is:

- Optional, Check White/Black List  (Accept,Reject,Continue)
- Optional, Check RBL  (Accept,Reject,Continue)
- Optional, Check LMAP/DMP  (Accept,Reject,Continue)
- If Continue Perform CBV (Call Back Verifier)

Comments:

1) Clarification of the MAIL FROM: response code/response:

I am sure the author did not attempt to be strict. The administrative
usage/policies can dictate behavior and responses but section 5.5 and 5.6
should be more "clear" about the responses.   First time implementations
tend to use the "examples" provided for guidance.

5.5 Non-Participating Domain's User, Non-Participating Client where
    Server permits Non-Participating Domains

   S: 220 mail.example.net MMS SMTPRCV service v0.95
   C: HELO sender.example.com
   S: 250 mail.example.net Hello sender.example.com [192.0.2.1]
   C: MAIL FROM:<[email-masked]>
   (server looks up 1.2.0.192.in-addr._smtp-client.example.com
   and returns with NXDOMAIN)
   (server looks up _smtp-client.example.com and returns NXDOMAIN)
   S: 250 OK client at 192.0.2.1 verified as sender.example.com
   [resume normally]

This is not a "verified" response.  Same with 5.6.   If you removed the
parenthetical comments, it will look and be logged as a DMP validated
success:

   S: 220 mail.example.net MMS SMTPRCV service v0.95
   C: HELO sender.example.com
   S: 250 mail.example.net Hello sender.example.com [192.0.2.1]
   C: MAIL FROM:<[email-masked]>
   S: 250 OK client at 192.0.2.1 verified as sender.example.com

This is a pure fall back situation for non-compatible clients so the
response should not say it was verified.  Thats my only point about this.
This will most likely be the most common situation during the initial
deployment stages.   In our case, we will fallback to the CBV check and will
produce a response based on its result.

2) Redirected lookups:  dmp=altdomain:$ALTDOMAIN.[,$ALTDOMAIN.]

Implementers need to be careful for redundant altdomains and continues
loops.   My recommendations is to add a paragraph or comment about watching
for this situation and to suggest a MAXIMUM number of checks or a maximum X
level of redirection is allowed.

Also a note to coders, developers about how to design such a redirection:
The trick is to use a stack for the DMP lookup.

        // Push client/user dmp reverse domain addresses

        Push Client DMP Domain Address
        Push User DMP Domain Address

        Attempts = 0
        MaxCheck = 10

        // Start DMP Lookup

: NEXT

        Pop DMP Domain Address (Exit Negative if empty)
        Perform DMP lookup
        if Allow Exit Positive Result
        if ALTDOMAIN Parse and Push DMP domains (reverse order)
        if Attempts > MaxCheck Exit Negative Result
        Goto Next

and based on the proposal, the following is the truth table for the logic:

 =========================================================================
 User     Client     Result  DMP Proposal Section Description
 =========================================================================
 Allow    n/r        250     5.2   Participating Domain's User and Client
 Deny     n/r        55X
 -------------------------------------------------------------------------
 Deny     Allow      250     5.3   Participating Domain's User, Forwarding
 Deny     Deny       55X           Service on Participating Client
 -------------------------------------------------------------------------
 <>       Allow      250     5.4   Null Reverse Path, Participating Client
 <>       Deny       55X
 -------------------------------------------------------------------------
*nxdom    nxdom      251     5.5   Non-Participating Domain's User,
                                   Non-Participating Client where Server
                                   permits Non-Participating Domains
 -------------------------------------------------------------------------
*<>       nxdom      251     5.6   Null Reverse Path, Non-Participating
                                   Client where Server permits
                                   Non-Participating Domains
 -------------------------------------------------------------------------
 SERVFAIL SERVFAIL   451     5.7   Participating Domain's User and Client
                                   where DMP lookup fails (SERVFAIL)
 -------------------------------------------------------------------------
 deny     nxdom      550     5.8   Participating Domain's User, Not
                                   Participating Domain's Client
                                   (dmp=deny, NXDOMAIN)
 -------------------------------------------------------------------------
deny     SERVFAIL   451     5.8.1 Participating Domain's User, Not
                                   Participating Domain's Client
                                   (dmp=deny, SERVFAIL)
 =========================================================================

* WcSAP Fallbacks to CBV will occur

---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg