I support adoption; it's time to revisit this BCP as circumstances have
changed.
-Jim
On 5/9/20 8:50 AM, Valery Smyslov wrote:
> Hi,
>
> the chairs encourage WG members to more actively participate in the call.
> At the meeting a lot of participants expressed a favor of adoption,
> we ask these p
I’m probably joining in the middle of this conversation, but please be
patient with me:
On 19 Apr 2021, at 10:48, Eliot Lear wrote:
Hi Rich,
A few of us just had this discussion in another context. Try this:
CAs MUST populate a SAN.
Verifiers MUST use a SAN if present.
Verifiers MUST reject
On 8 Jul 2021, at 7:12, Salz, Rich wrote:
> A discussion started on the GitHub repo
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis about what is allowed
> for the wildcard character, such as in DNS entries in subjectAltName. I am
> about to publish a new draft which takes the old adop
On 8 Jul 2021, at 7:12, Salz, Rich wrote:
> I’d like to know what the WG thinks. As we’re not really using GitHub for
> discussion, please comment on this list.
I made a comment on the pull request that is beyond editorial, so I’d like to
bring that back to the list.
Section 6.4.3 begins (ess
On 12 Jul 2021, at 14:27, Salz, Rich wrote:
* that further validation happens outside (before, after, or in
parallel to) RFC 6125 processing.
It seems like it would be worthwhile for us to mention that in the
beginning.
Part of my problem is that I don’t know what the boundaries of RFC
6
Viktor Dukhovni and I have been corresponding with the originator of this
erratum, and I believe that this report should be verified. The last sentence
in the notes (about unusable TLSA records) should probably be removed because
it refers to a situation where DANE would not verify successfully.
Not to distract from the STS discussion, but I thought I'd point out
another approach to SMTP TLS 'encouragement' that I submitted a few
weeks ago: draft-fenton-smtp-require-tls-01. There has been some
discussion of this draft, primarily on the ietf-smtp mailing list and a
little on the perpass lis
On 03/25/2016 06:45 AM, Jeremy Harris wrote:
> On 25/03/16 12:09, Aaron Zauner wrote:
>>> On 25 Mar 2016, at 03:12, Jim Fenton wrote:
>>> REQUIRETLS is an SMTP service extension that allows an SMTP client to
>>> specify (via a MAIL FROM option) that a given messa
On 03/25/2016 07:24 AM, Jeremy Harris wrote:
> On 25/03/16 02:12, Jim Fenton wrote:
>> draft-fenton-smtp-require-tls-01
>> The idea here is that REQUIRETLS allows the SMTP client to override the
>> default "deliver even if you can't do it securely" behavior of
On 03/25/2016 11:24 AM, Viktor Dukhovni wrote:
> On Thu, Mar 24, 2016 at 07:12:43PM -0700, Jim Fenton wrote:
>
>> Not to distract from the STS discussion, but I thought I'd point out
>> another approach to SMTP TLS 'encouragement' that I submitted a few
>> w
On 3/25/16 3:19 PM, Viktor Dukhovni wrote:
> On Fri, Mar 25, 2016 at 12:35:02PM -0700, Jim Fenton wrote:
>
>>> If the entire goal is to ensure the integrity of the RFC 6125
>>> "reference identifier" used to authenticate the nexthop SMTP
>>>
On 4/4/16 3:14 AM, Jeremy Harris wrote:
> On 01/04/16 23:18, Viktor Dukhovni wrote:
>> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote:
>>> I feel very strongly that policy for SMTP relay should be advertised by
>>> SMTP and protected by SMTP TLS.
>> Unfortunately, in MTA-to-MTA SMTP,
On 4/4/16 5:45 AM, Jeremy Harris wrote:
> On 04/04/16 13:01, Jim Fenton wrote:
>> On 4/4/16 3:14 AM, Jeremy Harris wrote:
>>> On 01/04/16 23:18, Viktor Dukhovni wrote:
>>>> On Fri, Apr 01, 2016 at 06:48:00PM -0300, Chris Newman wrote:
>>>>> I feel very
On 4/11/16 1:45 PM, Stephen Farrell wrote:
> - We can, and probably will, define a "webby" to achieve
> the same desired effect of getting beyond opportunistic
> security. Daniel and co's STS aprooach (as outlined for
> the next revision in B-A) is one such, and seems like
> it's one that c
On 4/13/16 10:43 AM, Chris Newman wrote:
> DANE is merely one method of validating a certificate, there can also
> be SMTP policy orthogonal to DANE. Take for example, DEEP’s “tls11”
> and “tls12” directives. Those specify a minimum acceptable version of
> TLS for future connections. Although we ha
On 4/15/16 5:28 AM, Eric Rescorla wrote:
>
> On Thu, Apr 14, 2016 at 10:38 PM, Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote:
>
> On 4/13/16 10:43 AM, Chris Newman wrote:
>> DANE is merely one method of validating a certificate, there can
>> also
On 4/16/16 10:23 AM, Chris Newman wrote:
>
>>> So while Viktor made a compelling case that the TLS version directive is
>>> not appropriate for SMTP relay, I think it is appropriate for the MUA STS
>>> scenario where it’s simpler to implement, where very old MUAs are in wide
>>> use requiring
On 4/25/16 6:49 AM, Leif Johansson wrote:
> On 2016-04-25 15:37, Leif Johansson wrote:
>>
>> Thanks,
>>
>> In BA there was consensus (pretty strong at that) to adopt this draft as
>> a WG document.
>>
> s/this draft/these drafts/
>
> This is 2 (two) separate consensus calls. Please express your sup
On 5/12/16 6:48 AM, John R Levine wrote:
>
>>> We really need a threat model beyond "someone might be spying on me."
>>
>> Sorry, but I completely disagree. Because "someone" *is* spying on
>> all of us! It's called full-take and they do it in real-time. Have
>> you been reading the news since June
welcome.
-Jim
A new version of I-D, draft-fenton-smtp-require-tls-02.txt
has been successfully submitted by Jim Fenton and posted to the
IETF repository.
Name: draft-fenton-smtp-require-tls
Revision: 02
Title: SMTP Require TLS Option
Document date: 2016-08-16
Group:
Apologies for the very late reply; this slipped through the cracks somehow.
On 8/22/16 7:53 AM, Jeremy Harris wrote:
> On 16/08/16 23:09, Jim Fenton wrote:
>> Name:draft-fenton-smtp-require-tls
>> Revision:02
> - Section 2, bullet point discussing th
On 9/18/16 5:35 PM, Viktor Dukhovni wrote:
>> On Sep 18, 2016, at 6:47 PM, Jim Fenton wrote:
>>
>> Yes; I'm not sure why I singled out MX and CNAME because I know those
>> aren't the only ways of locating the server. I would propose to change
>> "confi
On 9/18/16 6:38 PM, Viktor Dukhovni wrote:
>> On Aug 22, 2016, at 10:53 AM, Jeremy Harris wrote:
>>
>>> draft-fenton-smtp-require-tls
> ion
>> Abstract
>>
>>The SMTP STARTTLS option, used in negotiating transport-level
>>encryption of SMTP connections, is not as useful from a security
>>
On 9/19/16 10:19 AM, Viktor Dukhovni wrote:
>>
> In the face of DANE and STS, some users may encounter transient
> difficulties with mail delivery to some domains due to security
> policy and the failure of the receiving domain to correctly
> maintain their certificates and/or TLSA records.
>
> Use
It has been a little while, so I thought it might be appropriate to give
the WG an update on the status of REQUIRETLS
(draft-fenton-smtp-require-tls-02).
There are now two prototype implementations:
- Exim implementation by Jeremy Harris (announced on UTA list on 2
September)
- MDaemon implement
On 12/6/16 6:19 PM, Viktor Dukhovni wrote:
> On Tue, Dec 06, 2016 at 04:30:32PM -0800, Jim Fenton wrote:
>
>> It has been a little while, so I thought it might be appropriate to give
>> the WG an update on the status of REQUIRETLS
>> (draft-fenton-smtp-require-tls-02).
>
On 12/10/16 1:55 AM, ned+...@mrochek.com wrote:
>> On Fri, Dec 09, 2016 at 04:13:08PM -, John Levine wrote:
What would (for example) be the result if a client requested both
the REQUIRETLS and a separate MAYTLS feature?
>>> Given that mail servers will do whatever they wany with REQUI
On 12/16/16 3:31 PM, Viktor Dukhovni wrote:
>> On Dec 16, 2016, at 5:53 PM, Jim Fenton wrote:
>>
>> It seems that Viktor and I have differing views on the usefulness of
>> MAYTLS and REQUIRETLS. That said, I agree that it doesn't make sense to
>> have two me
Are there plans for a UTA WG meeting in Chicago?
If so, I'd like an opportunity to present an update on REQUIRETLS,
including recent updates to the spec (which I will have revised by then)
and info on our initial interoperability testing.
-Jim
___
Uta
nt is to meet in Chicago and progress the work.
> Please, share your plans (drafts, etc.) for the upcoming meeting and request
> a slot ASAP by Feb 9th.
>
> Thank you,
> The chairs.
>
> -Original Message-
> From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Jim Fen
A new version of I-D, draft-fenton-smtp-require-tls-03.txt
has been successfully submitted by Jim Fenton and posted to the
IETF repository.
Name: draft-fenton-smtp-require-tls
Revision: 03
Title: SMTP Require TLS Option
Document date: 2017-02-13
Group
Below are comments from my recent reading of draft-ietf-uta-mta-sts-03.
The biggest concern I have is the relationship between the DNS TXT
record and the HTTPS policy record. The policy is hosted in HTTPS rather
directly in DNS in order to attempt to provide security without DNSSEC.
But if attacks
On 02/23/2017 01:01 PM, Daniel Margolis wrote:
> Hey, thanks for the feedback. Comments inline.
>
> On Wed, Feb 22, 2017 at 1:55 AM, Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote:
>
> Below are comments from my recent reading of
> draft-ietf-uta-mta-
Responses inline.
On 3/3/17 4:36 PM, Viktor Dukhovni wrote:
>> On Feb 14, 2017, at 12:51 AM, Jim Fenton wrote:
>>
>> A new version of I-D, draft-fenton-smtp-require-tls-03.txt
>> has been successfully submitted by Jim Fenton and posted to the
>> IETF
On 3/27/17 1:21 AM, Viktor Dukhovni wrote:
>> On Mar 27, 2017, at 4:08 AM, Federico Santandrea - Diennea
>> wrote:
>>
>>
>> Let's suppose the sending MTA finds the MTA-STS TXT record, which states
>> the receiving domain has an MTA-STS policy. The draft says "To discover
>> if a recipient domain
[removing saag list because this is probably at a lower level of detail
than appropriate there. But feel free to add them if I'm wrong]
My sense that there is a "BCP part" to the draft is probably more
clearly stated that there are really two different things described in
the draft, as the draft i
Rolf, thanks very much for your review, including the nitpicking.
Responses to a few items below.
On 07/22/2017 02:57 PM, Rolf E. Sonneveld wrote:
>
> Page 4:
>
> this option MUST only be specified in the context
>of an SMTP session meeting the security requirements that have been
>specifi
On 7/12/17 3:11 AM, Leif Johansson wrote:
> This starts a 3 week working group last call (WGLC) on
> draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list
> by Wednesday
> August 2nd.
General comments:
All of the references are listed as normative, which I strongly suspect
isn't
On 8/1/17 2:11 AM, Alexey Melnikov wrote:
> Jim,
> I would like to disagree:
>
>> On 1 Aug 2017, at 00:02, Jim Fenton wrote:
>>
>> Section 5.3, I don't think it's a good idea to define and require new
>> message header fields for this. This means that s
On 8/1/17 1:02 PM, Alexey Melnikov wrote:
> On 01/08/2017 19:41, Jim Fenton wrote:
>> On 8/1/17 2:11 AM, Alexey Melnikov wrote:
>>> Jim,
>>> I would like to disagree:
>>>
>>>> On 1 Aug 2017, at 00:02, Jim Fenton wrote:
>>>> A bette
On 08/01/2017 10:17 PM, Leif Johansson wrote:
>
> On 2017-08-01 22:08, Jim Fenton wrote:
>>
>> I don't think I was suggesting anything involving Subject. There's
>> already some of this in Section 5.3, and I'm not crazy about doing that
>> either, espec
In response to Leif's request for specific text for the larger issues:
On 7/31/17 4:02 PM, Jim Fenton wrote:
>
> General comments:
>
> All of the references are listed as normative, which I strongly suspect
> isn't really the case. Informative references need to be separ
On 8/9/17 6:33 AM, Alexey Melnikov wrote:
> Hi,
>
> (As a participant)
>
>
> On 09/08/2017 14:07, Brotman, Alexander wrote:
>> Jim,
>>
>> To be clear, you'd like to remove the headers (5.3) and filename
>> (5.1) sections, and have all the filtering based solely on the
>> subject that is specified i
On 8/10/17 10:46 AM, Viktor Dukhovni wrote:
> On Thu, Aug 10, 2017 at 10:02:41AM -0700, Daniel Margolis wrote:
>
>> If anyone else has read this far on the thread, I'm happy to get feedback
>> on this proposal from others on the list.
> Yes, please!
>
I have been following the discussion, although
On 8/10/17 4:07 PM, Viktor Dukhovni wrote:
>
> Under that condition, there's no need to wait to remove the TXT
> record, removal of the record (being a change in the record) will
> in this variant of the design trigger a refresh, and the sending
> MTA will see a "none" policy and proceed to promptl
; Title : SMTP Require TLS Option
> Author : Jim Fenton
> Filename: draft-ietf-uta-smtp-require-tls-00.txt
> Pages : 13
> Date: 2017-08-07
>
> Abstract:
>The SMTP STARTTLS option, used in negotiating tra
On 9/15/17 1:46 PM, Viktor Dukhovni wrote:
> On Fri, Sep 15, 2017 at 08:14:40PM +, Binu Ramakrishnan wrote:
>
>> One advantage of using a sub-domain is the ability to delegate STS policy
>> serving (and mail hosting) to a 3rd party service provider.
> If support for 302 redirects is added, perh
Oops, your earlier message fell through the cracks.
I will be in Singapore, and would like the opportunity to talk some more
about REQUIRETLS, now that it is a WG draft.
I'm also a little confused on the status of the other WG documents.
Apparently DEEP is ready for IETF Last Call? TLSRPT is in W
> On Oct 19, 2017, at 4:03 AM, Daniel Margolis wrote:
>
> Yes, I also don't see the point of vanity hosts, but I guess some people want
> this for some reason.
Maybe this was explained somewhere earlier in the thread and I missed it, but
can you explain what ‘vanity hosts’ are?
-Jim
_
> On Oct 21, 2017, at 2:40 PM, Viktor Dukhovni wrote:
>
>
>
>> On Oct 20, 2017, at 7:09 PM, Jim Fenton wrote:
>>
>> Maybe this was explained somewhere earlier in the thread and I missed it,
>> but can you explain what ‘vanity hosts’ are?
>
> A
> On Oct 24, 2017, at 5:10 AM, Daniel Margolis wrote:
>
> Regarding arguments in favor of supporting SNI, Jim made the best attempt in
> this thread to come up with a motivating use case, and I don't find it very
> compelling. In his example (where two hosting providers merge
> infrastructure
A slightly different view of things, inline:
On 10/25/2017 11:16 AM, Viktor Dukhovni wrote:
> We're losing track of a few facts here:
>
> - It is not the client that has enhanced security requirements,
> rather it is the recipient domain that is politely requesting
> enhanced security, and th
On 10/25/17 3:57 PM, Viktor Dukhovni wrote:
>
> The middle paragraph leaves room for setting a somewhat higher floor
> for authenticated channels, and it would not be entirely inappropriate
> for STS to provide some guidance to server operations of the required
> minimum security. Thus perhaps ser
On 10/24/2017 11:59 AM, Viktor Dukhovni wrote:
>
>> On Oct 24, 2017, at 2:48 PM, Jim Fenton wrote:
>>
>> Regarding a) above: I apparently missed this. Is there any other
>> circumstance where the certificate presented is matched against anything
>> other
On 11/1/17 3:59 AM, Daniel Margolis wrote:
> The decision to use policy-to-SAN matching instead of
> policy-to-hostname matching was discussed here
> (https://www.ietf.org/mail-archive/web/uta/current/msg01938.html). I
> think the WG was at the time largely in consensus (or we misread the
> consens
Hi,
On the flight to Singapore, I went through the latest mta-sts draft, and
have a number of comments. Some of these I have probably made before,
but (at the risk of belaboring old items) I think they warrant revisiting.
My overarching concern is whether MTA-STS would be effective against an
att
On 11/12/17 10:48 AM, Viktor Dukhovni wrote:
>
>> On Nov 12, 2017, at 6:01 AM, Jim Fenton wrote:
>>
>> An attacker that is positioned between mail servers to be
>> able to block the negotiation of STARTTLS probably is also positioned to
>> be able to block the _mt
On 11/13/17 8:06 AM, Daniel Margolis wrote:
> Hey, thanks to you both for the discussion. I'll try to centralize the
> issues here a little bit, if you don't mind.
Good summary, thanks for organizing it. Comments inline.
>
> > Security properties of policy discovery and risks of persistent MITM
>
On 11/16/17 3:29 PM, Viktor Dukhovni wrote:
> Just listening to the recording of the meeting about sensitivity of
> reports. One thing to keep in mind is that reports will often need
> to be sent to the very domain which is failing STS validation, so
> in fact one may well need to deliver the repo
On 11/16/17 3:49 PM, Viktor Dukhovni wrote:
> 1. I agree that REQUIRETLS=NO needs a header so it can be
>tunnelled via an "agnostic" MTA.
>
> 2. However, even REQUIRETLS=YES needs a header, because:
>
>a. Within an MTA a message may make multiple internal
> hops, for example processin
On 11/16/17 7:06 PM, Leif Johansson wrote:
>
> On 2017-11-17 03:55, Viktor Dukhovni wrote:
>>
>>> On Nov 16, 2017, at 8:56 PM, Leif Johansson wrote:
>>>
>>> The sense of the room in Singapore was that the semantics
>>> of REQUIRETLS=NO was sufficiently different from REQUIRETLS
>>> that it would b
On 11/17/17 6:28 AM, Eliot Lear wrote:
> I've been watching the back and forth and trying to get my hands around
> the technical issues between the two cases. The closest I see for a
> technical explanation in this thread is this:
>
>
> On 11/17/17 3:55 AM, Viktor Dukhovni wrote:
>> As I pointed o
On 1/16/18 1:53 PM, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Using TLS in Applications WG of the IETF.
>
> Title : SMTP Require TLS Option
> Author
Gentle reminder:
I haven't yet gotten any comments on this new version of the REQUIRETLS
draft, and would appreciate some review.
-Jim
On 1/16/18 1:58 PM, Jim Fenton wrote:
> This version moves the "REQUIRETLS=NO" option to a message header field,
> RequireTLS: No, and re
On 2/20/18 10:13 PM, Valery Smyslov wrote:
> Hi,
>
> this is the second working group last call (WGLC) for the "SMTP TLS Reporting"
> (https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/).
> The WGLC will be short and will last for one week till March the 1st. The
> document has received
On 3/2/18 4:06 AM, Valery Smyslov wrote:
> Hi Jim,
>
> just one comment:
>
>> Section 5.3 paragraph 3: "MUST match the value found in the filename"
>> but the value in the filename is only a recommendation (section 5.1). I
>> continue to lean toward not depending on values in other than the
>> mess
ndees: 50
>>> Conflicts to Avoid:
>>> First Priority: tokbind tls oauth secevent
>>>
>>>
>>>
>>>
>>> People who must be present:
>
Requiring that the selector have a particular name or name prefix
associates semantics with selector names, of which there is none. It
also requires the management (e.g., rotation) of more keys per domain.
There is a better way to do this. The s= tag on the key record (service
type) can be used to
On 3/22/18 12:59 PM, Daniel Kahn Gillmor wrote:
> On Thu 2018-03-22 15:17:18 -0400, Viktor Dukhovni wrote:
>>> On Mar 22, 2018, at 2:59 PM, Martin Thomson
>>> wrote:
>>>
>>> https://tools.ietf.org/html/draft-trammell-optional-security-not-00 is
>>> relevant.
>> A reasonable guiding principle,
On 3/23/18 1:19 AM, Tim Hollebeek wrote:
>> to (easy with e.g. Postfix header_checks):
>>
>> Require-TLS: NO
>> Subject: [insecure-delivery]: actual subject
>>
>> or (not easy with header_checks, but hides the subject tag):
>>
>> Require-TLS: NO
>> Subject: actual subject
> I th
On 3/26/18 5:40 PM, Brotman, Alexander wrote:
> So, we'd need to create a new Service Type (I see only * and email
> currently), correct? Could we alternately use the "n=" field and require
> that the note be set to "tlsrpt"? If we do add this, and the receiving party
> is unable to find the
uire TLS Option
> Author : Jim Fenton
> Filename: draft-ietf-uta-smtp-require-tls-02.txt
> Pages : 14
> Date: 2018-04-06
>
> Abstract:
>The SMTP STARTTLS option, used in negotiating transport-level
>en
Thanks for your review, Chris:
On 4/9/18 6:08 PM, Chris Newman wrote:
> On 6 Apr 2018, at 16:20, Jim Fenton wrote:
>> The major change in this version is the removal of the options (CHAIN,
>> DANE, and DNSSEC) from the REQUIRETLS SMTP option as discussed in
>> Lo
uire TLS Option
Author : Jim Fenton
Filename: draft-ietf-uta-smtp-require-tls-03.txt
Pages : 15
Date: 2018-06-22
Abstract:
The SMTP STARTTLS option, used in negotiating transport-level
encryption of SMTP connections, is not a
Valery,
Thanks for your review. Responses inline.
On 8/15/18 7:55 AM, Valery Smyslov wrote:
Hi,
here is my review of the document.
The draft is well written, however I found few places where it could be
improved.
1. Section 2:
In the following para:
In order to specify REQUIRETLS tre
On 8/23/18 6:49 PM, Viktor Dukhovni wrote:
On Jul 18, 2018, at 1:50 PM, Valery Smyslov wrote:
draft-ietf-uta-smtp-require-tls-03
In https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-03#section-4.2.1
bullet 3, the reference to DANE authentication is to RFC6698, but DANE for SMTP
is
In addition to the comment from Viktor a couple of weeks ago, I received
a suggestion off-list the other day that is worthy of discussion. The
submitter did not want to join the mailing list but did agree to the
terms of the Note Well.
The suggestion:
I had the idea, that it would be useful t
Author : Jim Fenton
Filename: draft-ietf-uta-smtp-require-tls-04.txt
Pages : 15
Date: 2018-09-26
Abstract:
The SMTP STARTTLS option, used in negotiating transport-level
encryption of SMTP connections, is not as useful
On 8/23/18 6:49 PM, Viktor Dukhovni wrote:
This is recognized in the Security Considerations:
Another active attack involves the spoofing of DNS MX records of the
recipient domain. An attacker having this capability could cause the
message to be redirected to a mail server under the
Thanks for your response, Dan. Comments inline.
On 10/19/18 10:40 AM, Daniel Margolis wrote:
Hey Jim,
I've been too busy to follow along on REQUIRETLS closely,
unfortunately, so I may be missing some context. Feel free to ignore:
One caveat on your last statement is that, /alone/, you canno
On 10/22/18 3:02 PM, Viktor Dukhovni wrote:
On Mon, Oct 22, 2018 at 11:46:27AM +0200, Daniel Margolis wrote:
Close, but this conflates two issues: (1) making sure that the MX record
hasn't been forged (which MTA-STS or DNSSEC in the mailbox domain will do)
and authenticating the mail server (wh
ut supporting multiple authn
mechanisms.
On Tue, Oct 23, 2018 at 11:09 PM Viktor Dukhovni
mailto:ietf-d...@dukhovni.org>> wrote:
> On Oct 23, 2018, at 5:05 PM, Jim Fenton mailto:fen...@bluepopcorn.net>> wrote:
>
>> And yet, my preference would have been to
I support the adoption of this; seems pretty straightforward.
But isn't it possible to point specifications like RFC 8314 to a BCP
somewhere so that we don't need to revise everything that references TLS
whenever there is a version update? Seems like a lot of unnecessary work.
If 8314 is bein
OK; shall I do an update or wait for more comments?
-Jim
On 12/4/18 7:11 AM, Alexey Melnikov wrote:
> Hi Valery,
>
> On 04/12/2018 15:00, Valery Smyslov wrote:
>> Hi,
>>
>> while preparing shepherd write-up for the draft I came across
>> one issue. IANA Considerations section contains the followi
On 1/5/19 7:05 PM, Alice Wonder wrote:
> Well since SMTP is point to point, if you depend upon encryption you
> need S/MIME or PGP and always will.
Yes, and remember that S/MIME and PGP only encrypt the message body.
There's still quite a bit of information in the message header and SMTP
transacti
On 1/7/19 12:33 PM, Franck Martin wrote:
It took years to deprecate RC4. DKIM still uses outdated cyphers, and
there are no new ones approved (yet) AFAIK.
See RFC 8463.
-Jim
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/ut
On 1/8/19 12:59 PM, John R Levine wrote:
> Adding to the excitement, every domain has its own name for the mail
> server, e.g., for foo.com the mail server name is mx1.foo.com, all
> pointing at the same IP address. (This is not unusual; Tucows
> hostedemail does the same thing with much longer na
Thanks for your review, Alexey. Responses and a few clarifying questions
below.
On 1/9/19 8:34 AM, Alexey Melnikov wrote:
> Hi,
>
> Sorry for the delay in reviewing this. I reviewed it in 2018, but
> needed to work on expanding/decoding my notes so that they become
> useful for other readers.
>
>
Thanks for the review, Stephan.
On 1/25/19 1:58 PM, Stephan Bosch wrote:
>
> I just quickly reviewed this document. I notice that this extension
> also applies to LMTP. Now, I wonder what should happen when Sieve [RFC
> 5228] is involved there, particularly when actions like "redirect",
> "reject"
Hi Russ,
On 1/26/19 7:27 AM, Russ Housley wrote:
> I have no problem with the protocol itself, but I do not understand how this
> specification can not have a reference to TLS.
It does have at least a couple of indirect references to TLS, through
STARTTLS (RFC 3207) and BCP 195. An informative r
On 1/27/19 2:32 AM, Stephan Bosch wrote:
Op 27/01/2019 om 06:13 schreef Jim Fenton:
The draft discusses situations where intermediaries (relays) might
generate bounce messages and the like, but doesn't deal with what are
effectively reply messages back to the originator of the me
On 2/20/19 11:14 PM, Adam Roach wrote:
> --
> COMMENT:
> --
>
> Thanks for the work everyone did on this specification. I'm happy to see the
> state-of-the-art for
On 2/21/19 7:50 PM, Ben Campbell wrote:
> --
> COMMENT:
> --
>
> Thanks for this. I am balloting "yes", but I have a couple of questions. (The
> first would border
On 2/21/19 6:07 AM, Alissa Cooper wrote:
> --
> COMMENT:
> --
>
> I support Benjamin's first three DISCUSS points.
>
> I feel like there are some fairly significan
On 2/21/19 8:55 PM, Benjamin Kaduk wrote:
> --
> DISCUSS:
> --
>
> I'm pretty sad to see that the "RequireTLS: no" header field has the
> name "require TLS" and th
On 2/21/19 7:07 AM, Eric Rescorla wrote:
> --
> DISCUSS:
> --
>
> I support Benjamin's DISCUSS.
>
> To elaborate on one point a bit: it seems to me that it's harmf
On 2/27/19 3:45 PM, Viktor Dukhovni wrote:
> On Tue, Feb 26, 2019 at 03:26:05PM -0800, Jim Fenton wrote:
>
>>>If a REQUIRETLS message is bounced, the server MUST behave as if
>>>RET=HDRS was present as described in [RFC3461]. If both RET=FULL and
>>>
On 2/27/19 2:10 PM, Eric Rescorla wrote:
>
>
> On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote:
>
> On 2/21/19 7:07 AM, Eric Rescorla wrote:
> >
> -
On 2/28/19 8:01 AM, Barry Leiba wrote:
To elaborate on one point a bit: it seems to me that it's harmful to
security to allow the sender to unilaterally override the recipient's
preferences that something be encrypted. To forestall one argument,
yes, the sender knows the content
On 2/28/19 9:42 AM, Eric Rescorla wrote:
>
>
> On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <mailto:fen...@bluepopcorn.net>> wrote:
>
> On 2/27/19 2:10 PM, Eric Rescorla wrote:
>>
>>
>> On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton
>> mailto:
1 - 100 of 116 matches
Mail list logo
