SM wrote:
> Hi Hector,
> At 16:57 17-09-10, Hector Santos wrote:
>> Do you recall what was the average turnaround time? Its been 10 mins
>> or so. Hmmm, maybe it was greylisted. I should whitelist the address.
>
> The turnaround time should be less than five seconds unle
Nate Itkin wrote:
> On Fri, Sep 17, 2010 at 05:48:37PM -0400, Hector Santos wrote:
>> Yeah! Finally got DKIM+ADSP implemented into our mail software, but we
>> not signing yet, just verifying and prepending a A-R header.
>> When I begin signing are there some sites where we ca
Yeah! Finally got DKIM+ADSP implemented into our mail software, but we
not signing yet, just verifying and prepending a A-R header.
When I begin signing are there some sites where we can send signed
mail to verify and get feedback?
Thanks
--
Hector Santos, CTO
http://www.santronics.com
http
for Author Domains to
describe a signing practice that is not exclusive (1st party only).
--
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
else. This would be more of
business model function than a technical protocol function.
--
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
y a large commercial MTA.
PS: The request has already been made to get the specifics on the
implementation change.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mi
ch it
and in software, make it a default header among the list of headers to
be signed.
--
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
m, scams and phishes from both and
mixed, from little guy signed by yahoo.
--
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
;s opinion to do
the same thing you wish to do freely.
--
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
o add third party signing practices?
Thanks
--
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
he
IETF, "Running Code" and open source DKIM API (which mean
other MTA must be using it) naturally follows #1
4) Resigners (New and Legacy) are not listening to ADSP,
so #1 doesn't apply, thus forcing #2 and #3.
Just providing input to help codify the eng
uired: list.example
X-DKIM-Signature: d=example.com h="From:DKIM-Required"
DKIM-Signature: d=list.example.com h="From:DKIM-Required"
X-DKIM-Signature means that it was stripped and/or nullified in the
in distribution. Illustrated above to show there was a change.
ge MTA vendor revised there open source software three years later
presumably after extensive field operations to include a new option to
relaxed the 5322.From binding.
> - 1.
Thanks for your input.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Thanks Tony. Glad I asked because I had coded software and was
proceeding with "x-" due to not sure by the reading of the 5617 but
read other ADSP extension I-Ds today that did not use the prefix.
Thanks again
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.bl
To: John Levine et al
I am working on a ADSP I-D extension which adds a new tag "ASL"
Should the tag contain the "x-" prefix? Example
dkim=all; x-asl=x;
or
dkim=all; asl=x;
Which would be correct to document the I-D?
Thanks
--
Hec
n
> this mailing list, it seems that the arguement was about reducing the
> amount of bounces.
Small nit: "as the AUTHOR DOMAIN encouraging me to discard ."
--
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
erifiers/receivers.
Real good Charles.
My nit would be it lacks a security section. I think you need to
provide a rational why this proposal ... whats the proper word here,
pick one
violates, ignores, skips, circumvents
the security framework policy attempts to provide for the author d
om
DKIM-Required: thirdparty.com
DKIM-Signature: d=thirdparty.com h="From:DKIM-Required"
Is this proposal a method to expose the thirdparty.com as an
"authorized" signer?
I am not clear with the rational in the verifier procedure itemized in
section 3 &quo
might accept my email and apply a convincing signature for
> you!"
Agree, it does expose your "friends," but wouldn't you be first party
protected on the submission (assuming the MLM is ADSP compliant and
why one would put it in their ASL)?
ent for
large companies with many employees using different list servers. I
think it fits the millions more market place of small to mid size
domains or private domains that may outsource a one or more third
party signers or use a few professional or trade support list forums.
If you t
nvey
what the domain holder considers the likely survivability of the
practice for a receiver, in particular receivers that may be more
than one SMTP hop away.
o DKIM Signing Complete: a practice where the domain holder asserts
that all legitimate mail will be se
quot;
DKIM-Signature: d=mach1.signer.com
Is there a requirement the dkim.d domain must be a valid email address
domain? Yes for 1st party, but what about the third party?
If this is for the purpose of hiding original ADSP restrictions to
help push mail to list members, wouldn't this be cre
ation the ADSP=ALL policy as an always
sign by author domain or (any) 3rd party domain.
These adaptations by the major MTA vendor DKIM API is exactly what we
are looking for. They learned what needs to be done to better
implement DKIM and ADSP support. I believe they
m bind and
allowed for 3rd party signature policy declarations. (Note, just in
case, I am not referring to the problematic authorized signers
considerations.)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
> There was very little respon
ng the author domain, 3rd party signers
and/or list servers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This li
+1.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Steve Atkins wrote:
> On Sep 14, 2010, at 12:35 PM, J.D. Falk wrote:
>> Yes, I know it requires more effort, but what we've been doing so far
>> clearly isn't working.
> The problem
ty signing issues might help,
or perhaps getting a new editor for ADSP to fix its bugs might work too.
Either way, you have to open your mind on POLICY otherwise it is a
waste of time, but the issues don't go away.
Moving DKIM to experimental status might work too until we figure out
how
the ietf-domainrep list for discussion.
Brett,
Please feel free forwarding it there is you feel it will might be
useful. I, myself, getting wiry of the personal attacks so I think I
will begin to step back.
Thanks for the comment.
--
Hector Santos, CTO
http://www.santronics.com
htt
evel checks are skipped. It is
the unsolicited unauthenticated sessions where security checks best
applies.
--
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
with only a guessing game and/or need to
get receivers to use a common reputation service, with an propensity
to serve only certain high value domains to have a greater "meaning"
over the general population of domains.
Low or high value, all domains have to be treated with a fundamental
e
to how it integrates with the rest of the
world, namely list system. You could only tell people to ignore it or
move it to experimental.
No, POLICY isn't the problem - ADSP is!
Hey, you wrote it - FIX IT!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_
IM signatures deterministically. I don't feel
we are there yet but it ain't going to happen until the concept of
POLICY is better accepted especially by the reputation advocates.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
McDowell, Brett wrote:
> H
t will not
cover those who do not add a LIST-ID.
Check ADSP would also be made an option just in case it becomes
deprecated.
The ACCEPT-DISCARD will probably be made an option with a default of
true, otherwise it would be a REJECT.
--
Hector Santos, CTO
http://www.santronics.com
http
lient/server framework. The MLM saves an centralized
"list address acceptance" list file, including subscribe/unsubscribe
list addresses for the SMTP servers to use at the RCPT level.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
__
and I'm sure it will interesting, but
I don't see what its going to show beyond what was already know.
Anyway, this went off course.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing lis
AR!"
We don't need more DATA to see there is a problem and a wide spread of
indeterminate situations. Engineering intuition tells us we need a
solid deterministic backbone design and protocol protection layer for
DKIM again, and let the rest be based on that.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
l path either because of ADSP or to
provide the "positive appearance of 1st party mail."
Its a vicious cycle. We'll figure it out one day. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
dy hash seems fine though, but not the
signature. It appears no one really has done any real confirmation on
verification outside the yahoo distribution - the main reason the
customer went with this 3PS vendor.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
en
> that message should be discarded even though it would otherwise be
> legitimate.
Too logical Michael. :)
Some would rather not support ADSP yet acknowledge it by changing the
5322.From (a more drastic earth changing behavior) as a solution to
THEIR ADSP problem. HA!
Suddenly I got an urg
you want to change the from because of
ADSP? Sounds very odd.
--
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
How do you verify the authorization?
Is this FUD?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
d.
NFC - funny! Just as good as Murry's Cacophony! :)
Well, one thing for sure with such a cacophony and swamp environment,
before venturing into such a document, maybe the first rule should be:
"He who dares to write a document (of any status) better believe in
it!"
--
Hector Sa
u MAY alter the FROM when its was DKIM signed
but you need to break the signature
and tomorrow, you will find NON-DKIM reasons or worst no reason for
changing the From.
How will know when the original author was lost?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blog
rom header. Only then will it make
sense. But I still think you will never break the ultimate
association: From::Message that everyone sees, regardless of who signs.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
- separate the mail channels. Use a
entirely different domain you don't care about and try to see if this
is good enough to warm up the 3rd party signers with special vouchers.
No easy answer but to bring back some sort of 3rd party authorization
consideration.
--
Sincerely
ING games with DKIM signed
mail.
--
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
igh value domain like paypal when it begins
to negatively warm up systems that don't have an association with a SSA.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
dkim-ops mailing list
dkim-ops@mipassoc.org
http://mipassoc.org/mailman/listinfo/dkim-ops
y to be more wary of cousin domains and to recognize
>> paypal.com and trust its subdomains more than they should in this case.
>>
>> -Doug
>> ___
>> dkim-ops mailing list
>> dkim-ops@mipassoc.org
>> http://mip
Steve Atkins wrote:
> On Sep 5, 2010, at 1:10 PM, Hector Santos wrote:
>
>> In 2006, I submitted the I-D
>>
>> http://tools.ietf.org/html/draft-santos-dkim-rcvd-00
>>
>> Is there any interest for me to renew this I-D to help address some of
>> the
systems that might want to
support verifiers but are not ready to do it themselves yet - a
migration consideration.
Is there any reason why this proposal would not assist DKIM?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
e used a
migration idea for those systems not yet ready to sign or verify but
can get the information and store in the header in case there will be
a long time-shifted verification period that exceeds the domains key
expiration.
--
Hector Santos, CTO
http://www.santronics.com
http://sant
org/html/draft-santos-dkim-rcvd-00
A proposal offering partial DKIM verification support to help
resolve premature DKIM signature expiration and key revocation
related problems associated with time shifted DKIM verifier
applications.
--
Hector Santos, CTO
http://www.santronics.com
http:
C.ORG have a ADSP policy?
It sounds like a good idea, but it would a very radical change. I
don't wish to be part of the group of MTA and MLM that begin to fuss
around with the 8222.FROM making the mail more unreliable and less
trustworthy.
--
Hector Santos, CTO
htt
party signature?
If AT&T is my cell provider, and they are sending billing statements
with URL hooks to join 'Something' and other stuff, they should be
more concern about what 3rd party clearing house (YAHOO does a long
time PR problem as a source f
J.D. Falk wrote:
> On Sep 2, 2010, at 11:54 AM, Hector Santos wrote:
>
>> I think the issue is that we don't know what the assessors do
>
> Some of us have a pretty good idea. The people who design reputation
> systems don't do so in a vacuum; they're consta
o allow the
self-asserting domain to declare it expectation and policies for mail
distribution if only for one reason - to maintain a high benefit of
1st party signatures while you guys figure out how LIST systems ought
to work.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.co
l happen, but I can only imagine it will create a climate that the
3rd party signer trust is the only that counts and nothing else and
all members have whitelisted the list or has signed up to some common
reputation service - hmmm a POLICY for LIST domains!
--
Hect
al RFC and I-Ds.
That is really all this old frog is looking for. No "Rippet" mas!
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Michael Thomas wrote:
> On 09/01/2010 02:49 PM, Murray S. Kucherawy wrote:
>>> If your goal is to have MLM develop
that unsigned mail should become a pariah -- which I suspect is the
> right thing -- then all of the howls of indignation should just be ignored.
> And as is always the case, the whiners will figure something out if the,
> uh, laser is positioned correctly.
>
> Mike
> _
the
chartered goals.
Accept POLICY as a WG work item and maybe we can come to complete this
work and maybe many more systems can begin to get more DKIM/ADSP adoption.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
e has a BUG in
his software and whether he agrees or not, someone will throw it in
this face - you are violating RFC 5016..
Your MLM has it right Murray. It has all the information a MLM author
needs to go with to do this right.
You guys needs to make your minds regarding poli
should be "fixed" to codify the engineering semantics, if that can't
happen (and doubt it will), a document that puts it all together like
a RFC 1103 for DKIM operations on both the HOST and CLIENT side would
be very valuable.
--
Hector Santos, CT
ds.
Talking about common sense engineering goofs!
The big elephant in the room is unrestricted resigners. The documents,
proposed standard and/or informational are in conflict with dealing
with that issue.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_
raction, hindrance and road block in completed chartered goals.
--
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
Murray S. Kucherawy wrote:
>> -Original Message-
>> From: Hector Santos [mailto:hsan...@isdg.net]
>> Sent: Monday, August 30, 2010 1:00 PM
>> To: Murray S. Kucherawy
>> Cc: ietf-dkim@mipassoc.org
>> Subject: Re: [ietf-dkim] Proposed changes to MLM d
ring
conflicts when a MLM is being asked to IGNORE these WG work products?
--
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
quired engineering consideration for MLM.
To remove can create interoperability problems.
-1. Please No more dependencies on other technologies based on highly
subjective non-scientific presumptions.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Hector Santos wrote:
> The problem? Its no fun adding software with a WG standard that
> won't be followed at the suggestion of its authors.
But that I mean any developers that wish to support the the WG
Documents are put into a catch-22 position regarding DKIM and ADSP
implemen
xploring it before ADSP stripped down SSP and
created a "wait and see" attitude. The problem? Its no fun adding
software with a WG standard that won't be followed at the suggestion
of its authors.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
s. I
see many MTA that added DKIM-CORE signing only but no substance on the
DKIM verifier said.
--
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
he confusion is to honor it first. After that, it can really do what
it whats because it is all now in an indeterminate state that can only
be possibly handled by special signing arrangements.
--
Hector Santos, CTO
http://www.santronics.com
http:/
Hector Santos wrote:
> Dave,
>
> The term "Reputation Filtering Engines" (RFE) is understood in what it
> means. Currently proprietary solutions.
>
> Absolutely wrong with that.
Sorry, missing word - "Absolutely NOTHING wrong with that"
--
Hector Sant
-standard approaches.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Dave CROCKER wrote:
>
> On 8/24/2010 10:43 AM, MH Michael Hammer (5304) wrote:
>> One can assess based on policy rather than reputation. In fact I can
>> think of several com
1 mandate regarding invalid signatures changing to no-signature
status as if it never existed and the message was never signed.
What this means is that if a MLM keeps broken tracings of signatures,
the only existing trace signature is the valid one. All others must
be ignored.
--
Hector Santos,
I'm missing?
>
> So you're saying it can provide the obverse; you just don't like the
> failure modes. Perhaps surprisingly, the failure modes are exactly
> what attracts some folk to DKIM.
+1
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.c
sweet if we can finally get some consistency Dave,
for all parties across the board.
--
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
Michael Thomas wrote:
> We showed that over 90% of mlm signatures could be verified.
Any insight, breakdown or feel for that 10% failure? Multiple hops
for downlinks? More resigners, buggy DKIM verifiers? Was these all
DKIM or did it include DKEY?
--
Hector Santos, CTO
h
A continuation of
iffy iffy mail world with the biggest beneficiaries - the BAD GUYS who
will continue to do nothing to remain in a iffy iffy mail world.
Again, just background noise. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
__
believe is the only
situation where he has to cut out the other addresses.
--
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:
> John R. Levine wrote:
> Let me try LiveMail because I have an alias LiveID (hotmail) account
> for this group No. If interested, this is what I see with
> LiveMail showing this message:
>
> http://beta.winserver.com/public/files/levine2.png
o say here john. :)
If you like, send a direct test message to hl...@hotmail.com so I can
see how LiveMail shows your S/MIME signed mail.
--
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
idea can take advantage of that, but it should
the MTA that does this and not depend on all original mail authors
using S/MIME to sign their mail first in their MUAs. Maybe the I-D
can include a provision for recommending a MSA for adding it - but
isn't that somewhat what
roblematic issue to address for this WG.
--
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
our 100% exemplifies all the
concerns and also benefits POLICY proponents have been advocating.
You had an expectation for mail operations, a POLICY regarding S/MIME
expectations, yet that expectation failed.
Allow people to expose that expectation using standard methods, and
"recei
Honestly, no assumption of ignorance. I did have a few variations
"You're joking?... This is a joke right? ... Yeah right!" etc. But
you're right, I missed any subtlety and should of left it alone. I
apologize to anyone who felt offended for the Binding 101 lesson. :)
--
HLS
Mark Delany wrote
ks the bind.
Since 5322.FROM is a required binding for DKIM, it means you can not
change the 5322.FROM without breaking the signature. This naturally
implies an digital signature binding assertion that can used for
security purposes.
I am surprise it is even questioned at th
ation - soft failure? or Neutral? or Reject?
Do you see a difference? I don't other than one group wants to accept
the unknown (or learn the badness of the message, if your lucky to
accumulated repeated scoring) and the other group wants to do
something about it.
--
Hector Santos, CTO
htt
ctive set of signature.
Inherently, there are assessment assertions to be made within DKIM
5322.From binding requirement - ergo the protocol inconsistency with
between WG documents.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_
won't
be responsible for any harm done and further more, the resigner would
not assume any erroneous responsibility.
All the eyes dotted, tees crossed - common sense protocol consistency
within WG documents. You can't development a consistent protocol with
unknown methods and soluti
LARGE MTAs.
--
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
nts and ignoring the comments clearly hasn't help as well.
Can't blame me. I can step away and the bugs are still 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
our system records and finishes with the actual subscription
email request.
--
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
al disposition of DKIM signed mail.
This has less regard for DKIM-SENDER-POLICY considerations (the conflict).
Anyway, good luck. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Daniel Black wrote:
> I've got a presentation slot for DKIM at APNIC next w
at DKIM is, with
years of no real proof or payoff shown, and now the conference
sponsors decided to add an opposing viewpoint or a viewpoint that
might suggest where there might be a payoff with DKIM.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
e more general and made to work with for
most MTAs, with no or little change.
--
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
Daniel Black wrote:
> On Tuesday 17 August 2010 01:18:52 Hector Santos wrote:
>> I think which keeps getting in the way here in molding ideas is that
>> much of it is based on online MUA access which does not always match
>> Offline MUA access,
>
> I was going on a d
tion that we take the opportunity now with
4871bis to add compromising semantics that inform readers that SIGNING
is not always desirable or the right thing to do and they should be
aware of any current or future augmented DKIM related technology or
functional specifications.
--
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
signer and author
domain, is to remove the DKIM requirement to include the 5322.From
header in the bind.
--
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
a major help in my renewed DKIM interest. He is
probably sore for an additional pat on his back. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
ssions.
If ASDP is going to happen or have any hope of happening, DKIM-BASE
needs to have some semantics that this separation is not CUT and DRY.
I don't think a reference to POLICY needs to be made, but only focus
on the idea that the LAST SIGNER is the responsible party
1201 - 1300 of 2714 matches
Mail list logo
