Douglas Otis | 8 Jun 03:05 2014

Re: WSJ/gmail/ML, was a permission to...

On May 5, 2014, at 1:19 AM, Michael Richardson <mcr+ietf <at>> wrote:

> John Levine <johnl <at>> wrote:
> [...]
>> Remember that there are other things that DMARC broke, that do not
>> involve forwarding.  That's what "WSJ/gmail" in the subject line are
>> about.
> Yes, I understand.  I'm not sure that web sites sending on my behalf
> is ultimately distinguishable from spam without some cryptographic route
> through the browser/webserver into my MUA.
> I can imagine such a channel, but I don't think we want to talk about that.
> I think that we should list the various problems that we have discovered and
> it may be that some we can fix, and some we can not.
> Ultimately, in the space of end-to-end SMTP, lists are a form of
> intermediary.  DMARC is a form of BCP38...

Dear Michael,

Cryptography will help secure many things, perhaps none better than SMTP-DANE.  But can a sending domain
make request without providing information necessary to avoid exposure of private exchanges by way of
insecure DMARC feedback. Talk about a major security hole. 

Email is currently being accepted based on fairly weak validation schemes.  DKIM does not even indicate who
sent the message nor is it expected to indicate to whom it was intended.  It seems that when there are strong
methods to validate email sources, there should be a way for a DMARC strategy to make authoritative
exceptions. DKIM Delegate seems to assume sending domains know which destinations can be trusted to the
(Continue reading)

Brandon Long | 6 May 19:34 2014

Re: WSJ/gmail/ML, was a permission to...

On Mon, May 5, 2014 at 7:03 AM, John R Levine <johnl <at>> wrote:
Those two problems can be solved in different ways.  Gmail could use a
third party's submission server just like they use its pop/imap one.

Gmail does allow you to use a third party submission server, and it looks
like we may have to encourage its use even more in the future.

I'm not sure how realistic that is in practice for users who aren't uber-nerds.

To set up to use Yahoo's submission server from Gmail, I tried to configure it in the popup Gmail provided, which failed with an error message that told me to go log in at Yahoo.  I did, didn't help.  After some poking around I found a message in my Yahoo inbox that suggested I needed an app specific password.  (How many people will realize that Yahoo considers Gmail to be an app?)  It provided a link to the place in their credential server to create such a password, which is otherwise not easy to find.  So I finally found it, and made a password for Gmail, and then went back to Gmail, and used it, and indeed it worked.

But how many people without CS degrees are going to be able to go through all that?

Yes, it runs up against that other problem, that username/passwords are no longer near useful enough.  In Gmail's case, you would only need an application specific password if you have one-time passwords enabled on your account.  The error message when trying to use your password would give you to this url: which should be enough for some non-CS types to figure it out.  Its less than ideal, however.

But, even then, we have which means that trying to use a password on an account isn't going to work all that well in the future.  OAUTH2 SASL is almost an RFC, but using it still has scaling issues for clients, in that there is no discovery/registration protocol yet.  Theoretically, once all that is accomplished and implemented, trying to authorize smtp-msa from one account to another via the web would be as simple as an ACL pop-up that you can agree to.

Clearly, that level of interop is a bit further away than we'd want any solution to the DMARC issue.


ietf-822 mailing list
ietf-822 <at>
Paul Smith | 6 May 12:12 2014

Re: WSJ/gmail/ML, was a permission to...

On 05/05/2014 07:01, Brandon Long wrote:
> Gmail does allow you to use a third party submission server, and it 
> looks like we may have to encourage its use even more in the future.

We're thinking that as well, or just stopping forwarding services at all.

The problem with forwarders using third party services' submission 
servers is that the user would need to give out their login details - 
which is a big issue. Maybe users should be able to create extra sets of 
authentication details for their submission servers, but ONLY for mail 
going to their own email addresses, for forwarding servers to use. These 
could still let the messages be blocked by a spam filter, but would let 
the receiving server know that the messages are coming from a forwarding 
server, so (a) the forwarding server's reputation should not be affected 
by spam from there, and (b) some checks like DKIM might have to be 

I suppose that a scheme like this could potentially be extended to 
mailing lists - when you subscribe, you give authentication details as 
well as an email address.


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

ietf-822 mailing list
ietf-822 <at>

Miles Fidelman | 5 May 20:42 2014

Re: WSJ/gmail/ML, was a permission to... (off-topic)

S Moonesamy wrote:
> Hi Miles,
> At 04:51 04-05-2014, Miles Fidelman wrote:
>> No. If I have a secretary make 20 copies of a letter, and drop it off 
>> at the post office, I'm still the author of the message.  A 
>> secretary, forwarder, mailing list, what have you, is acting on my 
>> behalf, as my agent.  The letter is from me, and the return address 
>> should be mine.
> Which MUA would you recommend for the secretary to send a message on 
> behalf of an author?

Well, I was using physical mail handling as an analogy, but... Outlook 
supports delegated access rights for sending on behalf of, as well as 
scheduling meetings on behalf of another mail user. Would a recommend 
Outlook - that's a separate question :-)

ietf-822 mailing list
ietf-822 <at>

Brandon Long | 5 May 20:32 2014

Re: one can re-sign without a permission to re-sign header

On Mon, May 5, 2014 at 1:50 AM, Paul Smith <paul <at>> wrote:
On 02/05/2014 15:42, John R Levine wrote:
I don't see any replay protection in here at all. Nothing that says to keep the signature expiration relatively short, and nothing which a mailing list recipient could not subsequently use to send spam. The first issue just needs a mention. It's the second issue that needs to be addressed IMO:

Yeah, that occurred to me about five minutes after I posted it. Here's a tweaked version where the mf tag is now mf=list.domain, with handwaving about how a may-forward signature doesn't count unless there's also a signature from the list domain.  Given lengthy discussions about how little abuse comes from real mailing lists, that'd probably be adequate.
Could this be 'extended' to include message-ids in the MF signature?

That would provide some replay protection, especially if the forwarder checks for duplicate message-ids (the recipient could also check for dupes). Without it, I could see one of your messages on a list, then send messages to everyone on the list, pretending to be you.

I was wondering if we wanted a new canonicalization which would allow for the Subject to be included but stripped of "standard" MLM subject prefixes, ie something similar to the reply_regexp in mutt (


ietf-822 mailing list
ietf-822 <at>
John Levine | 6 May 04:01 2014

Re: one can re-sign without a permission to re-sign header

>That would provide some replay protection, especially if the forwarder 
>checks for duplicate message-ids (the recipient could also check for 
>dupes). Without it, I could see one of your messages on a list, then 
>send messages to everyone on the list, pretending to be you.

You could, but now we're back to whether we believe that list managers
act to keep crud out of their lists.  In general, I observe that they
do, so I don't see any point to adding features that assume that
managers will just sit there and allow subscribers to abuse their

Anecdote: I am on one non-technical list where there is an extremely
obnoxious person who chronically poisons the dialog, yet the list
managers are unwilling to eject.  (My guess is that he is a large
donor to the organization.)  I have dealt with him by bozo filtering
his mail in procmail, but other people keep writing to me and asking
isn't there list software that will let subscribers decide which other
subscribers' mail to get, i.e. do the bozo filtering in the list
software.  As far as I can tell, no, because this is not a problem
that many lists have.


ietf-822 mailing list
ietf-822 <at>

Pete Resnick | 18 Apr 20:43 2014

Mailing lists - assumptions

[Bcc'ing dmarc, but directed to ietf-822, since that's where we appear 
to be having the discussion for the moment.]

These ideas about mailing lists have been rattling around in my head 
these past couple of days, and they're based on a bunch of design 
assumptions. So I figured I'd post my list of assumptions and see if 
anybody thought any of them were off in space.

1. The mailing list itself is going to have to participate in this in 
some way. There's no point in trying to design something for mailing 
lists that simply will not make any modifications.

2. In the end, we want mailing lists to be able to send messages that 
say "From: user <at>" and not have to say 
"From: list <at>".

3. If an originator sends mail to a mailing list, the originator is 
implicitly giving permission for the list to re-distribute the message 
"From:" the originator.

4. If an originating site allows its users sending mail to mailing lists 
at all, the site is OK with *any* mailing list re-distributing mail from 
its users. so long as the mailing list received the mail directly from 
the originating user through the originating site. That is, originating 
sites don't care about pre-vetting mailing lists; they just care that 
the mail sent by mailing lists came directly from their users.

5. For a recipient of mailing list mail, their site cares about whether 
the message they got came directly from the mailing list site, cares 
that the mailing list got the mail directly from the originating user's 
site, and cares that the mailing list got the mail relatively recently. 
For the most part, the recipient's site doesn't care how much has 
changed about the content of the message. The eventual recipient might 
care if the changes are in the extreme, but from a "is this spoofed 
spam" perspective, that really doesn't matter.

6. The mailing list cares about whether it got the message directly from 
the originating user's site.

7. An originating site would be willing to query (through a DNS lookup 
or otherwise) the first hop recipient for any message and stick 
something in the message that indicates, "This message came from 
originating user's site and was sent to recipient at such-and-so time", 
in order to facilitate #4 and #5.

8. The mechanism we use might need to chain: If I send to a mailing list 
A, which itself sends to another mailing list B, the eventual recipient 
will be able to see that the message it got came directly from B, which 
it got from A, which it got from me.

Anything I screwed up there? Any assumption I'm missing?



Pete Resnick<>
Qualcomm Technologies, Inc. - +1 (858)651-4478

ietf-822 mailing list
ietf-822 <at>

John Levine | 18 Apr 04:19 2014

A permission to re-sign header

As I understand it, the original sender puts a hard to forge single
use token in the message, which the forwarder can include in the
signed message.

Since I am lazy, I will reuse DKIM key records and invent a new
May-Resign header something like this:

May-Resign: f=marissam <at>;; s=foo; a=rsa-sha256; \
   t=1397786669; b=hashhashhash

This is a permission to re-sign for a message From:
marissam <at>, to be re-signed by a mailing list at The
s= and a= and t= are the same as DKIM, the b= is a signature of a hash
of the M-R header, similar to the b= signature in a DKIM-Signature.

The relay includes the M-R header in the DKIM signature.  So now
we modify DMARC to say that

IF there is a M-R header with f= that matches the From: line address,

AND the M-R header is included in a DKIM signature that is signed with
d= that matches the M-R r=

AND the M-R signature validates using the s= selector and f= domain

AND the t= isn't too old (for some meaning of too old)

THEN the message is considered to be aligned.

Is that the general idea?

You could put an M-R header on anything, but if you want to limit it
to mail to addresses that claim to be mailing lists, you could use the
same name convention as the DANE S/MIME draft, with hashed mailboxes,

<hash of ietf-822> TXT "v=MR1;"

That says the ietf-822 <at> list is signed with  If a
domain contains only mailing lists, you can use a wildcard

* TXT "v=MR1;"


ietf-822 mailing list
ietf-822 <at>

Vasiliy Faronov | 18 Feb 15:15 2014

List-Id on the receiving end


I'm looking for information on what receiving software does anything with the List-Id header as defined in RFC 2919. I'm especially interested in whether (and how) they process the list description phrase (section 3) if it's included.

Thanks for any pointers. (Not subscribed so please Cc.)

ietf-822 mailing list
ietf-822 <at>
Jan Kundrát | 29 Jan 21:08 2014

Correct value for EHLO when submitting mail

when a MUA submits e-mail over SMTP, what value shall be used in the 
HELO/EHLO greetings? Shall I just stick with "localhost", or trust the 
OS-reported hostname, if any, or shall I use the IP address of my local 

I see problems with all of these, and apparently Thunderbird went through a 
nice discussion on this matter [1]. I didn't find any answer about that in 
RFC 6409, unfortunately, and RFC 5321's discussion [2] about this topic 
leaves me without a definitive answer, either -- the MUA will have zero 
idea about the "primary host name" and its relation to what OS returns, so 
I'm inclinded to interpret this as a suggestion to use address literals, 
but then I've heard about spam filters penalizing such messages [1]...

What is the current best practice?

With kind regards,



Trojitá, a fast Qt IMAP e-mail client --
ietf-822 mailing list
ietf-822 <at>
Dave Crocker | 6 Jan 17:28 2014

Is RFC5322 a 'protocol'?

New year.  New time for abstract queries...

In spite of its title, I believe the *22 series of documents might 
qualify as a protocol, rather than "merely" as an object format 

The difference I see between a format and a protocol is that the latter 
specifies actions to take.

 From RFC 5322's basic specification, the parts of the document that can 
be argued to specify protocol is, therefore:

      Originator fields (From:/Sender:/Reply-to:)

Possibly also: <return>.

I suspect some of the additional fields that have been specified in 
separate documents similarly contain directions about actions to be taken.



Dave Crocker
Brandenburg InternetWorking
ietf-822 mailing list
ietf-822 <at>