Paul Smith | 23 May 16:52 2016

SPF DNS query limits

In RFC 7208 section 4.6.4 we're told that the SPF implementation should 
limit the number of include, a, mx, ptr and exists to 10, and if that 
limit is exceeded then we MUST return a 'permerror' result.

1) is this limit of 10 for the whole evaluation process, or does it 
restart for each 'include'/'redirect'? I've presumed it's for the whole 
process otherwise the total number of DNS queries is effectively 
unlimited if you have many nested includes, and the purpose of that 
section seems to be to limit them.

2) Is this limit generally being stuck to by SPF evaluation functions?

The reason I ask is that our SPF implementation is regularly hitting 
this limit (eg one or two per minute on a low volume server).

For instance, we got a spam message claiming to come from 
(chosen at random from our incoming messages). That results in:

- - contains "a mx ptr" - so that's 
4 already
- - contains "" - so 
that's 5
- - contains 
- so that's 7
- - contains 
"" - that's 8
- - contains "a:..." - that's 9
- - contains 
"" - that's 10
(Continue reading)

John Leslie | 15 Apr 15:39 2016


   I'm currently caught up in a Spamhaus blackhole. :^(

   There should be a good place to discuss this! Any advice?

John Leslie <john <at>>

ietf-smtp mailing list
ietf-smtp <at>

Alexey Melnikov | 15 Apr 15:26 2016

New Mailing List to discuss email canonicalization?

I've been asked to create a new mailing list for discussing solutions to 
"are these 2 email addresses the same" problem which originated in the 
DANE WG. Should I just go ahead and do that or would people prefer to 
just discuss this topic on this mailing list?

Thank you,
Alexey, as ART AD.

ietf-smtp mailing list
ietf-smtp <at>

mostafa shahdadi | 29 Mar 21:13 2016

MTN Irancell

Sent from Gmail Mobile
ietf-smtp mailing list
ietf-smtp <at>
S Moonesamy | 28 Mar 18:45 2016

Re: New proposal: SMTP Strict Transport Security (off-topic)

Hi Mark,
At 08:08 28-03-2016, Mark Risher wrote:
>That disclosure was meant to remove any concern by making explicit 
>that the authors don't intend to restrict usage. Sorry if it 
>accidentally had the opposite effect.

It had the opposite effect; sorry about that.  I find the following 

S. Moonesamy 

ietf-smtp mailing list
ietf-smtp <at>

S Moonesamy | 25 Mar 23:54 2016

Re: New proposal: SMTP Strict Transport Security

At 18:45 20-03-2016, Mark Risher wrote:
>We have just submitted a proposal entitled SMTP Strict Transport 
>Security, which details a mechanism for protecting MTA-to-MTA email 
>traffic against TLS downgrade attacks and interception.

There is an IPR disclosure at

S. Moonesamy 

ietf-smtp mailing list
ietf-smtp <at>

Sean Leonard | 22 Mar 23:54 2016

BCP proposal: regular expressions for Internet Mail identifiers

Greetings IETF-SMTP Gods and Denizens (and dispatch):

Over the winter I worked on a new Internet-Draft that I would like to 
propose the IETF adopts: Regular Expressions for Internet Mail. The 
draft focuses on two identifiers: email addresses and Message-IDs.

The purpose of this standard (proposed as a Best Current Practice) is to 
have *IETF-vetted* expressions that implementers and non-mail standards 
authors can plug-and-chug without futzing with trying to interpret 40 
years of (occasionally conflicting and arcane) RFCs and implementation 
lore. There are many non-mail systems out there (read: nearly every web 
app, reservation system, customer database, etc. on Earth) that use or 
consume email addresses as identifiers, and their inability to accept 
the most obvious valid characters (like "+" or even "-"; I have used 
apps that do not even accept "-") is a great source of interoperability 
problems. (This document is also relevant to some other threads about 
the nature of email address identifiers in security artifacts such as 
certificates, PGP keys, and DNS records: anyone who is vouching for an 
email address ought to be sure that they are recording something that 
actually is a valid email address in the first place.) We should get 
this right now, before Unicode/EAI makes interoperability issues 50000x 
more expensive to correct.

