, selector, data-hash)
where:
body-hash: is the output from hashing the body, using hash-alg.
It is set as the value of the bh= tag in D-SIG for computing
the data-hash.
?
Sounds technically correct. +1
--
Hector Santos, CTO
http://www.santronics.com
http
was also possible. The key point is for 40 years, it wasn't a
problem until a new kid in the block came and now demands MLMs adjust
to work with it
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL
Hector Santos wrote:
The document editor and others believe this is a MLM BUG. It could
be, but we don't know if its really an normal attempt to add HEADER
text that was empty:
Create List Message for Distribution:
Body = EMPTY;
Body += AppendText(GetHeaderNoticeForList
Hector Santos wrote:
Hector Santos wrote:
The document editor and others believe this is a MLM BUG. It could
be, but we don't know if its really an normal attempt to add HEADER
text that was empty:
Create List Message for Distribution:
Body = EMPTY;
Body += AppendText
relaxed, less secured, with a wide degree of
receivers, minimized C14N related issues with an
relaxed algorithm.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
inapropiate that's cool but I'm frankly not convinced.
I'm OK if there's consensus not to change it, but the wider scope of
IETF LC and cross-area review is exactly to catch things that the WG
didn't.
+1
--
Hector Santos, CTO
http://www.santronics.com
. In that vain, we have
a form of whitelisting.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hector Santos wrote:
Hector Santos wrote:
The document editor and others believe this is a MLM BUG. It could
be, but we don't know if its really an normal attempt to add HEADER
text that was empty:
Create List Message for Distribution:
Body = EMPTY;
Body += AppendText
to be extensible, anyone feeling that
an
additional algorithm is warranted is free to define it and seek community
consensus for it.
d/
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
of having errors when it comes to C14N.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to the MLM I-D would be very informative to readers of the
document which would include MLM developer considering all the DKIM
incompatibility issues.
--
Hector Santos
http://www.santronics.com
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
John R. Levine wrote:
Hi Hector,
At 15:20 14-05-2011, Hector Santos wrote:
Shouldn't the MLM I-D say something regarding C14N and CR/LF related
mutations?
No.
+1 to the No.
I have my reservations about the draft, but this is not one of them.
In general, I would say NO too because I
, Hector Santos wrote:
Shouldn't the MLM I-D say something regarding C14N and CR/LF related
mutations?
No.
+1 to the No.
+1 to the No.
This is a software problem,
You mean the MLM who is ignorant of DKIM meta data for the past 40
years?
not something that needs to be solved by creating
SM wrote:
Hi Hector,
At 21:40 14-05-2011, Hector Santos wrote:
Can't share the wisdom why?
It's merely an opinion. Please see Murray's comment about a slippery
slope.
I understand the point. But we are doing all this already like section
3.3 Current MLM Effects On Signatures; Minor body
Agent (MUA) or MTA sending mail to the MSA or MDA.
Anyway, its a nit and just thought it was not necessary nor correctly
applied here.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
in section 3.3 titled
Current MLM Effects On Signatures
regarding a real living, walking and running MLM behavior?
This is surreal. Don't shoot the messenger, listen to the message!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Dave Crocker wrote:
+1
mail queues. Talk about slippery slopes. Anywho, I just
don't get it. Very different mindsets/thinking here. But hey, if
people think it helps unix people
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE
John R. Levine wrote:
There's no need to change the current language. RFCs have been
referring to cron jobs since 1997.
But this is 2011 for G-d sake!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL
are saying the
RFC5322 author is also the OS logged in username which cron uses as
a default as an environment variable for any mail scripting events.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
about the real MLM/DKIM
incompatibility issues and intentionally wants to hide this insight
that could promote changes.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
for sending mail to an originator.
Do you hate windows or know that Windows is still a major OS? or that
even other OSes may exist with the same scheduling tools ideas? MLM
is not exclusive to Unix systems.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
5.8.0 Undefined Policy detail
554 5.8.1 Message refused by local policy
or perhaps Murray can propose to Jeff to add a 5.8.27 status code
specifically for ADSP related policy rejects:
554 5.8.27 Message refused by ADSP From.Domain=IDENTITY-ODID
--
Hector Santos, CTO
http
don't see 550 there.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Hector Santos wrote:
Murray S. Kucherawy wrote:
But to be conformant, I suppose 550 5.7.0 would be appropriate.
Alessandro Replied:
Conformant to what?
RFC5321, as cited.
See section 4.3.2
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
SM wrote:
Hi Hector,
At 11:43 14-05-2011, Hector Santos wrote:
See section 4.3.2
DATA
I: 354 - data - S: 250
E: 552, 554, 451, 452
E: 451, 554, 503
From http://www.rfc-editor.org/rfc/rfc5321.txt
DATA
I: 354 - data - S: 250
SM wrote:
Hi Hector,
At 15:23 13-05-2011, Hector Santos wrote:
I am wondering if anyone else can confirm BODY HASH errors with the
originating author domain DKIM signature mail submitted to the
IETF-SMTP fora.
Yes. It may be an extra line between the message headers and the body
signatures coming from Aliasing list streams with
slight CR/LR mutations.
--
HLS
Hector Santos wrote:
SM wrote:
Hi Hector,
At 15:23 13-05-2011, Hector Santos wrote:
I am wondering if anyone else can confirm BODY HASH errors with the
originating author domain DKIM signature mail submitted
referred to as the
Mail Delivery Agent (MDA).
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
be viewed as a SMTP 550 no local user account
rejection.
Comments?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
SM wrote:
Hi Hector,
At 15:20 14-05-2011, Hector Santos wrote:
Shouldn't the MLM I-D say something regarding C14N and CR/LF related
mutations?
No.
Can't share the wisdom why?
I hate kludges but the insight for interested DKIM verifiers may help
increase valid signatures coming from
, Bonjour, Cheerio!, Catch you later, see ya on the
rebound, Bye Bye!
Ian Eiloart wrote:
On 12 May 2011, at 17:44, Hector Santos wrote:
For the record, the old MLM was read as well Levine's poison pill MLM.
With no intent nor suggest the writer is stupid, writers do say stupid
things
it hasn't done in
40 years.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
header.s=smtpout;
I was thinking it was an C14N issue, but the first two are
simple/simple and the last one is relaxed/relaxed.
What could be hidden in this body that is different?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Hector Santos wrote:
Nothing wrong with DKIM=DISCARDABLE. What is wrong is trying to
dictate to others MLM should ignore ADSP.
As a MLM vendor, I have technical and ethical engineering obligation
not to cause problems when taking on a new inherently incompatible
technology that doesn't
- resign.
But I object to the idea it is an unrestricted resigning model only
and I firmly believe it will harm the general wide best interest of
the IETF mail community and DKIM itself if we allowed this to be the
one way ticket.
Is that any more clear?
--
Hector Santos, CTO
http
of the user or author domain policies, you have what now?
FAIL
SOFTFAIL
UNKNOWN
DKIM is the the same boat as any other policy based technology
yielding indeterminate results.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
for RFC4871bis to close the issue.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
Considering how little of the advice is based on actual practice, even BCP
is a stretch.
G-d! and I was deathly afraid to comment on the same thing! So I'm
happy you said it!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
.
That original background last paragraph text just isn't the truth
and it doesn't fit with the other discussions regarding Author Domains
and references to ADSP - can't have it both ways.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
and me showing real examples for the
interoperability problem - it was only then that gave life to this
document.
Rough consensus in the group really doesn't match the many concerns
over the years with this issue and its unfortunate they aren't around
anymore to express their input.
--
Hector
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Hector Santos
Sent: Wednesday, May 11, 2011 2:34 PM
To: Barry Leiba
Cc: DKIM List
Subject: Re: [ietf-dkim] DKIM and mailing lists
After all
than
it
has been in the past and there's no new material.
d/
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
be part of the fee schedule
for the service. This will cater to domains with an fast DKIM entry
point who do not wish the deal with the internal overhead and cost to
setup/maintenance DKIM.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
or revoke a trusted signer who was breached.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
of this has to do with the business use cases for the author
domaina the DKIM signing service providers and how they are able to
expose that information in general or contractual.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
approve the
result, so I expect that'll take another two weeks or so -- say, until
11 June.
Have at it.
Barry, as chair
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
http
to operators.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
of using this tag and have a complete awareness of the
the intermediary (i.e. mailing list) message integrity
handling practice including verifiers have the technical
option to ignore the body length l= tag or perhaps handled
based on advanced criteria or usage limits.
---
Hector Santos, CTO
to such anonymity have
already long been the part and the source of the problem.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Model illustration?
Oh well.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
actively
counter-productive.
See above.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
functionality not be disabled in the hope of providing
some small margin of protection against an ignorant domain who is
trying to submit fake mail.
Maybe we should remove ignorant so it still applies 10 years later.
--
Hector Santos, CTO
http://www.santronics.com
http
domains?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
signing bit, but it is WRITTEN in the technical
specification as a MAY for Output.
I believe I am more RIGHT here than David and Murray and you.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
we can actually deprecate l=.
Barry, as participant
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
-
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
to spam.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
identity,
including the originating author domain.
Anyway
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
appended
to the body, the l= tag SHOULD NOT be used. (See Section 9.1).
My post list all the references to l= for reading and setting.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
needs to be more open with DKIM Complete information
for receivers to better consider.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun
semantics such as user part considerations and all we wanted here as a
ADSP functionality.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf
open with DKIM Complete information
for receivers to better consider.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf
technical subjective
semantics such as user part considerations and all we wanted here as a
ADSP functionality.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
Rolf E. Sonneveld wrote:
On 5/5/11 1:52 AM, Hector Santos wrote:
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From: address. This identity
MAY be considered as an output communicated to an advanced
Identity Assessor module.
INFORMATIVE
even with the receiver is willing to honor ADSP and author domain
policies?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
:
Optional Agent or User Identity: _
when they press SAVE, I have to decide what to do, like Popop Warning box:
Warning, the Public Key for this signer/selector must has
a t=s tag
Continue to Save: Yes | No
--
Hector Santos, CTO
http
section 3.9
This is what happens when you add something in the last minute without
any consensus. It was just added - no consensus.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
in
indirect and ambiguous ways we know offer utility.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Architecture. RFC4871bis does not reflect what
receivers need for security controls.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
.
You need to rethink why reasonable compromising solutions offered
should be ignored and rudely shunned out. You need to consider good
nature WG participant perspectives to help DKIM better fit receiver
needs and considering ODID (and AUID) is compatible with the DKIM goal.
--
Hector Santos, CTO
. Instead we have:
#3 NEW: RFC4871BIS Output requirements that do not reflect any other
work that as done, including this so called DKIM Service Architecture.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL
I believe are the four minimal extracts for DKIM output
and mail integration:
signature verify status
SDID
AUID
ODID
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
and does not represent current implementations.
This may not be an interest to you, but it to others.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Dave CROCKER wrote:
On 5/4/2011 9:15 AM, Murray S. Kucherawy wrote:
My read is that Rolf is objecting to RFC4871bis
Hector Santos wrote:
Murray wrote:
This is completely appropriate in another way: The SDID from a valid
signature is the only thing that DKIM proves.
Ok, very good. It tells you the payoff value for SDID and its ok, to say
its a mandatory identity receivers to look at. but its should
, including does
related to security.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Missing citations for the quotes below:
[1] http://www.messagesystems.com/wordpress/?p=65
[2] http://www.messagesystems.com/wordpress/?p=69
Hector Santos wrote:
Dave CROCKER wrote:
Given the continuing, intense attention to DKIM that is taking place at a
variety of vendues, such as MAAWG
which no one should take for granted - even
marketers are finally get that point.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
3.9 should state these minimal DKIM related output
purpose is to get a Security and/or Trust Evaluation.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
you want. But you have the
others too.
What is technically wrong with this?
--
Sincerely
Hector Santos
http://www.santronics.com
Dave CROCKER wrote:
On 5/4/2011 2:47 PM, Michael Thomas wrote:
On 05/04/2011 02:32 PM, Dave CROCKER wrote:
On 5/4/2011 2:29 PM, Michael Thomas wrote:
I
up to you to
reduce the conflicts with proposed compromising text. Murray, I am
not your problem as much you believe, insist it is.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates
of signature validation result codes.
You might be able to figure out better text.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
labeled as DKIM=OPTIONAL because if someone
went to extent to declare a record, it wouldn't be unknown what he
intended.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
will need a fall back with ODID.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
(FAIL). I don't wish to combine those as UNKNOWN.
In short the combinations of inputs and outputs allows for all states
to exist.
Note, these are all part of the semantics ambiguities discussed in the
past regarding ADSP. I hope we can fix it.
--
Hector Santos, CTO
http://www.santronics.com
http
Alessandro Vesely wrote:
On 01.05.2011 10:38, Hector Santos wrote:
Again, its about protocol consistency. So maybe I should ask the
chairs for:
Consensus needs to be reevaluated
IMHO, it needs not: It is premature to define an ODID now. ADSP is
considered somewhat broken
Hector Santos wrote:
IMV, ADSP is only broken in that it didn't allow you to declare you
were allowing mipassoc.org to sign for you or in general
My Mail Is Always Signed - by me or someone else.
By the way Alessandro, you could explore ADSP/ATPS support from your
record. Use
, just say
its an optional part of the total DKIM Service Architecture. Just
like VBR is, just like A-R is.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
for the DATA payload.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
or is a sub-domain
of it. If the public key contains t=s, then the domain name MUST
be the same as SDID. For DKIM processing,
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
are
using the DKIM recommended A-R reporting method and needs the AUID as
part of a DKIM Complete Outputs.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
Agent or User.
Who/What is an Agent? Undefined?
Who is the User? I presume the RFC5322.From? No?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
l= is
mentioned, you will see sentences with inferences for an expectation
it is present and/or should be added. These sentences need to be
reworded to indicate it is an option and not an expectation.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
in peace. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
and ergonomically (UI) claim
the author is trusted whether or not the signer had any association
with the author or not.
Again, its about protocol consistency. So maybe I should ask the
chairs for:
Consensus needs to be reevaluated
--
Hector Santos, CTO
http://www.santronics.com
http
that are resigning, the
l= concern is gone as long as the ODID (Originating Domain Identity)
accepts the independent MLM DKIM resigning role.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
Michael Thomas wrote:
Dave CROCKER wrote:
On 4/30/2011 9:10 PM, Hector Santos wrote:
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From
Hector Santos wrote:
Murray S. Kucherawy wrote:
Hector stated:
I think this message by Barry in March 2009 summarizing a conference
call between Pasi, Stephen and Barry nicely captures the upper/lower
layers, ADSP, i= and outputs conflicts that continue today:
http://mipassoc.org
not need to add the l= tag to the signature
if they are signing the entire body.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
701 - 800 of 2143 matches
Mail list logo
