Julian,
At 02:49 PM 1/9/2008, you wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
WebMaster(_at_)commerco(_dot_)net wrote:
> I appreciate your explanation to Alessandro, as it better clarifies
> the thinking behind not requiring actions on the receiver side in the
> specification for me. Even so, I think his is point is well taken
> (unless I'm missing something else), in that offering recommendations
> in RFC specs is not unusual. Simply couch them in words like
> "should" or "may".
Understood. However the specification is already making such a suggestion
for receivers' reaction to the "Fail" result:
| The checking software can choose to mark the mail based on this or to
| reject the mail outright.
Well, that is certainly fine. I guess my concern stemmed from how
the mail was rejected... again getting back to the bounce
issue. While common sense certainly suggests that no bounce should
occur, I was just concerned that some might not follow common sense.
I don't have a problem with such soft-talk. What I am against is making
one reaction or the other _mandatory_.
Agreed.
> If there is an underlying reason why "some things are better left
> unspecified" that you can either share here or simply assure me is
> true, but not for public consumption, I'll leave this issue entirely
> and accept what you say on this point without additional questions.
There's no secret magic at work here. I'm merely trying to get my point
across that strictly specifying some things is counter-productive.
You're free to dissent.
lol. Thanks, though I really do try not to be a trouble maker, I'm
just an interested domain holder wanting to make sure I get the best
level of protection I can against misuse and identity theft of my
domains and the consequential headaches from email resources being
overtaxed. ;-)
And by the way, I do agree that making things mandatory on the
receiver side is entirely counterproductive (and likely impossible or
the entire SMTP/POP3 environment would probably have been replaced
with something else by now).
That said, placing suggestions as to how to implement SPF does not
seem too problematic and will help coders do a better job of
following the intent of a specification. Still doing so is always
something of a balancing act which is subjective and bound to cause
some dissent.
Best,
AlanM
The Commerce Company
TZ.Com - Travel Zippy
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=83973583-6d795e
Powered by Listbox: http://www.listbox.com