IETF
EMAILCORE
emailcore@jabber.ietf.org
Wednesday, March 10, 2021< ^ >
Jim Fenton too has set the subject to: emailcore BOF @ IETF 108
Room Configuration
Room Occupants

GMT+0
[11:40:43] Meetecho joins the room
[11:42:09] Yoshiro Yoneya_ joins the room
[11:43:46] JcK joins the room
[11:50:06] Yoshiro Yoneya_web_624 joins the room
[11:50:06] Todd Herr_web_652 joins the room
[11:51:56] Daiki Ueno_web_634 joins the room
[11:52:34] Daiki Ueno_web_634 leaves the room
[11:53:24] Alessandro Amirante_web_616 joins the room
[11:54:21] Alexey Melnikov_web_910 joins the room
[11:56:13] Dave Crocker_web_182 joins the room
[11:56:50] Barry Leiba_web_553 joins the room
[11:57:19] Kazunori Fujiwara_web_713 joins the room
[11:57:38] Bron Gondwana_web_171 joins the room
[11:57:40] Kenneth Murchison_web_111 joins the room
[11:59:03] John Klensin_web_815 joins the room
[11:59:09] Trent Adams_web_386 joins the room
[11:59:12] Michael Breuer_web_422 joins the room
[11:59:15] Trent Adams_web_386 leaves the room
[11:59:25] Trent Adams_web_572 joins the room
[11:59:49] Harald Alvestrand_web_381 joins the room
[12:00:06] Hernâni Marques_web_543 joins the room
[12:00:41] hta joins the room
[12:01:15] James Galvin_web_395 joins the room
[12:01:33] Peter Koch_web_668 joins the room
[12:02:22] Takahiro Nemoto_web_234 joins the room
[12:02:25] Bernie Hoeneisen_web_959 joins the room
[12:02:26] Yoshiro Yoneya_ has set the subject to: emailcore @ IETF 110
[12:03:29] Murray Kucherawy_web_541 joins the room
[12:03:41] John Levine_web_715 joins the room
[12:06:13] Pete Resnick_web_277 joins the room
[12:09:12] Neil Jenkins_web_800 joins the room
[12:10:21] <Dave Crocker_web_182> Stray thought: SMTP cannot be used without 5322.  However the 5322 object /has/ been used without SMTP.  Making 5322bis depend on SMTP changes this.
[12:11:37] Tadahiko Ito_web_301 joins the room
[12:12:45] bhoeneis joins the room
[12:14:58] <Bron Gondwana_web_171> Pete: we heard you
[12:15:22] <Bron Gondwana_web_171> we here you as well Dave
[12:15:25] <Bron Gondwana_web_171> hear
[12:15:26] <Bron Gondwana_web_171> here
[12:15:47] <John Levine_web_715> i hear pete, not dave
[12:15:57] <Alexey Melnikov_web_910> Can hear Dave now
[12:17:06] Hernâni Marques_web_543 leaves the room
[12:17:16] <hta> a rather brutal form of echo cancellation?
[12:17:38] <John Levine_web_715> IMAP lets you put any random junk in the headers so I don't see the point in trying to guess how it might do that
[12:17:42] <Alexey Melnikov_web_910> I hate obs fields. I would rather remove them. But this is a separate issue
[12:18:03] <Alexey Melnikov_web_910> @John: IMAP references 5322
[12:19:12] <John Levine_web_715> +1 alexey
[12:20:35] <John Levine_web_715> also trace doesn't get helpfully reordered
[12:20:45] <Alexey Melnikov_web_910> Indeed
[12:21:37] <Alexey Melnikov_web_910> I don't think I agree with "no operational impact"
[12:26:37] <hta> If optional-fields float freely in the message, they terminate the trace-block, right? so received: / optional / received: is not a single trace block?
[12:27:35] <Alexey Melnikov_web_910> I agree with John. We should reflect reality
[12:28:13] <Alexey Melnikov_web_910> @hta: that is one of the questions to decide. See next slide
[12:28:34] <Alexey Melnikov_web_910> @hta: but yes, good question
[12:29:00] Gabriel Sullice_web_402 joins the room
[12:31:04] Neil Jenkins_web_800 leaves the room
[12:35:01] <hta> the meeting materials deck has a next slide...
[12:35:26] <Alexey Melnikov_web_910> @hta: it is on the next part of this topic
[12:35:46] Julian Reschke_web_172 joins the room
[12:38:11] Geng-Da Tsai_web_290 joins the room
[12:39:54] Gabriel Sullice_web_402 leaves the room
[12:46:18] Harald Alvestrand_web_381 leaves the room
[12:46:23] Harald Alvestrand_web_483 joins the room
[12:48:17] <Pete Resnick_web_277> @Dave: Just saw your post to the list and thereby your comment above. Missing piece of context: What dependency to 5321bis do you see in 5322bis? There shouldn't be a normative one.
[12:50:48] <Dave Crocker_web_182> @Pete, you and John K just had an exchange about doing a definition in 5321bis that 5322bis would use.
[12:52:05] <Dave Crocker_web_182> 5322/1.1: "(See [RFC5321] for a
   discussion of the envelope.)"
[12:52:10] <Pete Resnick_web_277> Ah, no, I think you misunderstood: 5322 (and 2822) have always said: This document doesn't define what to do with trace; go look at 5321 for more info. There's no proposal to change the general structure of that.
[12:52:51] <Dave Crocker_web_182> non-normative: /2.1.1: "However, there are so many implementations that
   (in compliance with the transport requirements of [RFC5321]) do not
   accept messages containing more than 1000 characters including the CR
   and LF per line, it is important for implementations not to create
   such messages."
[12:53:30] <Dave Crocker_web_182> 3.4.1: However, the domain portion contains addressing
      information specified by and used in other protocols (e.g.,
      [RFC1034], [RFC1035], [RFC1123], [RFC5321]).
[12:53:54] <Dave Crocker_web_182> 3.4.1: In both cases, how addressing is
   used and how messages are transported to a particular host is covered
   in separate documents, such as [RFC5321].
[12:53:55] <hta> CNAME pointing to A? DNAME at higher level pointing to synonym pointing to A?
[12:54:26] Hernâni Marques_web_953 joins the room
[12:54:36] <Dave Crocker_web_182> 3.6.7: Further restrictions are applied to the syntax of
   the trace fields by specifications that provide for their use, such
   as [RFC5321].
[12:54:37] <Peter Koch_web_668> I'd suggest this confuses protocol and policy
[12:55:01] <Dave Crocker_web_182> The 3.6.7 reference is interesting because it delegates further restrictions on use to 5321.
[12:55:43] <Pete Resnick_web_277> But none of those are normative dependencies; just pointing out that use of these things are defined elsewhere or restrictions might appear elsewhere.
[12:57:55] <hta> trace the records that mail.google.com points to and try to figure out whether it matches or not.
[13:00:02] <John Levine_web_715> I reject solely on non-match
[13:00:06] <John Levine_web_715> it's a very reliable botnet sign
[13:01:11] Geng-Da Tsai_web_290 leaves the room
[13:02:04] <JcK> and Pet's explanaton is why I'd prefer to retain this with SHOULD, but, again, if we are not going to retain at least SHOULD, then I think we take the paragraph out and rely on the A/S
[13:05:10] <Peter Koch_web_668> thanks, Dave, for very eloquently expanding my interjection!
[13:05:10] <Pete Resnick_web_277> I think Dave (and perhaps Peter K.) is correct insofar as this has *moved* from protocol to policy: It used to be quite clear that the match attempt was a thing that would cause interop problems. But now it has well moved into policy.
[13:06:11] <JcK> @Pete +1
[13:06:14] Hernâni Marques_web_953 leaves the room
[13:06:20] Hernâni Marques_web_380 joins the room
[13:07:41] Mark McFadden_web_317 joins the room
[13:08:00] <John Levine_web_715> It's totally policy: typically IPs are OK in submission, not in SMTP
[13:09:42] <Pete Resnick_web_277> Well, if it's submission, it's a different sort of issue. But would it be reasonable to use such things across the Internet to a pure SMTP server that happens to be OK with address literals?
[13:09:52] <Pete Resnick_web_277> I think it probably is.
[13:10:26] Niels ten Oever_web_255 joins the room
[13:10:42] Tomoko Nezu_web_176 joins the room
[13:12:41] <Bron Gondwana_web_171> Comment: we should just make all fields be CBOR
[13:12:44] Tomoko Nezu_web_176 leaves the room
[13:12:57] Pete Resnick_web_277 hopes that "how to fix it" doesn't include "change the quoted-string syntax in 5322".
[13:13:12] <Bron Gondwana_web_171> yeah, that - if we could change it then we'd use some kind of well defined structured format
[13:13:33] <Bron Gondwana_web_171> but we can't really do much more than bless the most common thing that's already in the wild
[13:21:50] Eliot Lear_web_674 joins the room
[13:34:28] Robert Stepanek_web_809 joins the room
[13:38:59] <Bron Gondwana_web_171> I was just gonna say that
[13:43:35] <bhoeneis> Timouts: I was wondering on the impact of spam mitigation practices applied by some servers, i.e. keep the connection open for a long time and hope the client will give up on sending.
[13:44:36] <Bron Gondwana_web_171> tarpitting - sending one character every 10 min
[13:45:18] <bhoeneis> Bron: not only tarpitting, but also simple delay the response.
[13:45:21] <Alexey Melnikov_web_910> Right, a.k.a. "slowlorries"
[13:47:14] <Bron Gondwana_web_171> that was a really productive meeting
[13:47:15] Tadahiko Ito_web_301 leaves the room
[13:47:19] Julian Reschke_web_172 leaves the room
[13:47:23] Yoshiro Yoneya_web_624 leaves the room
[13:47:26] Yoshiro Yoneya_web_348 joins the room
[13:47:35] <JcK> @Bron  +1... Thanks to co-chairs
[13:47:36] Barry Leiba_web_553 leaves the room
[13:47:39] Michael Breuer_web_422 leaves the room
[13:47:42] Dave Crocker_web_182 leaves the room
[13:47:44] Robert Stepanek_web_809 leaves the room
[13:47:46] Yoshiro Yoneya_web_348 leaves the room
[13:47:46] John Levine_web_715 leaves the room
[13:47:46] Harald Alvestrand_web_483 leaves the room
[13:47:46] Kenneth Murchison_web_111 leaves the room
[13:47:51] Eliot Lear_web_674 leaves the room
[13:47:52] Takahiro Nemoto_web_234 leaves the room
[13:47:54] <Bron Gondwana_web_171> Yes, thanks - good work keeping this one moving!
[13:47:55] Kazunori Fujiwara_web_713 leaves the room
[13:48:03] Hernâni Marques_web_380 leaves the room
[13:48:08] Yoshiro Yoneya_ leaves the room
[13:48:10] Murray Kucherawy_web_541 leaves the room
[13:48:14] Pete Resnick_web_277 leaves the room
[13:48:51] Bron Gondwana_web_171 leaves the room
[13:49:03] Alexey Melnikov_web_910 leaves the room
[13:49:06] James Galvin_web_395 leaves the room
[13:49:09] Trent Adams_web_572 leaves the room
[13:49:10] Todd Herr_web_652 leaves the room
[13:49:18] John Klensin_web_815 leaves the room
[13:49:45] JcK leaves the room
[13:50:11] Bernie Hoeneisen_web_959 leaves the room
[13:50:14] Alessandro Amirante_web_616 leaves the room
[13:50:14] Peter Koch_web_668 leaves the room
[13:50:14] Mark McFadden_web_317 leaves the room
[13:50:14] Niels ten Oever_web_255 leaves the room
[14:00:31] Meetecho leaves the room
[17:20:41] hta leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!