In article you write:
>This may be of interest to this group, as there isn't an active DKIM WG
>anymore.
At the DISPATCH session at IETF 98 I pitched a proposal to update DKIM
with a new crypto algorithm and/or a more compact key representation
(put the key in the signature and put a hash of it
>My reading of this too-long message thread is that there is essentially
>no support for making ARC's header-related issues any different from
>DKIM's, so I encourage the chair to shut this thread down.
What he said. Can we please limit subsequent discussion of testing
about how to test ARC as
In article
you write:
>The issue is that its possible for two separate arc implementations, given
>the exact same message inputs, keys, timestamps, etc to be generating two
>different, but equally valid ARC seal hashes.
DKIM does the same thing. The order of fields in a DKIM-Signature
header is
In article
you write:
>I'm not sure how you could go about registering key lengths. What do you
>have in mind?
Come to DISPATCH and learn all about it.
The general point is that DKIM's key advice is kind of stale -- 512 bit keys are
too short, 1024 keys are OK now, but within the likely lifeti
As threatened, albeit kind of late, here's plan for how to rotate to a
new algorithm.
We note that every Arc-Seal and Arc-Message-Signature header has an a=
tag that identifies the hash and signing algorithms used. (In sec
5.1.1.1 it just says hash, which is wrong.) Every DKIM key record has
k=
In article
you write:
>The last time I broached the topic of adding EC to DKIM, I was told there's
>no way that could proceed because EC was heavily encumbered by IPR claims.
>Is that no longer the case?
RFC 7479 adds Ed25519 to SSH and has no IPR disclosures.
Dan Bernstein is the primary autho
>It's been awhile since I've seen this, so it may not be a problem anymore.
>There is no obviously correct
>thing that someone won't screw up.
>
>It's probably better to specify how to put multiple strings together. RFC
>7208 has words that can probably be
>reused without modification.
Might a
>We should recommend secure defaults and let users of DNS crudware harangue
>their vendors or find new ones that
>can support publishing secure keys. We’re also foreshadowing long key lengths
>next year.
Having been dealing with the crudware argument for a very long time* I
can tell you that the
>As I recall there are issues using keys bigger than 1024 bits because
>construction and/or correct interpretation of TXT records that contain keys
>of that size or bigger has been problematic due to DNS provisioning
>software that does the former wrong and DKIM verifiers that do the latter
>wrong.
In article
you write:
>I'd like to come up with something better than updating DKIM every time
>there's new advice on key sizes, etc. Doing one update that points to the
>best current advice, and then letting that other thing get updated
>whenever, would be better. Otherwise at some point we'll
In article
you write:
>Trying to figure out some signing order for pathological cases seems
>unnecessary.
>
>What's the point of passing my failure status on?
I agree. We don't have legacy code to work around, so we should
concentrate on getting things to work correctly.
R's,
John
___
>How would you suggest we drive a revision to RFC 6376 to address this issue?
As you saw, anything in the IETF that smells of crypto tends to go
into the weeds with the crypto fad du jour.
If you want to do this, I'd suggest an update with a very small focus:
1) Add a new signature algorithm, pr
In article
you write:
>> No responsible operator has used the RFC minimum DKIM key sizes for a long
>> time. They were trivial to bypass half a decade ago. No one has ever
>> complained about 1024 bits default minimum being too big. ...
>I agree with your points, but don't you think it would be
>1) Do we have a normative reference within the RFC framework for key
>lengths for different crypto systems, and can we simply invoke that
>reference rather than including a hard figure in this spec?
There's RFC 3766, but it's over a decade old and has rules for how to
figure out how long a key yo
In article
you write:
>I'm currently working on a test suite for ARC, and have run into a few
>areas in the draft that could use some clarification, mostly with regards
>to section 5.2.1, which seems like it needs a non-trivial update. I've run
>into the following issues:
>
>- Can messages with
>It's a request, but my intend was it MUST be supported when the "ruf"
>tag is honored. Only if there is no "ruf", or a report generator ignores
>the "ruf", than the "fi" may be ignored. (I know some report generators
>don't implement "ruf", for reasons of privacy).
Remember that MUST only means "
>I'm not sure there's another way. If the domain receiving the reports were
>to be burdened with imposing the limit, it has only a few choices:
>
>* size up to withstand whatever load the greater Internet will throw at it
>(expensive);
>* build queueing infrastructure to accept anything the greate
>However, under certain circumstances this property can potentially lead
>to an undesirably high volume of reports. Especially when a Domain
>Owner's name is spoofed and abused in a large-scale phishing or other
>impersonation attack.
I gather that this was inspired by some sort of phish or spoof
In article <713098835.18678872.1478547678821.javamail.zim...@peachymango.org>
you write:
>The EAI WG found it was fine to remove the obligation to have an email address
>part in the
>mandatory RFC5322.From header, leaving only the display part to assert the
>original author.
Only in the very
>So, please point to the formal specification that permits a From: field
>to have no email address.
RFC 6854 section 2.1 allows the From: addresses to be an address-list.
In RFC 5322 sec 3.4, an adresss-list can be an address, an address can
be a group, and the group-list of addresses in a group
>Belittling people who are arguing that a long-standing problem needs
>to be fixed is not appropriate.
We all agree that the problem needs to be fixed, but many of us
believe we have a duty to try to understand a problem before demanding
"solutions" which would cause at least as many problems as t
>I've seen comments that people who were on Yahoo can fortunately go to Gmail.
>What happens when Gmail publishes a
>p=reject like they said they were going to (even if the timeline is delayed),
>per
>https://wordtothewise.com/2015/10/dmarc-news-gmail-preject-and-arc/?
They have said multiple ti
In article
you write:
>FWIW, I use Google For Work (or whatever it's called this week) and it
>doesn't automatically add DMARC headers--
Is it too much to ask that anyone who wants to tell us how to deal
with DMARC should at least read RFC 7489 so he knows how DMARC works?
R's,
John
Helpful ti
>Most of the recent work has been in regard to coordinating and testing the
>four (4) known implementations of the ARC spec (Google, AOL, dkimpy,
>OpenARC). They are each in various stages of completion/readiness for
>production.
Any chance we could get a peek at dkimpy or OpenARC? We understand
>My worry is that if DMARC started as a private mechanism for high value
>targets and large msps to collaborate to lower the risk of phishing for
>their shared users, and I don't want ARC to be perceived as breaking that.
>
>I don't want MSPs to have to come up with private lists of high value
>tar
>Should DMARC add a policy setting for whether the domain owner feels that
>ARC should be used to bypass regular DMARC evaluation?
Please, no. One approach to what we can oversimplify as the mailing
list problem is to do it from the sending end, with the sender using
something like conditional do
In article you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>In light of all of the discussion about how the LHS of email addresses are
>normalized and encoded/hashed in order to be used to
>publish certificates and keys via DANE records like SMIMEA and OPENPGPKEY we
>have put together an approach that le
>I can put together an appendix with some examples. I was thinking that
>having a better explanation would provide more value so I guess I got your
>suggestion backwards :-)
I'd prefer that you post the current version of the draft so we can
see what the context is. Draft revisions are cheap, pos
>I had not noticed -- and still don't quite understand -- what it is
>about the new stuff that will cause a legacy engine to fail the
>signature validation.
It's in section 3.5 of RFC 6376, the part about the DKIM-Signature
header, where it says:
v= Version (plain-text; REQUIRED). This tag de
>1. I wasn't recommending making the new feature optional. Merely
>noting the considerable benefit that accrues if you can live with it
>being optional.
You might want to reread my draft, because this discussion has no
relationship I can see to anything it says.
The DKIM spec says a signature i
>> Quite correct. I would expect conditional signatures to be applied by
>> large mail systems, using their private list of domains that look like
>> mailing lists to decide who gets them.
>
>How much of a barrier to entry to new or small mailing list providers
>(or new domains being used there) d
>> The local signer here must know this message goes to dmarc@ietf.org
>> an add a signature including "!fs=ietg.org"
>
>An average email author cannot be relied on to cause this setting to be
>made.
Quite correct. I would expect conditional signatures to be applied by
large mail systems, using t
> A sender that expects a message to be forwarded might put both a
> conventional DKIM signature and a signature with a !fs tag that
> refers to the domain name of the expected forwarder.
>
> require conventional, full DKIM signatures. Why? It seems to me that any
>DMARC authentication meth
I refreshed this draft so it wouldn't expire. Not very different,
mostly changed the @fs= to !fs= per Murray's suggestion.
I still think this is the least broken way I've seen to let
mailing lists coexist with DMARC.
R's,
John
___
dmarc mailing list
d
>ReSenders haven't introduced any interoperability issues. DMARC has. How
>about:
Indeed. I agree with the advice to refrain from blaming the victim.
> o MTAs sending email on behalf of multiple domains may require
> Domain Owners to provide DKIM keys to use DKIM to avoid SPF
> a
>But I am still receiving reports from hotmail despite DKIM and SPF
>tests passing ? So I don't understand what hotmail's system's are
>moaning about ?!?
Aggregate reports aren't failure reports, they're aggregate reports.
They tell you about all incoming mail that purports to be from you
and wha
>We've been looking at weak dkim from the angle of reducing what's covered
>by the signature... but unfortunately, that takes out the major parts of
>the message that we care about.
>
>I'm wondering if there is a different alternative.
When we were doing DKIM, we went around and around and around
>It is not wrong, I think you have no practical experience with EAI.
You might want to review these, as well as RFC 6783.
http://www.circleid.com/posts/email_in_the_worlds_languages_part_i/
http://www.circleid.com/posts/email_in_the_worlds_languages_part_ii/
http://www.circleid.com/posts/email_in
>> (3) I would really like to see some provision for reporting to mailbox
>> users when their mail is being discarded due to publication of
>> p=reject by their mailbox providers, especially in cases where a
>> Mediator is willing to put its reputation on the line by signing
>> the
>Please submit "stuff" that needs to be fixed
The worst problem is still section 3.1.2.3 which needs to be deleted,
since most of what it says is wrong, and what little isn't wrong is
irrelevant.
RFC 6854 is not about EAI, since an ASCII MUA can create mail with an
empty group From: as easily a
> > With double signing, you have the ability to distinguish between plain
> > old spammers, and spammers who are screwing around with forwarded
> > mail. I think that's a useful difference, since it is my impression
> > that the set of malicious mutating forwarders is pretty small because
> > it'
>On the inbound, I’m not sure whether or not we’d verify the DKIM v2 *or*
>simply suppress the DMARC check and apply all of our other antispam filtering,
>and update the MLM’s reputation accordingly.
Well, gee, you can do that now. We hope you do, since that will also
enable list mail from people
>> The double signing hack limits the opportunity for trouble to mail
>> systems that have a recent real message in hand. While I can
>> certainly imagine spammy scenarios, it's hard to imagine ones that
>> wouldn't be fairly easy to detect and shut down. ...
>True, the damage is limited to the l
>The challenge here is that the second signer may not have anything to do with
>the message. Since, except for From, only invisible parts of the message are
>signed, the signature could be applied to almost any email. Using the
>reputation of the second signer's domain is not substantially dif
>I would think you'd have to. There's a replay risk that's unique to this type
>of
>signature, so I think treating them the same would be a naive approach.
Remember that DMARC doesn't tell you that a message is good. The most
it can say is "not so awful that you should automatically reject it."
>> What would the Authentication-Results header look like? Presumably 3
>> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC?
>> Show one result or two? Or maybe something like dmarc=conditionalpass? ...
>Is there any use in making a distinction to your acceptance/routing of
>> Remember the key axiom of mail reputation: you cannot say good things
>> about yourself, only neutral or bad things. ...
>This is an interesting observation when compared to DKIM and SPF, where you
>only actually know something about the message when they report a "pass".
>But that's authentica
>Under at least one of the proposals, it can be determined that "yes, A
>signed the mods, and if the mods are removed to re-generate the original
>message, B signed the original message". If we have that, then I think
>the question becomes: if this is to be a DMARC-like scheme, how do we tie
>A's
>> No. Most domains aren't subject to significant phishing attacks, so
>> for them it's useful for incoming mail from Paypal et al, but not for
>> outgoing mail.
>
>I take it that a *significant* phishing attack is one where the
>5322.From domain is involved with money, and the hook is a URL at a
>Isn't the ideal objective of DMARC to be so reliable that *everybody*
>uses it with p=reject.
No. Most domains aren't subject to significant phishing attacks, so
for them it's useful for incoming mail from Paypal et al, but not for
outgoing mail.
> At that point, 5322.From addresses will all
>
In article <1552316227.113529.1431130088299.javamail.zim...@peachymango.org>
you write:
>I went over the emails of this week, did not find any new comment/update for
>the above document.
Do you know when you'll be posting a new draft? There's a fair amount of stuff
to fix.
R's,
John
___
>Is it sufficient to say something like this?:
>
>"A participating operator needs to solve the registration problem.
>Different operators will have different capabilities, requirements, and
>limitations here.
So far so good.
> A very simple approach would be ;
Not so good, since there are lists
>With List-Id becoming a more generic feedback channel, I suspect that its
>value for indicating the participation of a MLM will further degrade.
This is news to me. Can you explain or give pointers?
The only application of List-ID with which I am familiar is to sort
(or filter depending on whic
>I recall some earlier discussion about encoding information in From local
>part, but if for no other reason, automatic addition of new email addresses to
>contacts by some MUAs makes that highly problematic.
This trick also has patent problems.
>DNS query to message-id.yamfsidlocalpart._dmarc.
>Please post more reviews...
Hmmn. Section 3.1.2.3 on EAI is, to a first approximation, completely
wrong. Please delete it, since the problems it describes do not
actually exist.
EAI does not, repeat NOT, downgrade messages in transit. If I send
you an EAI message, either it'll be delivered a
> Are we going to say "The big four email providers pushed their problems onto
>everyone else" ?
Yes, of course. But as we've seen, we have little ability to push
back.
R's,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listi
>Even if we were all to concur that altering the From by adding the list is
>the right way forward here (an intriguing idea at the moment), ...
Just for the record, I haven't been responding to arguments about
rewriting the From: line because I don't any way they will lead to
anything useful, and
>Couldn't the DMARC specification spell out that Receivers claiming to be
>DMARC-compliant, when choosing to *accept* incoming messages from Senders
>publishing p=reject (irrespective of whether such accepted messages passed
>or not the DMARC checks), CANNOT after-the-fact reinject such received
>m
>yes, but the problem with cost imposed on third parties is that it is
>valued different by the one who imposes it on someone else and the one,
>on which is it imposed.
Well, sure. If I can force you to solve my problem, as far as I'm
concerned that's a free solution. I hope we agree we want t
>Rolf kind of said what I'm thinking here: I agree that we need to look at
>the costs. But are we willing, or not willing, to accept costs that are
>not zero?
Sure, everything has some cost. Something I should have made clearer
is the difference between the costs of changes one imposes on one's
>That leads to six combinations: Originator/Big, Originator/Small,
>Mediator/Big, Originator/Small, Receiver/Big, and Receiver/Small.
This is indeed useful. But I think it's also important to look at
technical vs. nontechnical costs for each actor. The whole reason
we're having this discussion
>This can be solved by having the owners of mailing lists publish a
>yet-to-be-defined DNS record in which they proclaim the presence of a
>mailing list within that domain.
That's unlikely to work, because malicious people can publish anything
that legitimate lists can.
There's a fundamental ru
>> A database is still needed of which domains will have an
>> outbound mail stream with two signatures.
Sorry, no, that's completely wrong. Please reread the draft.
>I have not yet taken the time to fully understand the "weak and
>strong signatures" idea, but if I may be forgiven for commentin
>That last sentence is basically what I said about both of my drafts, and
>that logic was shot down. Once you've decided you don't like the arbitrary
>changes, you know who to blame, but you still have to decide what you like
>and what you don't.
Yeah, now that I look at your drafts again, I see
I updated my conditional signature draft, which is now (thanks to a
suggestion from Ned Freed) the mandatory tag draft.
https://tools.ietf.org/html/draft-levine-dkim-conditional-01
The idea is that you have a weak signature on To, From, Date,
Message-ID but not subject or body, with a new tag tha
>Comments on either or both are welcome.
They both have the same problem: the list says:
Here's what I did. Whadda ya think?
Every recipient system has to come up with its own heuristics to
decide what combinations of changes are or are not acceptable, which
means that the exact same message w
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Looks like we require v to exist and be either 1 or DKIM1, otherwise you'll
>get a "bad format" or "bad version" in the AuthRes header. Wonder how old
>the DKIM1 is and whether we should remove that now...
The DNS key record has to say v=DKIM1
>Handled by whom? If we're talking about telling MUAs "Don't render the
>unsigned part of the content the same way as the signed content", then a
>bunch of additional complexities begin to appear:
We went over all of this ages ago when DKIM was young. It should all be
in the DKIM WG archives.
>
In article <551cc3fe.10...@dcrocker.net> you write:
>On 4/1/2015 8:22 PM, John Levine wrote:
>>> In the latter case, it's really an entirely new protocol, which should
>>> be identified by the next-lower protocol, rather than by using the
>>> version
>In the latter case, it's really an entirely new protocol, which should
>be identified by the next-lower protocol, rather than by using the
>version field as an in-bred demultiplexing field.
I suppose, but if the two procols are 99% the same, and the new one is
upward compatible with the old one,
>As I recall this was considered during the development of DKIM originally,
>exactly for this reason. We rejected it because we couldn't come up with a
>safe description of what a tag should look like.
Yeah, that's what I recall, we couldn't figure out a way to allow benign
modifications without
>Verifiable authenticity of email greatly depends on DMARC's success. Because
>without
>DMARC's success the authenticity of email can only be verified heuristically
>and not
>systematically.
Rehashing old arguments will not change anyone's mind. False assertions are
like these are utterly usele
>But do you think the general email-using population will be happy to miss
>authentic email from eBay, Amazon, Paypal and American Airlines, just to get
>email from some mailing list(s) delivered to their inbox?
My impression is that most users put a very low value on commercial
bulk mail. I'm no
>> How big is the volume of DMARC-problematic indirect email flows, compared
>> to the general volume of email which can readily benefit from DMARC?
The numbers I've seen say that the volume of mail that DMARC screws up
is fairly low, but it is very high value.
Personally, I would be happy never
> From: "John Doe (j...@dmarc-abuser.com) via NPO"
I would try some tests particularly at AOL before I did that. AOL
mail tends to reject anything that looks like a munged AOL address.
The least painful approach may be to tell people with AOL addresses,
sorry, please get a different address.
In addition to other comments:
Section 3.1.2.3 is just wrong. EAI specifically does not allow for
downgrading of messages in transit from UTF-8 headers to ASCII
headers. The only place the header downgrade is allowed is when a
non-EAI MUA picks up mail via POP or IMAP, but that would be long
aft
>Yahoo is NOT the only one I've had issues with; hotmail is the same - a couple
>weeks and I'm
>bounced again on either from the ARSClist. Based on my experiences with Yahoo
>in the past, I'm not
>even going to waste my time CONTACTING them, let alone trying to lobby them.
The problem is that Ya
>RFC 7208 doesn't say the HELO result determines anything. It says IF (I say
>again IF) a decision
>has been reached about message disposition based on the HELO result, there is
>no requirement to go
>ahead and do a pointless Mail From check.
While that is certainly one plausible interpretation
>DMARC leverages the Mail From identity, so I don't see how independent HELO
>checks can be relevant.
If you look at sections 2.3 and 2.4 of RFC 7208, a reasonable
interpretation is that you check the HELO identity, and if you get a
"definitive policy" result, you're done and return that to the
>Do people concur with this change, or something close to it?
I'm OK with it, but to the meta-question, I realize the practical
issues involved with yanking something out of the production queue,
but in this case I wonder if that's not the right thing to do.
There's no great hurry in getting the
>HELO results are unrelated to DMARC.
Is that still true when the bounce address is empty? It's fairly common
to have an NDR with an empty bounce address and
From: MAILER-DAEMON@flaky.example
Assuming it's not DKIM signed (most NDRs aren't) what's a DMARC user
supposed to do?
R's,
John
>Not mentioned anywhere: Which SPF modes are considered to be a "pass"
>> for purposes of DMARC? Presumably +, presumably not -, but it should say
>> something about ? and ~ if it doesn't already.
>
>Not only is that another late-stage technical issue to punt to the working
>group, but I also claim
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>OK, seriously, I hope I don't have to crack this open again. Conflict
>review is slated for the 1/8 telechat, and a flurry of last minute edits
>might not sit well with the IESG. We need to leave actual work, as much as
>at all possible, to the
>I'm staring at this and not understanding how the two are all that
>different. They both seek to ensure that a DMARC evaluation can be done on
>the From: domain, and thus both seek to ensure that the From: that lands in
>the inbox can be trusted by end users to be valid.
Now, wait a minute. DMA
>What about pointing it may be a security issue to let these messages through?
Only if we also point out that it may be a security issue not to let them
through.
Seasons xmas,
John
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/lis
>>> 1. Hotmail/outlook.com puts a green shield in the web UX in front of
>>> trusted senders
>who authenticate. Is that what you mean?
>>
>> Only sort of. That's ad-hoc since each recipient system has their private
>> list of
>green-bar-worthy senders. (I mean, if I wanted to get into it, how
>4. Anything else?
Figure out how to display signed mail from famous brands in a
distinctive way analogous to browser green bars, and tell people
to look for that.
Crooks can figure out ways to misspell Paypal faster than you can
blacklist them, and half the time the crooks don't even bothe
>So the edge system generates a bounce message (MDN). Knowing that
>RFC5321.MailFrom will "<>".
>To be DMARC compliant the RFC5321.HELO/.EHLO name must be align with the
>RFC5322.From of the MDN.
Why wouldn't you add a DKIM signature that matches the domain name in
the message From: line? The e
>>> Could I request the list admins, to drop the subject tagging and the footer
>>> on
>this list? And if possible remove the removal of the HTML?
Every IETF list I subscribe to, which is a lot of them, is set up the
same way with subject tags, message footers, and flattened text.
There is no mor
>> I occasionally see non-ASCII octets introduced by spam/virus checkers in
>> X-Spam-* fields in the header or in the (non-8-bit) message body, due to
>> copying message content into those contexts. The From field is perfectly
>> valid, however. Does that really mean that identifier alignment ca
>What sort of remedy would you suggest here? Off the top of my head, here
>are some suggestions:
>
>1) Evaluate all the domains you find, and if any of them have published
>DMARC policies, apply the strictest one ...
Given the anti-phishing goals of DMARC, I don't see how anything else
makes any
>A more general comment: reading the wiki and the discussions on this
>list, it get the impression that we seem to focus more on the issues
>related to the 'DKIM part of DMARC' then on issues related to the 'SPF
>part of DMARC'. Is my observation correct, do we tend to forget SPF here?
I agree
In article
you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>> I'm not Doug, but Google unquestionably did that when AOL and Yahoo started
>> publishing p=reject
>
>Again, this is an assertion and where is the evidence for this?
Tech people at Google told me that's what they did.
R's,
John
_
of email are often incredibly problematic. Thanks to John
>Levine for quietly
>inserting this into the WG's wiki.
>
>I'll be trying to find.. volunteers... from various embedded communities to
>contribute to
>this page. Feel free to note your own experiences.
I stuck in a
>The discussion of interoperability between DMARC and MLMs has become opaque
>enough to
>warrant taking the time to document the learning. To make comparing and
>contrasting between
>MLMs possible, I think the WG needs a model --
Take a look at RFC 6377. It's not really a BCP, but it lays out
>> The typical reaction to the disruption they created was to translate their
>> p=reject into p=quarantine.
>
>Would you provide some proof of this assertion?
I'm not Doug, but Google unquestionably did that when AOL and Yahoo started
publishing p=reject.
R's,
John
_
>while some BBS's have evolved more mailing list type functionality "receive
>posts via email, respond to posts via email". The ones that started as MLM
>tend to use "from is author" and the ones that started as a BBS tend to use
>"from is mediator".
Having been there at the time, I'm fairly conf
>mail readers. The existing use of X-Original-From is an existence proof
>of [perceived] utility, despite the absence of widespread (any?) MUA
>display of this data.
Who uses X-Original-From ? This is a real question, I'm not aware of
anyone who does.
R's,
John
PS:
>and the creators of DMARC
>The opportunity for this WG would appear to be to spell out sensible
>practices for use in the two situations, and perhaps to spell out the
>trade-offs for deciding between the two, assuming that we are able to do
>so without devolving into further equine abuse. I'd suggest that
>specifying a
I've added an indirect mail flow page to the ASRG wiki. If you don't
have a password to log in and edit, write to me and I'll give you one.
>> >IMO, the place to record the inventory is the wiki. Mailing lists are
>> >not a good place to keep such records.
>> I would love to add it to the Wiki,
901 - 1000 of 1051 matches
Mail list logo
