On 2/12/2018 12:40 PM, John R. Levine wrote:
Just for fun I sent in a new I-D of the dkim-conditional draft that
takes out version numbers and adds feature tags in a backward
compatible way.
https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/
+1.
But just for fun? I wish you
+1.
I think there are parsing issues to be highlighted. Do you decode
first, then extract the Author Domain or extract first before
decoding? etc.
On 12/5/2017 10:27 PM, John R. Levine wrote:
If I may change the topic for a moment ...
I'm working on some stuff for ICANN to help people
On 11/17/2016 9:34 AM, MH Michael Hammer (5304) wrote:
For exclusive policies (SPF -ALL), you really don't need DKIM, DMARC or ARC
for that matter since the receiver (at least ours) will never accept the payload
anyway, i.e. it never gets to the SMTP "DATA"
state. SPF does not require you
On 11/16/2016 1:09 PM, Terry Zink wrote:
This means ARC will be needed not only for mailing lists which modify the
header or
body of an email, but for EVERY mailing list and EVERY forwarded email or
EVERYTIME
the recipient has been modified and the email leaves the ADMD boundary. From a
DMARC
On 11/16/2016 8:03 AM, Murray S. Kucherawy wrote:
That's not correct. The verifying MTA, if it doesn't know the new
tags, is unaffected by the new tags because RFC6376 directs the
verifier to ignore them. It's as if they weren't there.
Do you have any data with unknown tag recordings
On 11/13/2016 1:50 AM, Murray S. Kucherawy wrote:> I've posted a draft
that attempts to address an attack that's begun to
appear with DKIM. Interestingly, we called it out as a possible
attack in RFC6376 and even RFC4871, but now it's apparently happening
and being annoying enough that people
IMO, this suggestion would be better as an Informational and BCP note.
I don't think it warrants a change to STD76.
We went through this already. We (DKIM WG) were well aware of the
weakness of a smaller key but we had backward compatibility concerns
so the proper verification migration
On 5/13/2015 1:25 AM, Roland Turner wrote:
On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with
what I'm saying above. When talking about unacceptably small keys,
the unacceptable decision is not made by the protocol, but by
On 5/13/2015 7:31 AM, Scott Kitterman wrote:
DKIM is a security protocol. I find it very odd to claim that the security
part of a security protocol isn't part of the protocol.
Good point. But we did take it into account. As you point out, the
APIs seem to have limited the size.
While I
There are several ways to offer the DKIM key size expectation for
Receiver local policies to deal with:
1) Report the bit size in Authentication-Results (Auth-Res) header.
Authentication-Results: mail.example.com
dkim=pass . bitsize=num-bits;
2) Add a DMARC tag extension ess=
-1
Please stop! No more DKIM code changes ok? The IETF just made it a STD.
Maybe we should remove the STD status first, move it back to proposed
standard or experimental if this and other changes are coming.
If signers want 1024 bits, then can do so ready.
--
HLS
On 5/11/2015 1:06 PM,
STD76, DKIM is an Internet Standard, already has a Signer/Verifier
migration path in section 3.3 towards the higher key with backward
compatibility support for the verification of the smaller key.
Why remove 512 support from the verification side? Does this mean the
verifier will take valid
with all the current DKIM features and options.
On 5/12/2015 8:56 AM, Scott Kitterman wrote:
On May 12, 2015 7:28:25 AM EDT, Hector Santos hsan...@isdg.net wrote:
-1
Please stop! No more DKIM code changes ok? The IETF just made it a
STD.
Maybe we should remove the STD status first, move
On 9/12/2013 3:28 PM, Dave Crocker wrote:
There seems to be a pattern that has developed, of demanding that
failure mean literally no adoption. It doesn't mean that. It means
that it has no community traction. ADSP more than qualifies on the
pragmatics of failure.
d/
The pragmatics of
This will require a substantial review before any change of status is
done and should be done as part of WG working on Domain Policies.
There is already substantial work with ADSP and APIs implemented and
deployed. We continue to get world wide usage of our ADSP zone record
generator wizard:
On 8/4/2013 4:35 PM, Pawel Lesnikowski wrote:
There are few details I'd like to clarify.
Body hash for this message is correctly computed by the sender.
Entire signature of this message in fact valid - this is why Port25,
Gmail, and Mail.dll validate DKIM signature with 'pass' result.
The
On 7/2/2013 10:11 AM, Murray S. Kucherawy wrote:
On Mon, Jul 1, 2013 at 12:24 PM, Michael Deutschmann
mich...@talamasca.ocis.net wrote:
On Mon, 1 Jul 2013, Alessandro Vesely wrote:
Well, not really. MAIL FROM: is only visible after delivery, so to
avoid dangling signatures one should
Oh, I didn't know there was a requirement for one to have IMPLEMENTED
and DEPLOYED proposed protocols before one can have any sort of
engineering insight into problems and their resolutions? I'm sure that
is not what you mean.
Sure, it helps, but keep in mind DKIM itself was engineered with
There are a number of domains supporting ADSP, ATPS and ASL records.
There is a healthy set of world-wide usage at our ADSP Wizard [1].
The problem is I doubt anyone is ACTING on any strong policy rule.
That was one of the chief complaint among the policy advocates (vendors)
with the first
(RFC5585) informational publications. Perhaps some update in the future
can correct this design and market inconsistency and explicitly provide
knowledge of the alternative frameworks available for DKIM.
--
Hector Santos, CTO
Santronics Software, Inc
Our extant product supports AUTH-RES for DKIM and ADSP. Without a
thorough review again and confirmation, I feel, unfortunately, probably
not 100% according your specification. At the time it was implemented,
over a few years ago, I had found it inadequate to cover all bases. I do
recall it
Murray S. Kucherawy wrote:
On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net wrote:
Here are two small tweaks that might correct things:
y This domain is testing DKIM. Verifiers MUST NOT treat messages
from Signers in testing mode differently from unsigned
Barry Leiba wrote:
That said, I'm inclined to agree with Mike T that input from the
reputation target is suspicious, so it's not clear how much value it
will have nor whether it might be gamed (by the reputation target) or
hacked (by someone wanting to hurt the target's reputation).
It
Murray S. Kucherawy wrote:
And you thought this list was dead.
I was asked to consult recently on some DKIM questions raised by a customer
of a former employer. The questions involved the meaning of t= in DKIM
keys and the text in RFC6376. The focus of this tag has always been, to
the
John R. Levine wrote:
I've opened a ticket to arrange that t=y suppresses any positive impact
domain reputation has in the next version of OpenDKIM, as an experiment.
I'm inclined to leave well enough alone. That wouldn't have been an
unreasonable interpretation six years ago when DKIM was
of member's submissions.
--
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
. In the mean time, here is
our auto-responder email address:
dkim-autoresp...@isdg.net
And for those with OpenDKIM setups exploring this, we have a wizard at
this URL to help prepare your records:
http://www.winserver.com/public/wcadsp
--
Hector Santos, CTO
http://www.santronics.com
to create an IETF no
consensus.
Hey, I'm all for proving me wrong. Please do so.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
outliving the Space Shuttle program.
Mark.
___
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
mail pickups.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Michael Deutschmann wrote:
On Wed, 27 Jul 2011, Douglas Otis wrote:
Your fix will not control phishing or spoofing abuse and would expose
these domains to open-ended sources.
ADSP reforms along my
policy layer.
+1. But 5+ years WIP? :) It wasn't rocket science.
--
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
. Are you anticipating a larger number of
new SMTP clients as a consequence of IPV6?
Mark.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
http://www.santronics.com
http
it.
--
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
Deutschmann wrote:
On Sun, 10 Jul 2011, Hector Santos wrote:
Now of course, if ADSP was a standard and whitehouse.com had an
exclusive signing policy, receivers would of rejected the junk
distributed by Dave's list server as an ADSP violation. But ADSP is a
pipe dream.
The attack only
main concern is that malicious signers and malicious intermediaries are
both recognized (or if not that neither is explicitly mentioned). IMHO is
is the malicious signers that are more insidious, since the 'h=from:from:'
offers no protection against them.
--
Hector Santos, CTO
http
valid signature requirement
as outlined in section 6.0, a verifier SHOULD NOT treat a message
that has one or more bad signatures and no good signatures differently
from a message with no signature at all.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
and verifiers, which
includes receivers or internal mail creators don't allow multiple from
headers.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org
a ONE FROM RULE criteria for both
signing and verifying.
--
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
in transit. This is done
by having the signer list the field name(s) in the h= tag an extra
time [...etc...]
Barry, as participant
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Hector Santos, CTO
the t's in their integration. If they have software control of
their DKIM stuff, its probably a good idea to make their the Verifier
and Signer has a One From DKIM Rule concept as cited in my previous
post and the specs should make that very clear.
--
Hector Santos, CTO
http://www.santronics.com
is correct, including time wise, given the fact
the payload is 100% exact?
Just wondering how much time I should spent on what appears to be one
of the final considerations for our new revision of DKIM implementation.
Thanks
--
Hector Santos, CTO
http://www.santronics.com
http
can use the
official completion announcement as part of our marketing.
PS: We resolved the overhead issues with DKIM signing so we are now
ready to go. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Barry Leiba wrote:
The 4871bis draft was on this past
, as a highlighted signer recommendation targeting
list mail. But as the table above shows, without the CRLF fix it
doesn't matter.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
Alessandro Vesely wrote:
On 25/May/11 20:23, Dave CROCKER wrote:
That's not likely to be the goal of this sort of exercise. Rather, it
will be to choose a set of particular types of breakage, ignoring others.
For an effort like that, it is not meaningful to come up with additional
types
to.
--
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 and none/fail
as far as catching badness with very little impact on legitimate mail.
What sort of phishing are we talking about? Identities or the context?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Hector Santos wrote:
John R. Levine wrote:
These days most subscriptions are entered on a web page, and if you're
lucky the mailer will send a confirmation message with a URL that sends
the subscriber back to the web page. Where's the MTA going to get the
subscriber info?
See below
), is a very important factor in all this.
--
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:
MH Michael Hammer (5304) wrote:
Remember, it's not static, it's dynamic. What was a non-phished domain
yesterday could be a phished domain today or tomorrow. DKIM isn't a
magic bullet, it's one more tool in the toolbox. I've found that in
combination with SPF it works
, people software (Old and New)
need to change to make DKIM work better.
--
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
Submission Integrity
because it doesn't matter any more when the MLM is always (re)signing.
Anyway, IMV, what people need is insights and let them make their own
decisions based on their own needs, but overall, the same outcome in
all cases should be the intended goal.
--
Hector Santos, CTO
http
Ian Eiloart wrote:
On 26 May 2011, at 12:46, Hector Santos wrote:
In principle, passthru mail should not be tampered, but MLM list mail are
the industry accepted exception to this non-tampering tradition and today
(at least in the USA), it is CAN-SPAM legal requirement to have a
viewable
the responsibility of the
originating domain, copyright holder author mail.
The Broken Signature Resign solution is only one solution. It doesn't
cover all the problems for one reason only - you can't assume everyone
is going to resign yet alone add DKIM to their software.
--
Hector Santos
, then this tends to be true. But when not, when the
list or any group forum is anonymous in nature, history has told us
its get corrupted with junk and most people tend to dislike it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Steve Atkins wrote:
On May 26, 2011, at 1:50 PM, Hector Santos wrote:
If by traditional, you mean the members are vetted with subscription
and confirmation, then this tends to be true. But when not, when the
list or any group forum is anonymous in nature, history has told us
its get
subscription.
I guess if the RECEIVER is a List Server SMTP Server, then its
database will be easily accessible to do a member check at SMTP level.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list
and/or operators add Plug and Play hooks, to do the Always
Resign thing you want, we will always have the problems for a very
long time.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
John R. Levine wrote:
Perhaps an MLM's reputation is pulled up or down as the average
can see where this be a good idea to do now -
SMTP level rejects with response text User not member of so and so list.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http
in life.
In any case, we are not doing any REJECT/PASS handling based on DKIM
yet, but I am going to try turning off SPF for my domains and see if I
get the expected 100% would-be rejects based on DKIM and my ADSP
policies.
--
Hector Santos, CTO
http://www.santronics.com
http
. Before that, it was
in the 1-4% range.
So if most of the 6% SPF rejects are spoof attempts on our domains,
then I have no reason to believe that DKIM plus our ADSP/ATPS/ASL
policies would not yield the same result.
Hector Santos wrote:
MH Michael Hammer (5304) wrote:
The other piece
have from a pre-filter standpoint. If most of
it is pre-filtered, then extracting the various value of DKIM is
masked or lost.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
of any
empty
header file of size 2, crlf)
- Intermediaries that expand QP to 8 bit
- Intermediaries that reformat to BASE64
I personally have not seen anything else.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Alessandro Vesely wrote:
On 25/May/11 10:03, Hector Santos wrote:
How would 7/8 bit be considered?
Personally, the STRIP C14N idea would work just fine by removing all
trailing WSP (CR, LF, SP) and for QP text, decode it first. I'm
considering updating my 2006 I-D to include the QP
beta code, revamped to support I/O
completion ports and the code for undotting of the leading dot (per
RFC5321 4.5.2) fell thru the crack. So we can nix this one. :)
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
% failure
NEW: 4.8% failure
and the major contributor to this is that I have no more
facebookmail.com failures!
When I remove the domains I know, the rest is pretty much spam. :)
Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit
Scott Kitterman wrote:
On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
...
When I remove the domains I know, the rest is pretty much spam.
...
Isn't that pretty generally true, DKIM or no DKIM.
Sure, in general I would agree with that and most of it are single
shot deals
icon attachment, the
message display is blank. That may be related to what you are talking
about. In any case, its all fubar.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according
://jl.ly
___
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
Ian Eiloart wrote:
On 23 May 2011, at 17:10, Hector Santos wrote:
Rhetorically, why not? Put another way, why should a receiver
tolerate failure, or better, why should DKIM itself - the technology
- tolerate failure? Sounds like DKIM has some inner soul turmoils - a
devil on one
.
--
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
better, there
were less issues, less surprises and future things would basically fit
right in.
With new needs such as EAI (internalization) and DKIM
(authentication), it is highlighting the cases where certain methods
in the network were not ideal.
--
Hector Santos, CTO
http://www.santronics.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
.
Not in Thunderbird V2.0, V3.1. It knows nothings about your signature
- Click View | Message Security Info and it says:
Message Has No Digital Signature
Message Not Encrypted
What version of TBird did you use?
--
Sincerely
Hector Santos
http://www.santronics.com
Charles Lindsey wrote:
On Mon, 23 May 2011 03:50:06 +0100, Hector Santos hsan...@isdg.net wrote:
It would of been nice to have some DKIM-Signature flag that might
indicate the Content-Transfer-Encoding, i.e.:
et=base64 --- copy of the top level Content-Transfer-Encoding
Could you
Ian Eiloart wrote:
On 20 May 2011, at 05:24, Hector Santos wrote:
In this case, if this is enforced with a MUST, for a system that is
not 8BITMIME ready but is adding DKIM signing support, to remain
compliant it is far more feasible to add a rule to a DKIM signing
component:
If mail
that are guarantee to change based on a
known path it will take - like for an MKM, consider not hashing the
5322.Subject tag and use l= when the target path is known to be a
list adding a footer.
So with the Pareto Chart, we can include MLM and target/path as two of
the items.
--
Hector Santos, CTO
http
Ian Eiloart wrote:
On 23 May 2011, at 15:19, Hector Santos wrote:
But why skip? Usually the message won't be downgraded. And even if they
are, usually a broken signature will cause no harm.
Thats the problem - define usually and also define no harm.
Well, harm will only be done when
Alessandro Vesely wrote:
On 23/May/11 06:35, Hector Santos wrote:
Alessandro Vesely wrote:
For example, MTAs that autoconvert from quoted-printable to 8bit, a
rather common circumstance.
I did the following Content-Transfer-Encoding failure analysis:
Failure rates for message top
!
--
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
.
--
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
but it could be done with downlink target/path knowledge:
if mail is 8bit then
if target path does destroy 8bit then convert
sign mail
While that may be a functional description of a fallback, we don't
have the automated technical capability to define it reliably.
--
Hector
Murray S. Kucherawy wrote:
Hector Santos followed up Crocker'ss passing of the buck:
Please refrain from passing the buck to the WG. The document editors
are:
D. Crocker (editor)
Tony Hansen (editor)
M. Kucherawy (editor)
If the WG was technically incapable as you
so, but if
l= was used, there is some avenue for success.
The main realization is that Sender/Signers need to be more aware of
the target/path if they desire a higher rate of return.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
and signers.
--
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 list.
It would be interesting to see what Murray can show for his volume
collection.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list
an asciiz String?
3. Section is confusing, mixes up sections (i.e. previous steps
... what steps?)
4. There is no explicit statement for a signer MUST implement simple or
relaxed, unlike explicit MUST statements for verifier.
5. Should this say invalid signature?
6. Ambiguous?
--
Hector
trust? If the signer is unknown, DKIM
authenticity has no value.
--
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
for DKIM
verification failures
If we change this downgrade to a MUST, then we must also fix the C14N
problem we forgot about the extra CRLF possible at the top the
message possible in IETF streams like IETF-SMTP. Can't have it both
ways: its important here, but not there.
--
Hector Santos, CTO
be converted to 7-bit MIME by an MUA or MSA
prior to presentation to the DKIM
So I don't even know why we are talking about this. If its out of
scope how we can contemplate a MUST here. I concur with Levine, take
it out.
--
Hector Santos, CTO
http://www.santronics.com
http
Pete Resnick wrote:
On 5/19/11 6:52 PM, Hector Santos wrote:
SHOULD is an optional requirement - Its a recommendation for the
better, but things will not break things for your peers if you don't
follow it. You may be shamed but the person shaming you is the one
wrong if they depended
canonicalizations.
--
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
-param but without the b-param (data hash)
--
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 be statistically true, then I think the
only thing we can say is that we did our job to provide a relaxed
C14N method to lower the transport mutations issues for those domains
who need it.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
rates for simple or relaxed).
I also think that if DKIM has a C14N option (i.e. STRIP) available to
resolve legacy throughputs for particular streams, they will use it
too maybe on per target basis only. :)
Anyway, thanks.
--
Hector Santos, CTO
http://www.santronics.com
http
relaxed/relaxed.
--
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
, 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
1 - 100 of 1268 matches
Mail list logo
