On Wed, 2004-08-11 at 10:01, George Mitchell wrote:
At Tue, 10 Aug 2004 10:40:19 -0700, Ted Hardie
<hardie(_at_)qualcomm(_dot_)com> wrote:
At 7:14 PM -0400 8/9/04, Meng Weng Wong wrote:
While such a change is, from the standpoint of architectural
purity, absolutely the correct thing to do, I fear that in
practice it may lead to confusion, needless duplication of
records, and a failure to achieve the intended objective.
In other words, it is my opinion that engineering
considerations do not weigh in favour of changing the string.
I particularly do not want to see a world where the norm is:
example.com TXT "v=spf1 a mx ptr"
example.com TXT "v=spf2 a mx ptr"
Both records would contain the same content, yet senders
might feel the need to publish both "just to be on the safe side".
Both records do _not_ contain the same information. The first
record has a target of MAIL_FROM; the second has a target
of PRA. The fact that the strings "a mx ptr" happen to be
the same in both records does not change that fundamental
fact. [...]
Surely this is a distinction without a difference. If you ask me,
"What checks do you want me to make on email which arrives with
MAIL FROM: george(_at_)m5p(_dot_)com?", and then you ask me "What checks do
you want me to make on email which arrives with a PRA of
george(_at_)m5p(_dot_)com?", would you be surprised if I answered
"... a mx -all" in both cases? Perhaps there are cases in which
people want the checks to be different, but this will be the
exception (and I think a rare one) rather than the rule. I
strongly agree with Meng that the problems associated with
changing the version string outweigh the possible theoretical
advantage.
The difference and advantage of one scheme over the other is not
theoretical. SPF allows the RFC 2822 From to differ from the RFC 2821
MAIL FROM. This allowance enables provider customers to continue using
recognized return addresses seen within their messages. SPF also checks
the MAIL FROM validity to help prevent a spoof bounce technique often
used by spammers to dodge repudiation checks.
Sender-ID places an onerous restriction on the mail sender with respect
to the use of their well-known mailbox address and Sender-ID does not
prevent the spoof bounce technique. Nor does Sender-ID conserve network
bandwidth with rejected mail, as does SPF. It would be irresponsible to
conclude acceptance of this restriction by those that have published SPF
records. I suspect the principle motivation to publish SPF records was
to find relief from the spoof bounce techniques.
There have already been some on this list indicating a series of checks
be made, one for SPF (to enable the bounce protections) and then
Sender-ID to impose limits upon the RFC 2822 From address. The logical
outcome will be inclusion of a Resent-From header by ISPs when forced
into using Sender-ID as a means to negate this expensive restriction.
A CSV check of the HELO/EHLO domain would provide a mail identifier
enhancement that can be used with an accreditation service and assist
enforcement policies. Sender-ID can not be safely used with
accreditation checks nor does it identify how mail was introduced.
If there are already wildcard SPF records, and then adding wildcard
Sender-ID records will collide and may cause a response problem.
Wildcard records granting "open" lists would likely be used as a spammer
exploit adding random sub-domains forcing a huge load on the DNS
server. I recall other issues raised in opposition to the use of
wildcards. It seems highly inappropriate for Microsoft to demand a
signed contract, and to usurp the function and meaning of SPF records.
This all seems to come under the topic why TXT records should not be
overloaded. To be fair, this was a warning ignored by the WG at the
interim meeting.
-Doug