On Nov 7, 2008, at 9:27 AM, Charles Lindsey wrote:
On Fri, 07 Nov 2008 04:00:58 -0000, Douglas Otis <dotis(_at_)mail-
abuse.org>
wrote:
New email headers' misuse of the term "authentication" will prove
highly deceptive for recipients and damaging for domains!
The Random House dictionary definition of "authenticate" says:
1. to establish as genuine.
2. to establish the authorship or origin of conclusively or
unquestionably, chiefly by the techniques of scholarship: to
authenticate a painting.
3. to make authoritative or valid.
All you are doing is making a, possibly sensible, case for better
wording of the various parameters of this header. If you were to
concentrate on that, we might begin to listen.
Thank you for your fair comment.
Since there will be complaints that there is already some deployment,
one possible solution could be to change Sender-ID and SPF results
from:
sender-id=pass jon-doe(_at_)example(_dot_)com
to:
sender-id=pass MTA/192.168.100.128/Authorized-By/@example.com
Fix ups would be limited to stripping "MTA/192.168.100.128/Authorized-
by/" from the domain. The MUA could then add "*." when looking for a
header field match while following the PRA algorithm. There are two
important reasons not to include the local-part in this header.
Exclusion of the local-part acknowledges this local-part information
is never verified by the authorization methodology. In addition, use
of local-part macros within the SPF records might create a potential
for DDoS attack. bot-net are often leased for over a span of hours.
Negative caching, coupled an already diverse use of local-parts in a
spam campaign can be leveraged over this period into an attack with
its magnitude increased by several orders and then appear to emanate
from the receiving domains. This would be a new type of high gain
reflected attack.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html