-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
AccuSpam wrote:
<snip>
| Thanks for advice, but our hope is Microsoft or other large entity will
| adopt SenderKeys. AccuSpam.com alone can not carry it.
Microsoft merged their effort with SPF (I presume you know this, right?).
| Just as Pobox.com alone could not carry SPF to widespread adoption.
The portion of SPF which is included into MARID will be carried to
widespread adoption when the RFC is completed.
| AccuSpam wants SenderKeys to prosper because the other anti-forgery
proposals
| will not solve the e-mail forgery problem for most domains, because of the
| reasons stated on the SenderKeys web page. If any other the other
proposals,
| e.g. SPF, DomainKeys, or SenderID, were going to solve the problem, then
| there would be no need for us to propose SenderKeys.
Now we come to the true issue of debate. Your web site says:
A. "are unable to detect with 100% certainty whether a "From:" address
is forged, unless all e-mail from all e-mail addresses, which use same
domain, is always sent from a mail server which is approved by the owner
of the domain."
B. "Restricting all senders whose address contains the domain, to the
approved mail servers for the domain, is highly impractical, as has been
elaborated extensively by others."
You say this stuff as though it is fact but you leave the arguments to
others ("as has been elaborated extensively by others") as though it is
not your responsibility to prove your own position. I posit to you that
it *IS* your responsibility to prove your own position as there are a
very large number (and it's growing daily) of competent network and mail
system admins who disagree with the statement I quoted above. These
admins are the very same people that you are talking to in this forum
and you will have a damnably difficult time convincing us (as I include
myself in the number of SPF users) if you do not prove your argument.
Now, as to the argument itself lets take a look at it...
Your statement that I have referenced in "A" above implies that *if* a
mail is sent from a server which the domain owner has authorized then
all 3 methods (DomainKeys, SenderID, and SPF) *can* be 100% certain that
the mail is not fraudulent. I cannot speak for Domainkeys or SenderID
(and frankly I wouldn't care to even if I had enough quantitative or
qualitative information to do so). That said I *can* speak for SPF in
that regard and say that *if* an email is sent from an authorized MTA
for my domains (moongroup.com plus about 30 others) it will *NOT* be
fraudulent unless it involves the edge case I mention next. Now some
people have said, in essence, "What about the edge case involving stolen
credentials?". A valid concern but it's *NOT* the problem that SPF is
trying to solve! If this were to happen (and I admit that it does) it is
a simple matter to deal with it and in fact... a proper SPF
implementation makes it much simpler as this type of fraud is much
easier to deal with when you know the source of the fraud and SPF flat
out guarantees that you will!
To continue on in this vein I turn now to reference "B" wherein you say
that "Restricting all senders whose address contains the domain, to the
approved mail servers for the domain, is highly impractical...". Leaving
aside the fact that you have given no support to your argument I will
deal with it as though you *have* tried to support it. I *DO*, in fact,
(right now, today even) restrict all senders whose address contains one
of my domain names to transiting through the approved mail servers for
those domains and it has *NOT* proven to be impractical, nor has it even
proven to be marginally difficult and I should also hasten to add that I
have been doing this for *YEARS* in advance of the time that I first
heard of SPF or MARID. If someone would like to point out that my
domains are a pindrop in the ocean of the internet I would agree but I
have to say that the company that I work for everyday does the same
thing and they've also been doing it for years with little difficulty
and so do any number of other firms I have worked with over the years.
When I was chief technologist at LinuxMall I required it then and we had
no problem doing what it took technologically to make it happen. With
the variety of methods that make it possible I do not understand the
repeated, and IMHO, ill informed objections, to this. The methods I know
of include vpn's of myriad type, web mail, DRAC, pop-before-smtp, and
SMTP-AUTH and those are just for starters... there may be others of
which I have no knowledge. So from my point of view your point "B" is
specious from the get go!
As to your second paragraph which begins with the words "Wide
deployment..." all I can say is that for the same reasons I just gave
above it's simply balderdash.
Paragraph 3 requires an SRS implementation to overcome and that presumes
you are remotely concerned with breaking forwarding and I openly admit
that I am not. I have no interest in "fixing" it or even recognizing it
as a serious problem. IMHO it is a miniscule problem completely subsumed
in the spam/worm/virus maelstrom.
What follows are some numbers which represent the % of mail traffic
handled by my own MTA for each day of the last 5 which was rejected as
spam, worm, virus or the like. This is not email which was detected by a
spam filter after receipt. This is mail which was rejected at the SMTP
port and it represents the problem I joined this effort to try to solve:
Postfix log summaries for Aug 19 - rejected (76%)
Postfix log summaries for Aug 18 - rejected (84%)
Postfix log summaries for Aug 17 - rejected (89%)
Postfix log summaries for Aug 16 - rejected (88%)
Postfix log summaries for Aug 15 - rejected (95%)
These are mail *SERVER* stats... *NOT* mail *CLIENT* stats and I reject
the notion that this is a client level problem or even that it can be
solved at the client level! As the service provider *I* am the one who
the expense is tied to! *I* am the one that is *PAYING* with my time
each and every time some mental midget decides it would be soooooooo
*COOL* to modify the latest vbscript worm and send it out through his
stolen bot network! If domain owners adopt SPF it'll die still born and
that will be glorious to *NOT SEE*.
For those who would continue to argue I will now step down off the soap
box and make room for those who have more cogent arguments than I but
before I go there is one more thing I want to say about this. For those
who have not yet realized it the days of the kind, gentle, trusting
internet are over. I have had to recognize that (depressing though it
may be) and that realization has not made me happy. Some who agree with
me are still hoping to preserve vestiges of what it used to be but I no
longer think we can. It's gone forever and it's not coming back.
- --
Chuck Mead <csm(_at_)redhat(_dot_)com>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBJk6dZfy0juH51WsRAr1NAKCMLiK14hBS5qndtGyj3KPFTd1BnwCfWiok
wB/A7ek9YPwoTmftLBJxHAE=
=C6bs
-----END PGP SIGNATURE-----