The document is not meant to modify the mail standards, but merely to 
reflect and track them as they are updated over time.

As a first draft, the document is in rough shape and has extensive notes 
about issues that came up during R&D but have yet to be addressed. 
Significant areas that need adequate treatment include:
1. the impact of Unicode (EAI) on identifiers.
2. handling domain names, which comprise 50% of an email address, but 
perhaps 85% of the complexity when Unicode gets involved.
2. "deliverable email address" (complying with the modern SMTP 
infrastructure) vs. other kinds of email addresses (Internet Message 
Format, historic forms).
3. regular expression engines and grammars (i.e., which grammars to use, 
which are widely used and produce uniform results).
4. efficiency of the regular expressions.
5. different expressions for validation (testing), part extraction 
(capturing groups), decoding, encoding, and searching through text.
6. test vectors.

Hopefully the adoption of this work as an IETF item, coupled with input 
from those with extensive experience

(Thanks to John Levine, Pete Resnick, and others for taking initial 
questions and discussion on the topic.)
Discussion welcome. Thanks.


-------- Forwarded Message --------
Subject: 	New Version Notification for draft-seantek-mail-regexen-00.txt
Date: 	Mon, 21 Mar 2016 16:55:53 -0700
From: 	internet-drafts <at>

A new version of I-D, draft-seantek-mail-regexen-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-mail-regexen
Revision:	00
Title:		Regular Expressions for Internet Mail
Document date:	2016-03-21
Group:		Individual Submission
Pages:		24

    Internet Mail identifiers are used ubiquitously throughout computing
    systems as building blocks of online identity. Unfortunately,
    incomplete understandings of the syntaxes of these identifiers has
    led to interoperability problems and poor user experiences. Many
    users use specific characters in their addresses that are not
    properly accepted on various systems. This document prescribes
    normative regular expression (regex) patterns for all Internet-
    connected systems to use when validating or parsing Internet Mail
    identifiers, with special attention to regular expressions that work
    with popular languages and platforms.

ietf-smtp mailing list
ietf-smtp <at>

Franck Martin | 21 Mar 23:12 2016

Re: New proposal: SMTP Strict Transport Security

----- Original Message -----
> From: "David Schweikert" <david <at>>
> To: "Daniel Margolis" <dmargolis <at>>
> Cc: "Wei Chuang" <weihaw <at>>, "Mark Risher" <risher <at>>, ietf-smtp <at>
> Sent: Monday, March 21, 2016 1:12:12 PM
> Subject: Re: [ietf-smtp] New proposal: SMTP Strict Transport Security

> > I think there are a couple of options for addressing this that involve some
> > mechanism of policy "pointers". For example, you could instead say that the
> > policy RR ( is merely a pointer to either a HTTPS URI
> > (which contains the policy potentially served via an SNI-aware server) or a
> > new
> > DNSSEC-served record (depending on your preferred authentication
> > mechanism). By
> > this approach the perishable bits of a policy can be hosted by the MX
> > provider
> > and the *existence* of a policy still indicated by the policy domain owner.
> Yes. I was also thinking that having one level of indirection might
> better fit the SMTP model of mail domain and mail hosts. Let me make
> an example to see if I understand you right:
> The RR could contain the policy like
> "" and also publish that same information under
> Then, any client would need to
> access and authenticate two HTTPS resources:
> -   ->
> -     -> mx:... a:...

may be a CNAME could do the same ?

ietf-smtp mailing list
ietf-smtp <at>

Mark Risher | 21 Mar 02:45 2016

New proposal: SMTP Strict Transport Security

[cross-posting from UTA mailing list as well)

We have just submitted a proposal entitled SMTP Strict Transport Security, which details a mechanism for protecting MTA-to-MTA email traffic against TLS downgrade attacks and interception.

The initial draft is at and we hope to discuss this at the Buenos Aires meeting next month. While we have deployed a prototype/reference implementation among the authors, we are very open to feedback and suggestions from the broader group and look forward to your input.

Thank you for your consideration,


ietf-smtp mailing list
ietf-smtp <at>
Sean Leonard | 10 Mar 00:51 2016

"decoded local-part" for dane-smime and dane-openpgp

Currently, dane-smime says:
Section 3:

    1.  The user name (the "left-hand side" of the email address, called
        the "local-part" in the mail message format definition [RFC2822 <>]
        and the "local part" in the specification for internationalized
        email [RFC6530 <>]) should already be encoded in UTF-8 (or its
        subset ASCII).  If it is written in another encoding it should be
        converted to UTF-8.  Next, it is hashed using the SHA2-256
        [RFC5754 <>] algorithm, with the hash truncated to 28 octets and
        represented in its hexadecimal representation, to become the
        left-most label in the prepared domain name.  Truncation comes
        from the right-most octets.  This does not include the at symbol
        (" <at> ") that separates the left and right sides of the email

The problem is that this text does not distinguish between the 
local-part production, and the decoded (unescaped) local-part characters.

As I am discussing in another Internet-Draft elsewhere (in progress, not 
necessary to cover right now here), the local-part has evolved basically 
to be a string of Unicode scalar values, which may or may not be escaped 
or quoted. Specifically: <at>
"johnny\.apple" <at>
"johnny.ap\ple" <at>

all have the same local-part characters:

It is therefore appropriate that the local-part be isolated from the 
entire e-mail address production, and unescaped/unquoted (i.e., 
decoded). All three of the above examples should result in the same 
SHA-2-256 value, namely 
A3E3740AD57C3A2D1927DFED24B719FA8C4BBC006E1D0DE30670974B257D4FDD. Note 
that this issue has nothing to do with case.

While we are at it, RFC 5322 (Internet Message Format) still permits 
CFWS (but not RFC 5321 (SMTP)). Therefore, these also have equivalent 
local-parts: (seed!)  <at>
    (could be a song)
       (mis(ter)) "j\oh\" <at>

Note that the term "user name" is not really ideal or correct in 
draft-ietf-dane-smime-10. Details were already hashed out a long time 
ago and are discussed in RFC 5322 sec. 3.4.1 and RFC 5321 sec. 2.3.11.

I therefore propose the following text:
Section 3:

    1.  a.  The local part of the address ("local-part" [RFC5321]
        [RFC5322] [RFC6530]) is isolated and decoded, i.e., de-commented,
        whitespace-folded, unquoted, and unescaped, as appropriate. The
        resulting UTF-8 string is the "decoded local part". Note that
        the at symbol (" <at> ") that separates the left and right sides
        of the email address is not part of the local part.

        b.  The decoded local part is hashed using the SHA2-256
        [RFC5754 <>] algorithm, with the hash truncated to 28 octets and
        represented in its hexadecimal representation, to become the
        left-most label in the prepared domain name.  Truncation comes
        from the right-most octets.

I propose similar text for draft-ietf-dane-openpgpkey. Assuming we have 
agreement, I can tackle that draft accordingly.


ietf-smtp mailing list
ietf-smtp <at>

John R Levine | 9 Mar 21:46 2016

Re: [dane] Request DANE ALPS (another attempt to canonicalize local parts)

> [CC +PKIX]
> I greatly appreciate the cross posting in the parent, as I didn't realize
> there was a large body of work already developed in DANE on interpreting
> the email address local-part.

Not really.  There have been two drafts in DANE, one for storing PGP keys 
in the DNS, and one for S/MIME keys, and the authors have consistently 
ignored advice from the SMTP community that what they are doing is a bad 
idea and how to minimize the damage.

> I would agree that it would be very helpful to create a compatible email
> canonicalization or mapping scheme.

As I said a few messages ago, it is not an accident or a mistake that 
there is no canonical form for e-mail addresses.  We understand why some 
people wish it were otherwise, but the number of ways that MTAs map e-mail 
addresses is only slightly less than the number of MTAs, and the mappings 
are constantly changing.

It may be possible to figure out a way to use an SMTP server or maybe a 
web server connected to an SMTP server as an oracle, to ask do these two 
addresses deliver to the same place or to ask for a key or a certificate 
for an address, but even that is iffy.

We can't even say what it means for two addresses to be "the same". For 
example, on my MTA there about a thousand live addresses that deliver to 
the same inbox where your message was delivered, but that doesn't mean I 
want all of them to have the same PGP or S/MIME keys.


ietf-smtp mailing list
ietf-smtp <at>