From: Alex van den Bogaerdt
Sent: Monday, May 31, 2004 3:33 PM
On Mon, May 31, 2004 at 09:51:51AM -0500, Seth Goodman wrote:
"allow for rejection before data" != "must reject before data"
I'd like to make that choice myself, as do many users. Next thing
you know there's spf.rfc-ignorant.org listing people who
don't reject ...
(no, I am not against rfci)
If SPF ultimately does come to pass, I hope that there _is_ a
DNSBL such as
the one you mentioned for systems that don't reject SPF detectable
forgeries. It would be a perfectly reasonable and
self-protective action to
reject mail from systems that knowingly accept forgeries.
Make it a BL that lists domains _responding_to_ such addresses (any
response, such as but not limited to "Out of Office" and "No such user"),
and I agree with you completely.
We do agree here.
Me accepting such a message does not mean you have a problem with
it. It is
when I send mail to the non-existing address. Fight the problem, not an
intermediate action please.
In general, I agree with you. The circumstance I was thinking of is if the
forgery is of a real address. If there is eventually a widely accepted,
lightweight method for detecting such forgeries, an MTA that doesn't block
or at least warn their users of forgeries becomes part of the problem. I
grant you that at present, we are not even close to this situation.
To state my feelings: I MUST be able to accept and hold messages that I
will be rejecting in a month or so. There MUST be a possibility to dry
run such an invasive protocol as SPF potentially can be. Brave people
MAY start blocking right away, this MUST NOT be enforced.
There should be a serious testing and evaluation period for any methodology
that significantly affects email delivery, and SPF is no different. It
would be irresponsible to start rejecting without first doing a thorough
evaluation. How long you wait to deploy a given technology, if ever, is
totally up to you. Somewhere down the road, if and when a standard is
broadly deployed, it becomes reasonable for other systems to expect
compliance to standards and they may attempt to enforce it.
The current RFC's were not immediately implemented upon publication, either,
even though they did include some MUST language. Neither was everyone who
did not comply blacklisted. Implementation was gradual over a period of
time. When enough people had implemented them and felt that good
implementations were widely available, it seemed more and more reasonable to
expect compliance of other systems. I think much the same would take place
if SPF becomes adopted.
I hope that we don't make the mistake of failing to use MUST language where
appropriate in a standard because a transition period is required. As past
RFC's have shown, there can be an extended transition period with early
adopters and late adopters. That shouldn't preclude using MUST language in
standards and _eventually_ enforcing them.
--
Seth Goodman