At 04:03 PM 8/18/2005 -0400, John Leslie wrote:
David MacQuigg <dmquigg-clear(_at_)yahoo(_dot_)com> wrote:
The main issue is whether we should include an MTA action other than
'ACCEPT', 'REJECT', or 'TEMPFAIL'. I guess I should have said that this
routine is to be called *after* it is known that the sender offers CSV
authentication. In that case it makes sense to reject when the promised
CSV records are not there.
My preference would be to have this routine return the "unknown"
result, documenting that an "unknown" result for a domain which promises
to maintain CSV records should probably be cause to reject the email.
(This, of course, creates an overlap with weight==3...)
That still leaves the "weight==3" case, which I did not know about, and
don't understand. If a sender can't make a clear statement as to the
authorization of all servers with A records under a name that he chose, I
don't see any value in having CSV records for those servers.
From the standpoint of the CSV spec, it's legitimate to say that the
HELO name is authorized, even if the full list of IP addresses cannot
be returned in a single DNS response. An example would be special-purpose
DNS servers which return different lists (not just differently-ordered)
lists depending on topology, time-of-day, or other criteria.
We certainly did not intend to recommend such a practice; and I would
certainly agree it does not meet the reasonable expectations of a promise
to publish CSV for a domain -- since there are a number of simple ways
to avoid situations like this. The CSV _spec_ nonetheless intends to
absolutely minimize the changes to current email policies (which in many
cases are IMHO excessively bureaucratic).
Thus it would be entirely reasonable for _you_ to recommend rejection
of email from a sending SMTP client using a HELO string which leads to
a weight==3 SRV response.
We can certainly add an "unknown" action to our list, and let receivers
decide what to do,
That is my recommendation.
but I would much rather have a simple script returning a clear
recommended action. SPF suffers from this kind of ambiguity, and I
thought CSV was supposed to avoid it.
It is impossible to avoid all ambiguity in email. CSV is supposed to
enable unambiguous declarations, not require them.
If a sender promises CSV, then can't be definite about his CSV
authorizations, he shouldn't get any advantages from "offering" CSV.
The spec cannot assume the sender has promised anything. The situation
becomes entirely different when such a promise exists; but this is
out-of-band to CSV. It is better, IMHO, for a "CSV implementation" to
return the "unknown" result.
Note also that all *actions* are ultimately the choice of the receiver.
I totally agree. I just find it easier to keep "implementations" of
CSV within the paradigm of CSV, which intends to offer a benefit to
those who publish CSV, not a punishment to those who don't.
OK, I think I see a clear plan of action. We have two "unknown" situations:
1) The sender has declared their offer of CSV records (or we wouldn't be
calling this routine). No records were found.
2) The sender has said in their CSV records (with weight=3) - "Please
accept messages with this HELO name, even if the IP is not on the list we
send you."
The MTA must dispose of the message one way or another. This routine is
where the decision is made on what to do with an "unknown" result. Here is
what I have done to the script. It is easy to change if there is further
discussion.
1) These messages will be REJECTed, with a clear statement in the SMTP_reply.
2) These will be sent to the spam FILTER, with a warning in the SMTP_reply
and a CSV1 UNKNOWN result in the header.
Here are the changed sections. Updated module at
http://purl.net/macquigg/email/python/pycsv.py
weight = data[1] # authorization ( 1: NO, 2: YES, 3: MAYBE )
...
## Check incoming IP against the list:
if IP in aa:
action = 'ACCEPT'
SMTP_reply = (250, '', 'Sender CSV OK')
header = {'label': 'Authent:',
'text': '%s %s CSV1 PASS' % (IP, helo) }
return (action, SMTP_reply, [header] )
else:
if weight == 2:
action = 'REJECT'
SMTP_reply = (550, '5.7.1',
"'%s' not authorized by '%s'" % (IP, helo) )
return (action, SMTP_reply, [] )
elif weight == 3:
action = 'FILTER'
SMTP_reply = (250, '?.?.?', ### code for "tentative accept"?
"'%s' not listed by '%s' Do not depend on delivery." % (IP, helo)
)
header = {'label': 'Authent:',
'text': '%s %s CSV1 UNKNOWN' % (IP, helo) }
return (action, SMTP_reply, [header] )
else:
action = 'REJECT'
SMTP_reply = (550, '5.7.1',
"SRV record with weight=%s not valid for CSV version 1" % weight
)
return (action, SMTP_reply, [] )
The warning in the SMTP_reply, plus the false rejects from spam filters,
should give senders with weight=3 plenty of incentive to mend their ways.
Is UNKNOWN the right keyword to use? SPF has a well-defined set of
"result" keywords, but I can't find anything similar in
draft-ietf-marid-csv-csa-02.
--
Dave
************************************************************ *
* David MacQuigg, PhD email: david_macquigg at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *