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:<user(_at_)example(_dot_)com>
(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:<user(_at_)example(_dot_)com>
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg