Discussion:
Should DKIM drop SSP?
(too old to reply)
Douglas Otis
2005-10-26 21:45:54 UTC
Permalink
One could view DKIM as a mechanism that establishes an accountable
domain for the messages contained within the email message transport
system. By limiting the scope of DKIM to being a mechanism that
provides an accountable domain for the transport system, a great deal
of benefit can be derived without threatening the integrity of the
transport system. As such, policies that are established by various
methods MUST BE with respect to the email message transport system,
and NEVER a specific header unrelated to the email message transport
system, see RFC2822.


Justifications for Anti-Phishing policies:
----
Special policies for email-address constraints may be established as
a response to domains that have become "phishing" targets.
Nevertheless, these policies should be considered outside the scope
of DKIM. In such "phishing" messages, links are often included that
take the recipient to fraudulent websites. An urgent response to
this situation is not addressed by a complex scheme that requires
parsing of several text and binary DNS records, and where a sequence
of additional DNS records may also be required in attempts to
mitigate problems created for the general case.

In addition, an immediate response to the "phishing" threat would
include far more restrictions than just for the RFC2822
Arvel Hathcock
2005-10-26 21:54:05 UTC
Permalink
No, DKIM should not drop SSP.

--
Arvel
Scott Kitterman
2005-10-26 22:32:18 UTC
Permalink
No we should not.

Is there anything in this line of reasoning that isn't duplicative of the last
time we went through your view on this in August?

Scott Kitterman
Douglas Otis
2005-10-26 23:24:32 UTC
Permalink
Post by Scott Kitterman
No we should not.
Is there anything in this line of reasoning that isn't duplicative of the last
time we went through your view on this in August?
At that time, if I recall, the problem was related to shared systems
and possible unfair accrual of reputation based upon the email-
address. This issue was left open. Since then, SSP has become more
disruptive of typical email use. Unfortunately such disruption by
SSP is _required_ before benefits are derived with respect to
repudiating invalid messages. Such disruption would not occur when a
relationship to the email message transport is used as the basis of
the policy, rather than the author.

Risks to valid messages associated with these policies and a lack of
a defensive strategy remain the greatest risks to a successful
outcome. There are several that see
Dave Crocker
2005-10-26 23:48:45 UTC
Permalink
Doug,
Can you acknowledge the trade-off and defend this choice?
Can you demonstrate any support on the list for your proposal?
Douglas Otis
2005-10-27 01:08:46 UTC
Permalink
Post by Dave Crocker
Can you acknowledge the trade-off and defend this choice?
Can you demonstrate any support on the list for your proposal?
Those advocating use of SSP should be prepared to review disruptive
changes to email handling that will be entailed. SSP related
problems were not covered in the threat review prepared by Jim.
Mark Delany
2005-10-27 01:23:15 UTC
Permalink
What damage does SSP cause the email message transport system?
You mean the transport that is currently 80% pollution? None of
consequence. Can we move on now?


Mark.
Mark Delany
2005-10-27 01:01:33 UTC
Permalink
Post by Douglas Otis
Risks to valid messages associated with these policies and a lack of
a defensive strategy remain the greatest risks to a successful
outcome. There are several that see
Douglas Otis
2005-10-27 02:11:41 UTC
Permalink
Post by Douglas Otis
Risks to valid messages associated with these policies and a lack of
a defensive strategy remain the greatest risks to a successful
outcome. There are several that see
Earl Hood
2005-10-27 04:17:08 UTC
Permalink
There are vast numbers of messages legitimately sent by those not
identified in the
Douglas Otis
2005-10-27 19:14:46 UTC
Permalink
There are vast numbers of messages legitimately sent by those not
identified in the
Frank Ellermann
2005-10-27 02:04:03 UTC
Permalink
Can you acknowledge the trade-off and defend this choice?
I'm more interested in your choice, DKIM without SSP. Your
vision is some kind of reputation system, e.g. you know that
NNNNN are good guys. Therefore you want to accept anything
that's really from NNNNN. If it comes directy from one of
their mailouts you don't need DKIM, that situation is faster
handled by one of the HELO-checking protocols like CSV or SPF.

So your focus are "redirected" mails. Wild and wonderful 251-
forwarding from who knows. A DKIM signature _should_ survive
this torture, and then you can check that the source was NNNNN.

How do you catch the crap that only claims to be "from" NNNNN ?

Bye, Frank
Douglas Otis
2005-10-27 20:45:20 UTC
Permalink
Post by Frank Ellermann
Can you acknowledge the trade-off and defend this choice?
I'm more interested in your choice, DKIM without SSP. Your
vision is some kind of reputation system, e.g. you know that
NNNNN are good guys.
DKIM signatures will be invalid for many reasons for perhaps a long
deployment period. A reputation system can be based upon the signer
only when the signature remains valid. Otherwise, use of the remote
IP address, or perhaps a verified EHLO would be used.
Post by Frank Ellermann
Therefore you want to accept anything
that's really from NNNNN. If it comes directy from one of
their mailouts you don't need DKIM, that situation is faster
handled by one of the HELO-checking protocols like CSV or SPF.
With the assured maximum of 1 lookup, CSV could offer DoS protections
within the same name space as the signer. The signer however offers
a significant advantage when attempting to remedy abuse.
Post by Frank Ellermann
So your focus are "redirected" mails. Wild and wonderful 251-
forwarding from who knows. A DKIM signature _should_ survive
this torture, and then you can check that the source was NNNNN.
The concerns regarding the SSP policy is not confined to Unix style
forwarding, but includes list-serves or e-invites that sign messages,
and cases where an ISP wishes to sign messages without introducing
Sender headers that create support issues.
Post by Frank Ellermann
How do you catch the crap that only claims to be "from" NNNNN ?
Assuming signatures have been proven reliable, then fewer
repercussions occur regarding assertions made with respect to all
email that appears to have been "introduced" per RFC2822 by domain
NNNNN. This association for the assertion allows DKIM to directly
provide the desired repudiation of unsigned messages without
degrading the integrity of email delivery.

As repudiation is most often needed for prior correspondents, these
assertions could and should be directly carried within the message,
as this method is likely the most secure means for distributing these
few bits of information. I also assume the deployment period will
allow introduction of DKIM aware MUAs and MTA able to collect this
information. When a recipient has never seen a message from YYYYYY,
most will be more careful about believing the content of such a
message or perhaps even accepting these messages for a period of
time. Automatic collection of the binding information found within
the message could happen when the signing-domain is within email-
address.

Use of an opaque-identifier option will quickly isolate compromised
systems by third-parties and will also allow the use of this
information to create a type of pseudo-certificate that identifies
the account used to send the message. These pseudo-certificates can
opportunistically be bound to email-addresses being used by the
account holder, which does not require any administration by the
provider to accomplish the association. (The real low cost approach.)

Within the message signature, there can be assertions made that
indicate that all messages "introduced" by the signer are signed.
There can be assertions that indicate the email-address bound to the
signature has been verified. There could be assertions that indicate
the use of an opaque-identifier will associate with the account.
Several of these assertions within messages can be safely acquired
automatically by the MTA and MUA. By using this approach, there
would not be a need to look for separately published policy
assertions or binding tips, as they would have already been securely
acquired.

The opaque-identifier option would also allow the detection of intra-
domain spoofing. With the current proposal, intra-domain spoofing
can not be detected and relies upon restrictions made upon the
account holder. This limits the email-address account holders would
be allowed to use. An opaque-identifier approach would allow current
practices to remain unchanged, while offering every account holder a
pseudo-certificate <OID>.<signing-domain>. Sweet. : )


-Doug
Scott Kitterman
2005-10-27 20:52:24 UTC
Permalink
Doug,

So is it your view that DKIM roughly at it stands, with SSP and without your
"Opaque identifier" is fatally flawed and shouldn't go forward?

Scott K
Hector Santos
2005-10-27 21:22:50 UTC
Permalink
----- Original Message -----
From: "Scott Kitterman" <ietf-***@kitterman.com>
To: <ietf-***@mipassoc.org>
Sent: Thursday, October 27, 2005 4:52 PM
Subject: Re: [ietf-dkim] Re: Should DKIM drop SSP?
Post by Scott Kitterman
Doug,
So is it your view that DKIM roughly at it stands, with SSP and without your
"Opaque identifier" is fatally flawed and shouldn't go forward?
Douglas Otis
2005-10-27 21:49:01 UTC
Permalink
Post by Scott Kitterman
Doug,
So is it your view that DKIM roughly at it stands, with SSP and without your
"Opaque identifier" is fatally flawed and shouldn't go forward?
SSP, as it is currently defined, will cause a reduction in the
integrity of email delivery which, before this strategy, managed in
spite of inordinate abuse. This policy placed exclusively on the
Dave Crocker
2005-10-27 23:41:38 UTC
Permalink
Doug,

My, my, but aren't we having fun consuming list bandwidth?
SSP, as it is currently defined, will cause a reduction in the integrity
of email delivery which, before this strategy, managed in spite of
inordinate abuse. This policy placed exclusively on the
Frank Ellermann
2005-10-28 11:06:41 UTC
Permalink
Allow the DKIM SSP policy assertion be referenced from the
header associated with the domain that "introduced" the
message (Resent-Sender, Resent-From, Sender, or From), and
not the domain associated with the originator (From).
Terminology issue: (2)822 uses "originator" for the set of
addresses found in
Douglas Otis
2005-10-28 20:40:28 UTC
Permalink
Post by Frank Ellermann
Allow the DKIM SSP policy assertion be referenced from the
header associated with the domain that "introduced" the
message (Resent-Sender, Resent-From, Sender, or From), and
not the domain associated with the originator (From).
Terminology issue: (2)822 uses "originator" for the set of
addresses found in
Scott Kitterman
2005-10-28 16:37:34 UTC
Permalink
Post by Douglas Otis
Post by Scott Kitterman
Doug,
So is it your view that DKIM roughly at it stands, with SSP and without your
"Opaque identifier" is fatally flawed and shouldn't go forward?
SSP, as it is currently defined, will cause a reduction in the
integrity of email delivery which, before this strategy, managed in
spite of inordinate abuse. This policy placed exclusively on the
Scott Kitterman
2005-10-27 14:46:35 UTC
Permalink
Post by Douglas Otis
Post by Scott Kitterman
No we should not.
Is there anything in this line of reasoning that isn't duplicative of the last
time we went through your view on this in August?
At that time, if I recall, the problem was related to shared systems
and possible unfair accrual of reputation based upon the email-
address. This issue was left open. Since then, SSP has become more
disruptive of typical email use. Unfortunately such disruption by
SSP is _required_ before benefits are derived with respect to
repudiating invalid messages. Such disruption would not occur when a
relationship to the email message transport is used as the basis of
the policy, rather than the author.
Risks to valid messages associated with these policies and a lack of
a defensive strategy remain the greatest risks to a successful
outcome. There are several that see
Hallam-Baker, Phillip
2005-10-27 00:53:17 UTC
Permalink
No, DKIM should standardize both SSP and the message format.

SSP will be used regardless.
-----Original Message-----
Sent: Wednesday, October 26, 2005 5:54 PM
Subject: Re: [ietf-dkim] Should DKIM drop SSP?
No, DKIM should not drop SSP.
--
Arvel
_______________________________________________
ietf-dkim mailing list
http://dkim.org
Ned Freed
2005-10-27 00:58:54 UTC
Permalink
Post by Hallam-Baker, Phillip
No, DKIM should standardize both SSP and the message format.
Agreed. SSP needs to be standardized.
Post by Hallam-Baker, Phillip
SSP will be used regardless.
Yep.

Ned
Hector Santos
2005-10-27 03:30:50 UTC
Permalink
[note: FWIW, due to Hurricane Wilma and south Florida commercial power
damages, our company server T1 is down. So I'm using a temporary address
from another source for this list.]

Doug,

I must admit it is hard to follow your thinking.

The way I see it, DKIM is not about interpreting the intent of the sender,
but rather the consistency of the transaction. In other words, how bad of a
liar is the sender and can we detect his lies?

Today, without a doubt, by far, "bad actors" do not attempt to play straight
simply because the current protocols (primarily x821, x822) allow for
"unexpected" verification of the transaction data. This is why by industry
estimates over 60-80% of all transactions are simply "bad."

The SMTP industry has two choices:

- Totally revamp SMTP (i.e. SMTP 3.0), or
- Augment it with new EMAIL security ideas which addresses
the verification (authentication) concept.

Independent of varying opinions, A federal law was passed called CAN-SPAM
which in my view, was a compromise with one major (idealistic) goal - to
allow for commercial direct marketing as long as they didn't lie or
intentionally attempt to "hide" their transactions. Other requirements were
imposed for the right to "spam", but for the most part, the key idea was to
minimize the "liars" and to improve trackability.

So as a SMTP vendor, I really don't care what your mail is about, who is
from, etc, as long as you are who you say you are and if need be, you can be
contacted and/or mail can be returned (bounce). In other words, "play by
the rules" of the transport and email system.

The first thing we added was a CBV (Callback Verifier). The CBV is a
backward compatible SMTP callback to validate the provided return path -
spoofed or zombie, again, the concern was that it is a technically valid
address - not whether you are a good or bad person. Of course, if the valid
was deemed bad, then the transaction was instantly rejected.

Since a CBV is a high overhead consideration, we looked for new ways that
can pre-empt the CBV process to avoid the overhead.

SPF was the direction so it was added. Although I believe SPF is a good
idea, it is not a perfect solution. My concerns were stated from the onset
and the concerns were proven correct. The two concerns were:

- Dearth of mixed domain policy conflict protection, and
- Unrestricted Relaxed Policy Domain Definition and Exposure.

The only reason relaxed policies existed were due to the known potential
forwarding problems where you have IP::DOMAIN relational transition point.
But even before you have this potential problem, you also had inconsistent
transactions which could go unchecked with SPF classic (i.e, HELO domain is
spoofed, but MAIL FROM domain passes the SPF test - mix policy transaction).

The one thing I believed very strongly about SPF or for that matter, any of
the LMAP based proposals where a IP::DOMAIN assertion is made, is that the
best protection is obtained when using LMAP for your own DOMAINS. In other
words, SPF works 100% to protect your local domains. There is no doubt
about this. However, it works less than 100% for remote domains SPF
checking simply because you don't have a verification concept. You can
trust your own domain setup. You don't know about remote domain setup or
trust it.

SUBMITTER and SENDERID were proposed to address the transition point issues.
SUBMITTER is 821 based and SENDERID is 822 (payload) based. SUBMITTER was
viable but as defined conflicted with user privacy issues. With SENDERID, I
still don't see the technical merits of this proposal and I strongly believe
this is one proposal that can create more harm than good.

Which brings me to DKIM.

After it is all said and done at the SMTP protocol and the transactions
passes all minimal checks you made have at the SMTP level, the remaining
consistency check is with the payload.

So to me, DKIM with a strong SSP checking concept, provides another level of
transaction consistency checking that may be used by the SMTP-DATA or
POST-SMTP process to perform a final PAYLOAD check. I don't believe this
checking should include a "REPUTATION" concept at this level. I think "DKIM
signing consistency" is the key goal.

I believe that once this done, widely adopted, it will begin to put a major
dent in combating the "bad liars." You will not address the "good liars"
(spammers who use DKIM), but this begins to change the spammers to move
towards our direction. Even DKIM proves to be a strong deterrent and
spammers will simply ignore it, the GOOD DKIM signers will be protected.

I also believe REPUTATION can also be added later. Although I think
REPUTATION is better suited at the SMTP IP/DOMAIN level, I can also see it
a version of DKIM with REPUTATION added.

But even with REPUTATION, your transaction must be consistent. If its not
consistent, then reputation should not be used as a way to bypass or
override a bad transaction.

In all cases, it is about verification of the transport process entities and
since we lack this with the current SMTP protocol, augmenting it with DKIM
should at the very least be strongly offer a consistency model, not a weak
one.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Douglas Otis
2005-10-27 22:04:27 UTC
Permalink
Post by Hector Santos
So as a SMTP vendor, I really don't care what your mail is about, who is
from, etc, as long as you are who you say you are and if need be, you can be
contacted and/or mail can be returned (bounce). In other words, "play by
the rules" of the transport and email system.
Fortunately, the policies established by the recipient can be much
stronger than those established by the government or SMTP vendors.
Playing by the rules should include not sending unsolicited bulk email.
Post by Hector Santos
So to me, DKIM with a strong SSP checking concept, provides another level of
transaction consistency checking that may be used by the SMTP-DATA or
POST-SMTP process to perform a final PAYLOAD check. I don't
believe this
checking should include a "REPUTATION" concept at this level. I think "DKIM
signing consistency" is the key goal.
I am not against the repudiation aspect of non-signed messages. The
objection results from not considering which domain introduced the
message. The current SSP is not compatible with current email
practices and aimed specifically at establishing unfair reputation
assessments on email-address domains, rather than signing-domains.
Ask yourself why SSP precludes a signature that is is not bound to
some email-address. There could still be assertions that all servers
within a domain signs all messages. See I-D.crocker-csv-csa-00 for
an example.
Post by Hector Santos
In all cases, it is about verification of the transport process entities and
since we lack this with the current SMTP protocol, augmenting it with DKIM
should at the very least be strongly offer a consistency model, not a weak
one.
DKIM should identify the domain associated with the email message
transport. It is over-reaching, to say the least, when attempting to
use this mechanism to verify the author of the message. Leave that
effort to OpenPGP and S/MIME. By establishing the accountable
domain, abuse can be handled in a more efficient manner than it is
today. This would also afford opportunistic identifications akin to
that used with SSH. I don't think this aspect has been given any
consideration.

-Doug
Hector Santos
2005-10-28 11:18:52 UTC
Permalink
----- Original Message -----
Post by Douglas Otis
DKIM should identify the domain associated with the email message
transport. It is over-reaching, to say the least, when attempting to
use this mechanism to verify the author of the message. Leave that
effort to OpenPGP and S/MIME. By establishing the accountable
domain, abuse can be handled in a more efficient manner than it is
today. This would also afford opportunistic identifications akin to
that used with SSH. I don't think this aspect has been given any
consideration.
Doug, DKIM is like a traffic cop pulling you over and ask for your Driver's
license and Registration. Sure, it can be all fake, but it better be
consistent.

- You appear to be 40-45, but your license shows a birth
year that would makes you 23 years old?

- You are white, your photo shows you as Afro-American?

- You are a women, your photo shows a bearded man?

- your registration VIN does not match your car VIN.

etc, if anything is inconsistent, you will be immediately scruntized.

Either way, he is required to check your information against the central
databases for the validity of the license and also for any outstanding
tickets, warrants, etc. This is the 3rd entity in the picture that
validates the process. You (Sender), the cop (receiver) and central
database (DNS).

In the end, he *should* be turning a blind eye on WHO you really are. You
could be the Mayor of the town and you might have a dead body in the trunk.
He shouldn't care as long as you are playing by the rules. But if you raise
a raise flag, then that begins a new process of actions that could be taken.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Eliot Lear
2005-10-28 11:34:47 UTC
Permalink
Post by Hector Santos
- You appear to be 40-45, but your license shows a birth
year that would makes you 23 years old?
- You are white, your photo shows you as Afro-American?
- You are a women, your photo shows a bearded man?
Heck, a lot can happen in 20 years!

Eliot
Hector Santos
2005-10-28 11:35:56 UTC
Permalink
----- Original Message -----
Post by Eliot Lear
Post by Hector Santos
- You appear to be 40-45, but your license shows a birth
year that would makes you 23 years old?
- You are white, your photo shows you as Afro-American?
- You are a women, your photo shows a bearded man?
Heck, a lot can happen in 20 years!
Touché! :-)

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Stephen Farrell
2005-10-28 11:30:39 UTC
Permalink
Doug,

This thread doesn't really appear to be going anywhere.

Someone earlier asked you to provide examples. Why don't
you do that in a new thread - just an example showing the
worst bad effect you claim but without the extensive
discussion?

Stephen.
Post by Douglas Otis
So as a SMTP vendor, I really don't care what your mail is about, who is
from, etc, as long as you are who you say you are and if need be, you
can be
contacted and/or mail can be returned (bounce). In other words, "play by
the rules" of the transport and email system.
Fortunately, the policies established by the recipient can be much
stronger than those established by the government or SMTP vendors.
Playing by the rules should include not sending unsolicited bulk email.
So to me, DKIM with a strong SSP checking concept, provides another level of
transaction consistency checking that may be used by the SMTP-DATA or
POST-SMTP process to perform a final PAYLOAD check. I don't believe
this
checking should include a "REPUTATION" concept at this level. I think "DKIM
signing consistency" is the key goal.
I am not against the repudiation aspect of non-signed messages. The
objection results from not considering which domain introduced the
message. The current SSP is not compatible with current email
practices and aimed specifically at establishing unfair reputation
assessments on email-address domains, rather than signing-domains. Ask
yourself why SSP precludes a signature that is is not bound to some
email-address. There could still be assertions that all servers within
a domain signs all messages. See I-D.crocker-csv-csa-00 for an example.
In all cases, it is about verification of the transport process entities and
since we lack this with the current SMTP protocol, augmenting it with
DKIM
should at the very least be strongly offer a consistency model, not a
weak
one.
DKIM should identify the domain associated with the email message
transport. It is over-reaching, to say the least, when attempting to
use this mechanism to verify the author of the message. Leave that
effort to OpenPGP and S/MIME. By establishing the accountable domain,
abuse can be handled in a more efficient manner than it is today. This
would also afford opportunistic identifications akin to that used with
SSH. I don't think this aspect has been given any consideration.
-Doug _______________________________________________
ietf-dkim mailing list
http://dkim.org
Jeff Macdonald
2005-10-29 02:33:24 UTC
Permalink
Post by Stephen Farrell
Doug,
This thread doesn't really appear to be going anywhere.
Someone earlier asked you to provide examples. Why don't
you do that in a new thread - just an example showing the
worst bad effect you claim but without the extensive
discussion?
I'd like some concrete examples too.
wayne
2005-10-27 04:02:17 UTC
Permalink
Post by Douglas Otis
One could view DKIM as a mechanism that establishes an accountable
domain for the messages contained within the email message transport
system. By limiting the scope of DKIM to being a mechanism that
provides an accountable domain for the transport system, a great deal
of benefit can be derived without threatening the integrity of the
transport system. [...]
I don't think that DKIM should drop SSP.

That said, let me play devil's advocate for a bit.


Experience with SPF has shown that there *will* be people who will
reject email because they didn't receive an SPF PASS result, even if
that result is NEUTRAL. These same people will not reject email
just because there weren't SPF records found, even though that is
supposed to be the same meaning as an SPF NEUTRAL result.

Because of this, there *are* be people who will either not publish SPF
record, or will withdraw publication of SPF records because any
failure to authenticate a message, for any reason, could cause a
legitimate message to be rejected.

One of the reasons why Tripp Cox gave for removing SPF records for
Earthlink was "SPF and SenderID posed serious risks to the
deliverability of legitimate email. We believe it is better to publish
no record at all than to publish a record that may be subject to
misinterpretation."[1] Before Tripp removed Earthlink's SPF records,
their records ended with "?all", which should have given NEUTRAL
results for any email that didn't get an SPF PASS. According to the
specs, there is no way that Earthlink's SPF record should have hurt
any more than not publishing any SPF record at all.


So, you can rest assured that the mere publication of SSP information
will cause some people to reject email from the domain that hasn't
been signed, has been signed but fails to validate, or has a third
party signature even if it is approved. You can also expect some
people to reject that has valid DKIM signatures, but no SSP
information.

Some people, maybe even major players, will refuse to publish DKIM
records because it may cause legitimate email to be rejected, even if
they publish the loosest of requirements.


I think there could be a reasonable level of demand for a solution
that could only give positive results. One that makes it so that you
really can't easily tell if a message that doesn't validate is because
the validation failed, or because it is like 99% of the email today
that never could have been validated.


I'm not sure that simply removing SSP from DKIM would be enough, since
there will still be some people who reject email based on signature
failures alone. However, including SSP will certainly give people who
what to take a very hard line to reject more legitimate email because
it doesn't pass with flying colors.

I suspect that people who are too scared about legitimate email being
rejected to publish SPF or DKI/SSP records, but want some form of
authentication, will need to stick with something like DNS whitelists
or HELO checking.


</devil's advocate>


-wayne

[1] http://www.trippcox.com/blog/archives/2005/08/much_ado_about.html
Hallam-Baker, Phillip
2005-10-29 03:01:22 UTC
Permalink
Post by Hector Santos
Doug, DKIM is like a traffic cop pulling you over and ask
for your Driver's license and Registration. Sure, it can be
all fake, but it better be consistent.
- You appear to be 40-45, but your license shows a birth
year that would makes you 23 years old?
- You are white, your photo shows you as Afro-American?
More bad news for Michael Jackson
Hector Santos
2005-10-29 03:07:32 UTC
Permalink
----- Original Message -----
Post by Hallam-Baker, Phillip
Post by Hector Santos
Doug, DKIM is like a traffic cop pulling you over and ask
for your Driver's license and Registration. Sure, it can be
all fake, but it better be consistent.
- You appear to be 40-45, but your license shows a birth
year that would makes you 23 years old?
- You are white, your photo shows you as Afro-American?
More bad news for Michael Jackson
How funny I picked a profile that might actually be one of a kind. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
Loading...