This draft introduces several areas where the vouching services
results could be exploited.
Section 3. Validation Process
2. Verifies legitimate use of that domain using one or more
_authentication_ mechanisms as described herein
This draft incorrectly describes Sender-ID and SFP as a domain
Authentication mechanism. Sender-ID and SPF represents a method to
authorize SMTP clients by IP address. This method does not
"authenticate" that a domain represents the source of the message.
This would be expecting all shared outbound servers to impose
restrictions on the use of the PRA, Mail-From, or the From.
Depending upon whether DKIM, domainkeys, Sender-ID, or SPF is the
mechanisms being used, any of these fields or any of these mechanisms
might be tried. In addition to communicating the type of message
being vouched for, the domain exclusion method or the domain
authentication method being employed by the recipient should also be
included. It should be clear that neither Sender-ID or SPF represent
a means to "authenticate" the valid use of the domain. The VBR-info
header should also communicate the mechanism supported by the domain
in conjunction with the vouching service. It is possible that a
domain is sent through shared servers where only the use of DKIM is
considered to offer a safe assertion with respect to the veracity of
the message. In an effort to suppress DSN abuse, an SPF record might
also be employed. To avoid the exposure to possible abuse that
shared servers might create for either SPF or Sender-ID (which could
mistake the use of SPF), the vouch header should also include the
supported method, such as sm=dkim, and the types of supported
transactions and the domain exclusion or authentication mechanism
should be returned by the vouching service to verify that the header
conforms with what the domain is trusting as a safe.
-Doug
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf