Subject: [Asrg] The state of the email system

From: Franck Martin <[email-masked]>
Date: Sun, 16 Nov 2008 14:20:33 +1200 (ANAT)

Looking at the discussions, I'm wondering if someone could point me to graphs showing (with a timeline): 

SMTP vs ESMTP traffic 
Mime formatted emails vs non Mime 
Text email vs text+HTML vs HTML only emails 
Character encoding in emails (which ones are used) 
PGP/SMime/Total 
SPF/SenderID/DK/DKIM/Total 

If these graphs exist, we could link to them on the wiki 

If they don't exist, how can we encourage, groups, email providers to give them? 

I know it would be difficult, to make them authoritative, but with well framed explanations, it would give some sense to them. 

Cheers 

_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: der Mouse <[email-masked]>
Date: Sun, 16 Nov 2008 22:20:23 -0500 (EST)

> If they don't exist, how can we encourage, groups, email providers to

I don't know, but I can keep at least some of those statistics for the
mailers I run (my own) or co-run (at work).

My own mailer stats would border on useless, both because I'm such a
tiny leaf site and because the mail is heavily self-selected.  Work is
larger, but nowhere near big enough to be more than one data point.
It's slightly less certain because I'd have to get approval to release
the data, but I have no real doubt the approval would be forthcoming
for aggregated statistics such as you list.

Assuming I (a) can implement it and (b) get approval to release the
data, what statistics would you like (just the above? more?) and what
useful things could I do with the data?  Send the data to an
aggregator?  Make plots available?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Franck Martin <[email-masked]>
Date: Mon, 17 Nov 2008 15:45:08 +1200 (ANAT)

I found 
http://utility.nokia.net/~lars/meter/dkim.html 

Which is interesting, but does not give an idea based on traffic. If yahoo, hotmail and gmail implements dkim, well it could be more traffic using dkim than may be a few ISPs... 

So I think it is important to base these stats on traffic rahter than on how many sites have it configured. 

For the purpose of this workgroup I think we are looking at technologies that reduce spam. So I guess a graph in time showing how much mail traffic is dkim/dk/spf(?)/senderid(?) would be interesting. I think making the plot available would be interesting. I saw with the stop of the recent botnet, security companies run graph on the number of spams within the mail system., it would be nice to see the above graph per non-spam traffic and spam traffic. 

For your case you would have to monitor only inbound mail traffic, as with outbound, it would only tell us what you have implemented on your MTA. 

Not sure I'm fully clear here... 

If several big mailing site do that, then it can be aggregated to get an idea of what's happening. 

----- Original Message ----- 
From: "der Mouse" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Monday, 17 November, 2008 3:20:23 PM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] The state of the email system 

/~\ The ASCII Mouse 
\ / Ribbon Campaign

---

From: Steve Atkins <[email-masked]>
Date: Sun, 16 Nov 2008 20:04:01 -0800

On Nov 16, 2008, at 7:45 PM, Franck Martin wrote:

> Which is interesting, but does not give an idea based on traffic. If  
> yahoo, hotmail and gmail implements dkim, well it could be more  
> traffic using dkim than may be a few ISPs...
>
> So I think it is important to base these stats on traffic rahter  
> than on how many sites have it configured.
>
> For the purpose of this workgroup I think we are looking at  
> technologies that reduce spam.

DKIM is not intended to reduce spam.

> So I guess a graph in time showing how much mail traffic is dkim/dk/ 
> spf(?)/senderid(?) would be interesting. I think making the plot  
> available would be interesting. I saw with the stop of the recent  
> botnet, security companies run graph on the number of spams within  
> the mail system., it would be nice to see the above graph per non- 
> spam traffic and spam traffic.
>
> For your case you would have to monitor only inbound mail traffic,  
> as with outbound, it would only tell us what you have implemented on  
> your MTA.
>

It would certainly be interesting, but I'm not convinced it
would be particularly useful - as in changing anyones
behaviour.

Cheers,
   Steve

---

From: Franck Martin <[email-masked]>
Date: Mon, 17 Nov 2008 23:59:53 +1200 (ANAT)

Huh DKIM is for what then? Not sure what it was created for then? Why do we bother to implement? 

Graphs would not change behavior, but would show either what is popular, and if program to change behavior are succesfull. 

I think anyhow we need some data rather than hunches. 

----- Original Message ----- 
From: "Steve Atkins" <[email-masked]> 
To: "Anti-Spam Research Group - IRTF" <[email-masked]> 
Sent: Monday, 17 November, 2008 4:04:01 PM (GMT+1200) Auto-Detected 
Subject: Re: [Asrg] The state of the email system 

Cheers, 
Steve

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 12:23:23 -0000

>Huh DKIM is for what then? Not sure what it was created for then? Why do

DKIM makes it easier to identify the actual sender of a message.  In
practice, its likely utility will be to recognize mail from people you
trust so it can bypass the filters.  As a sufficient fraction of real
mail is recognized, you can crank up the filters on what's left.

I am surprised that any of this would be news to people who'd been
following the discussion here in recent months.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 17 Nov 2008 12:23:23 -0000

Regards,

---

From: David Wall <[email-masked]>
Date: Mon, 17 Nov 2008 08:55:40 -0800

> DKIM is not intended to reduce spam.

And yet so many have written articles to the contrary, including 
wikipedia. (search DKIM spam)

Since DKIM is intended to identify the sender, to ensure sent email is 
legit and hasn't been forged, then it would reduce spam if all senders 
did this because reputation matters.  For one thing, sending spam is 
illegal in many areas, so having proof a spam is yours would not be good 
from a legal defense perspective.  Second, blacklisting with provably 
bad senders would be be more useful than some of the "random proof" 
blacklisting that goes on today.

Yes, if you are infected by a spambot, you will send signed spam.  But 
if I can prove your system is sending spam, it may be easier and quicker 
to get resolution to clean that system.  When most spam forges the 
sender, you can't complain to the purported sender that they are sending 
spam as it's not clear.  Furthermore, if your computer is "willfully 
neglected" and sends out such spam despite notices, you'll get 
blacklisted, perhaps held accountable as a spammer under the law, and if 
ISPs don't knock off such abusing users, they will get blacklisted or 
perhaps held accountable, too.

With clear identification, spam and virus sending will go down in my 
opinion, regardless of whether that's the intent of a given technology.

Of course, like all such solutions, the real key is to get receiving 
systems to start demanding such security be in place to accept email.  
Step 1 is to get senders to use it, to be sure, since you need a good 
base of senders before anybody would block on the receiving end, but 
spam won't stop until step 2 is done, which is to block unless the 
sender is so identified.

David

---

From: Steve Atkins <[email-masked]>
Date: Mon, 17 Nov 2008 09:34:12 -0800

On Nov 17, 2008, at 8:55 AM, David Wall wrote:

> Since DKIM is intended to identify the sender, to ensure sent email  
> is legit and hasn't been forged, then it would reduce spam if all  
> senders did this because reputation matters.  For one thing, sending  
> spam is illegal in many areas, so having proof a spam is yours would  
> not be good from a legal defense perspective.

Someone intentionally sending spam will not use a DKIM identity easily  
associated with a legal identity. Either they'll be quite honest about  
sending the email, or they'll obscure anything that can connect them  
to the email, including a DKIM identity. Scarlet fish.

>  Second, blacklisting with provably bad senders would be be more  
> useful than some of the "random proof" blacklisting that goes on  
> today.

You cannot use DKIM for blacklisting, for reasons discussed later.  
Another scarlet fish.

>
>
> Yes, if you are infected by a spambot, you will send signed spam.   
> But if I can prove your system is sending spam, it may be easier and  
> quicker to get resolution to clean that system.

You can do that now. Peer IP address is perfectly good for that  
(despite valiant attempts by NAT vendors to make it less useful).

> When most spam forges the sender, you can't complain to the  
> purported sender that they are sending spam as it's not clear.   
> Furthermore, if your computer is "willfully neglected" and sends out  
> such spam despite notices, you'll get blacklisted, perhaps held  
> accountable as a spammer under the law, and if ISPs don't knock off  
> such abusing users, they will get blacklisted or perhaps held  
> accountable, too.
>

That's, at best, wildly optimistic.

> systems to start demanding such security be in place to accept  
> email.  Step 1 is to get senders to use it, to be sure, since you  
> need a good base of senders before anybody would block on the  
> receiving end, but spam won't stop until step 2 is done, which is to  
> block unless the sender is so identified.

Anyone who is familiar with the history of SPF can guess where this  
line of reasoning ends up.

DKIM has a critical feature that seems to consistently confuse people  
who try and use it as part of some anti-spam contraption:

"It is possible for an email to be validly DKIM signed when sent, yet  
not validly DKIM signed when it is received. "

Any number of forwarding systems and some MTAs will, in some cases,  
modify the body of a message, often just by modifying the encoding or  
moving MIME around in order to be able to forward it on correctly.  
Those cases are rare, but they do occur. And they're, to some extent,  
a systemic error specific to a particular sender or recipient (so one  
recipient may never see the problem, while another recipient may see  
it in a large fraction of their email). This is conceptually similar  
to the SPF/.forward problem.

That means that if you receive a message that is DKIM signed, you know  
for sure that the message was signed by someone who was authorized by  
the domain owner to do so - the signing domain takes responsibility  
for the message.

But if you receive a message that is not DKIM signed that doesn't tell  
you anything. Maybe the message wasn't DKIM signed when it was sent.  
Maybe the body was modified in transit, so it was DKIM signed when it  
was sent, but isn't now. (You can't guess which of those cases it was,  
as there's no way to distinguish between a DKIM signature invalidated  
by modification in transit and a cunning forgery intended to look like  
a DKIM signature invalidated by modification in transit)[2].

That means that DKIM is a single positive assertion ("this message was  
authorised by $DOMAIN") about an email, and nothing more. Lack of DKIM  
means nothing, and makes no negative assertion about the email. Any  
attempt to use the inverse of DKIM to mean something (taking some  
subset of email and asserting that any email within that subset that  
is not DKIM signed at receipt is not legitimate email) is based on a  
logical fallacy, and will lead - at best - to false positives if used  
to reject email.

(We really need some simple to remember fairy tale involving scrolls  
and wax seals and the dark and scary woods to simplify this  
explanation).

So, DKIM is useful for spam filters as it provides a persistent  
identifier for a sending entity, *not* because DKIM signed mail is  
unlikely to be spam[1]. Filters can build reputations, positive and  
negative, around those identities.

Any sender can choose to discard their current reputation and start  
over with a new, neutral reputation at any point. That means that  
senders who are sending generally wanted email will use DKIM to build  
and maintain good reputation, and get good delivery rates (even when  
they send similar email from a different IP address) because spam  
filters will recognize them as senders with a good history. Bad  
actors, those who are either knowingly sending spam or who know that  
their mail is not well received and that's leading them to get a  
negative reputation will tend to change DKIM identities, and their  
reputation will float somewhere around neutral.

DKIM is also useful for feedback loops, for the obvious reason that it  
gives a clear identity of someone who provably is responsible for the  
email.

And it would be possible to layer some other forms of shared  
reputation (third-party whitelists, for example) on top of DKIM, as  
long as that's done carefully and with a clear understanding not just  
of what a DKIM signature means but also what lack of such signature  
means. I'm not aware of anyone having done this yet, despite it being  
an obvious thing for phishing targets to consider.

But DKIM is just a device that lets you assert that a particular email  
was sent on behalf of a persistent entity. It's not intended to, and  
will not, reduce spam (even though the data it provides may be useful  
to some spam filter related systems).

Cheers,
   Steve

[1] At various points in the deployment process a DKIM signature may  
well have been a sign of the mail being spam, rather than otherwise,  
for some recipients.

[2] And maybe it's perfectly legitimate email that just wasn't DKIM  
signed for some perfectly good reason, but even ignoring that...

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 13:38:35 -0500

> mail is recognized, you can crank up the filters on what's left.

Although certainly possible that seems to reduce it to an enhanced
whitelisting support system.

DKIM is mostly attractive to combat phishing so if you get an email
from your bank which says "click here to enter your account
information" you have some confidence that the email is really from
your bank and not some miscreant.

There are two big challenges in DKIM tho, both very closely related:

1. It would seem to require some sort of reliable reputation
system. Just because your MUA says "DKIM checks out!" you still don't
really know who the mail is from, only that it's from who its headers
claim it's from. That is, it may only be telling you that this is
authentic phish from the phisher hisself!

"Reputation systems" don't come out of thin air. Insert all the
objections about creating a global system of trust.

2. Which leads to the obvious subversion which is for phishers to just
register plausible-looking domains like citig.roup.com (add in the IDN
hazards) or bankofamerica.customer-services.co (colombia, for example,
because it looks like .com), include valid DKIM info and voila, people
think it's ok and click the link.

Obviously even that could be mitigated with some sort of personal
whitelist service which might, for example, alert you that you have
never received email from this DKIM-verified domain before which might
be a hint that it ain't bank of america.

We need a term of art for when "solutions" seem to require more and
more layers of other crud seemingly invented as objections are raised
to make them plausible.

Personally I think DKIM will be of only minor help, in the "better
than nothing" category and mostly of use only to reasonably smart and
alert people.

Admittedly right now even pretty smart people don't have a way to
answer "hmm, is this email really from my bank?" short of being able
to read and interpret email headers shrewdly. DKIM might help them
with that, but they have to say "hmmm" or know what's at issue anyhow.

-- 
        -Barry Shein

The World              | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Barry Shein <[email-masked]>
Date: Mon, 17 Nov 2008 13:38:35 -0500

-- 
        -Barry Shein

---

From: Bart Schaefer <[email-masked]>
Date: Mon, 17 Nov 2008 10:44:45 -0800

On Nov 17,  9:34am, Steve Atkins wrote:
} Subject: [Asrg] Positive assertions vs negative assertions Re: The state o
}
} And it would be possible to layer some other forms of shared  
} reputation (third-party whitelists, for example) on top of DKIM, as  
} long as that's done carefully and with a clear understanding not just  
} of what a DKIM signature means but also what lack of such signature  
} means. I'm not aware of anyone having done this yet, despite it being  
} an obvious thing for phishing targets to consider.

Several months ago I encountered a encountered a company offering a
Goodmail-style service except that it was implemented by piggybacking
an extra identifier into the DMIM header.  I'm trying to dig up the
reference, I'll follow up if I find it.  (Does this sound familiar to
anyone else?)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 17 Nov 2008 15:40:54 -0600

David Wall wrote:
> Since DKIM is intended to identify the sender, 

Discussion about DKIM has been resistant to any effort at careful and contingent 
language.

DKIM won't reduce spam, per se.  It also won't reduce phishing, per se.  Both of 
these are forms of attack and DKIM does nothing to reduce the attacks.

What DKIM will help to do is to separate out some legitimate traffic from the 
noise (attacks) in the current traffic stream.

Further, to say that DKIM identifies the sender is a convenient and 
mostly-correct short-hand that turns out to be limiting, at best, and 
potentially misleading.

The language we've settled on for the Overview that has been approved by the 
working group:

    <http://dkim.org/specs/draft-ietf-dkim-overview-10.html>

begins with:

    "DKIM allows an organization to take responsibility for
    transmitting a message, in a way that can be validated by
    a recipient."

There is no requirement that that organization pertain to the author or the 
original poster of the message, or even be one of the operators in the transit 
path.  (That is, the label "sender" is highly ambiguous.) It can, for example, 
be a third-party that one of the handlers request to sign the message.

DKIM is about trust.  It enables the development of trust assessment for a 
message.  This does not have anything to do with MIS-trust assessment. 
Identifying spam and phishing about about assessing mistrust.

Given the rest of the necessary trust assessment machinery, DKIM will allow you 
to trust some aspects of a message.

The fact that you can trust one message does not mean you should trust or 
mistrust another.

A phishing message won't be participating in this trust exercise DKIM will have 
no impact on whether a recipient continues to succumb to a phishing message.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 Nov 2008 12:29:20 +0000

--On 17 November 2008 15:40:54 -0600 Dave CROCKER <[email-masked]> wrote:

>
> DKIM is about trust.  It enables the development of trust assessment for
> a message.  This does not have anything to do with MIS-trust assessment.

So, I can trust you and mis-trust you at the same time?

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 Nov 2008 12:31:47 +0000

--On 17 November 2008 15:40:54 -0600 Dave CROCKER <[email-masked]> wrote:

>
> A phishing message won't be participating in this trust exercise DKIM
> will have no impact on whether a recipient continues to succumb to a
> phishing message.

When dkim is widespread, I'd expect my email client to say "don't trust 
this message"  if it can't find a dkim signature.

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 18 Nov 2008 08:04:20 -0500

> blacklisting that goes on today.

<shrug> I don't see how.  We already have any number of well-known
senders out there who are equally well-known for sending spam over
long periods of time.  Yet many of them aren't blacklisted, or in
some cases, they are, but enough people have either not used the
blacklist or have used local whitelisting that the blacklist entry
is ineffective.

> to get resolution to clean that system. 

I'd like to buy into that, but I don't.  I don't think *any* mechanism
is going to motivate the former owners of a few hundred million zombies
to reclaim them and keep them that way.  (Not that I object -- I'm all
for it.  But it hasn't happened yet, despite the presence of compelling
evidence, and I don't think piling the evidence higher will change that.)

> systems to start demanding such security be in place to accept email.   

Agreed.  That's definitely the key; but the history of receiving systems
to date is that their keepers have displayed considerable reluctance to
cut off all but the most egregious offenders.  Until that attitude is
changed, it won't matter what technology we invent, because all it will
do is tell us again what we already know.

(This reluctance extends to more than mail by the way: look at what
it took to get Atrivo/Intercage disconnected -- and just as importantly,
look at how long it took: many years.)

---Rsk

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 18 Nov 2008 07:22:46 -0600

Do you use that same model in dealing with people?

You have some set of people you know you can trust, so you mistrust everyone else?

d/

-- 

   Dave Crocker

---

From: Dotzero <[email-masked]>
Date: Tue, 18 Nov 2008 09:40:33 -0500

> You have some set of people you know you can trust, so you mistrust everyone

Yay!  A juncture I may jump in at.

Just because I have to deal with people doesn't mean I have to trust
them. As I read this thread I have an image of Tina Turner dancing and
singing "What's Trust got to do with it..."
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 Nov 2008 15:57:33 +0000

> You have some set of people you know you can trust, so you mistrust

Yes. For example, I sometimes get calls from my bank, they start by asking 
for my security information. I don't give it to them, because I can't know 
who they are. If my phone were fitted with secure caller id, and could 
confirm it was the bank calling, then I might think differently.

Actually, I assign different levels of trust to different people.

I guess the phrase  "don't trust this message" might not be the best, but 
I'd certainly expect my email client to tell me about the dkim status in a 
way that was useful to anyone that speaks my language.

Also, I'd want to be able to tell my mail client who my bank is (etc), so 
it can tell me when email really is from them, and especially to alert me 
when an email is from a close but different address.

---

From: "David Nicol" <[email-masked]>
Date: Tue, 18 Nov 2008 10:39:49 -0600

On Tue, Nov 18, 2008 at 9:57 AM, Ian Eiloart <[email-masked]> wrote:

>  If my phone were fitted with secure caller id

Does that exist yet?  Last I checked, convincingly spoofing caller ID
is one of the fun things you can do when you start fiddling with
asterisk/freeswitch/etc
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Ian Eiloart <[email-masked]>
Date: Tue, 18 Nov 2008 17:03:38 +0000

--On 18 November 2008 10:39:49 -0600 David Nicol <[email-masked]> 
wrote:

> Does that exist yet?

I've no idea.

> Last I checked, convincingly spoofing caller ID

Probably not, then. :^(

---

From: der Mouse <[email-masked]>
Date: Tue, 18 Nov 2008 12:25:42 -0500 (EST)

>>> If my phone were fitted with secure caller id

Secure?  Against what?

Caller-ID is secure against a number of threats.  It's insecure against
another bunch.  (It's heading in the less-secure direction; the height
of the barriers against injecting random CLID are getting lower all the
time.)

>> Last I checked, convincingly spoofing caller ID is one of the fun
>> things you can do when you start fiddling with
>> asterisk/freeswitch/etc

Yes and no.  Asterisk and its ilk let you set caller-ID to whatever you
please, yes, but for it to be of any use for forging caller-ID in the
sense relevant here, your uplink to the PSTN has to accept and pass
along the caller-ID you set - an uplink willing to do that is the real
barrier.  (Access to such uplinks is steadily becoming cheaper, which
is why I say the barriers are getting lower.  For example, I have such
access, but most of my friends either don't have such access or don't
know how to use it if they do.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "John Johnson" <[email-masked]>
Date: Tue, 18 Nov 2008 11:40:03 -0600

> is one of the fun things you can do when you start fiddling with
   Which would explain why I'm getting phone spam from Florida
   which my caller ID happily displays country code 062 for.

   I'm pretty sure they are paying to call me, against my will, because
   my number is in some Federal "do not call" database. 
 
   The cost incurred doesn't seem to phase them a bit.

---

From: Barry Shein <[email-masked]>
Date: Tue, 18 Nov 2008 14:59:46 -0500

There are a number of services, some advertise incessantly on late
night TV here, which let you set the caller-id for a
call. Telespoof.com is one (not the late-night one, I don't remember
their name, something like dialtel.com but that's not it.)
123spoof.com also.

I believe the way they work is you call their number and enter an id
code and then the caller-id you want sent and the number. They
apparently have access to an SS7-capable switch (not my expertise so
apologies if that terminology's not quite right) so can inject
whatever caller-id they like.

The late night ads offer fooling your SO (e.g., yeah I'm home, can't
you see the caller id!), or tricking someone into picking up a call
they might not otherwise pick up.

-- 
        -Barry Shein

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 20 Nov 2008 09:58:55 -0800

On Nov 17, 10:44am, Bart Schaefer wrote:
}
} On Nov 17,  9:34am, Steve Atkins wrote:
} }
} } And it would be possible to layer some other forms of shared  
} } reputation (third-party whitelists, for example) on top of DKIM
} 
} Several months ago I encountered a company offering a Goodmail-style
} service except that it was implemented by piggybacking an extra
} identifier into the DMIM header.

It's brandmailsolutions.com in case anyone wants to check them out.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg