[09:20:15] --- resnick has joined
[09:32:00] --- resnick has left: Disconnected
[09:57:45] --- resnick has joined
[10:14:33] --- RBarclay has joined
[10:18:16] --- mrose has joined
[10:20:46] --- eric_allman has joined
[10:22:15] --- molson has joined
[10:22:57] --- eric_allman has left
[10:23:09] --- eric has joined
[10:23:42] <mrose> we're waiting 5 more minutes to begin...
[10:26:40] --- anewton has joined
[10:26:42] --- gconnor has joined
[10:27:18] <mrose> meeting begins
[10:27:26] <mrose> andy>agenda bashing
[10:27:50] <mrose> andy>instead of starting talking about the dns stuff, we're going to hear a presentation from harry, jim, and meng
[10:28:22] --- hardie has joined
[10:29:24] <mrose> jim>callerID==SPF, just a few details different(!!): 8821 or 8822, semantics of the check, and the format of the record
[10:30:07] <mrose> jim>spf:2821 - allows rejection at MAIL-FROM instead of DATA time, helps minimize joe jobs, but SRS is a pain
[10:30:24] <mrose> jim:caller-id:2822 - less works for forwarders
[10:30:46] <mrose> jim>convergence algorithm...
[10:31:15] <mrose> jim>2821 mail-from is overloaded in the sense that it can serve two different purposes
[10:32:15] <mrose> jim>pick a particular 2822 header (e.g., using the caller-id selection algorithm) and "promote" this to the 2821 envelope to explicitly recognize the bifulcation
[10:32:16] --- rand@sendmail.com has joined
[10:32:50] <mrose> jim>obviously, one must eventually make sure that this new envelope item (let's call it RFROM) corresponds to the 2822 headers
[10:33:17] <mrose> jim> if RFROM is missing, use caller-id like algorithm
[10:34:02] <mrose> jim> joe jobs should be solved using unilateral approach (we heard about three of them yesterday)
[10:37:42] <mrose> jim>note that the purpose of the RFROM is to optimize checking at MAIL-FROM time rather than DATA time
[10:39:01] <mrose> pete> since spammers won't put in a "bad" RFROM, isn't the RFROM a no-op?
[10:40:26] <mrose> jim>not clear if that's the case, spammers sending a lot of mail, may want to short-circuit their own bandwidth usage
[10:42:49] <mrose> jim>eventually require clients to send RFROM data if the server advertises that capability (if not present, treat RFROM=MAIL-FROM)
[10:44:09] <mrose> margaret>RFROM is useful for cases with legitimate mail that you may not want (i.e., things other than pure spam, such as aggressive marketing). RFROM will catch this stuff.
[10:44:34] <mrose> [note to room, as always, i'm paraphrasing what folks are saying...]
[10:45:10] <jlcjohn> (I'm nearly clueless what RFROM means)
[10:45:14] <mrose> jim>ideal goal is to remove the incentive to lie about who they are
[10:46:12] <mrose> jim>RFROM stands for "Responsible FROM" (more technically, the address returned by the caller-id algorithm)
[10:46:21] <jlcjohn> thx
[10:48:51] --- dcrocker has joined
[10:52:47] <dcrocker> RFrom means "latest sender" (injector into the transmission service)
[10:53:15] <mrose> jim> there are three concepts: who authored the thing, who caused it to be sent, who wants to see bounces. the second is RFROM, the third is MAIL-FROM.
[10:53:35] <gconnor> greg> My quick read on it was that RFROM puts "The Real Sender" back in 2821. Since 2821 MAIL FROM is really the return address, we would like to know "latest sender" aka "responsible sender" earlier than DATA.
[10:54:31] <gconnor> greg> thanks to dave for the clarification... I used the word "from" which is ambiguous and probably wrong
[11:01:00] <mrose> jim>next slide
[11:01:18] <jlcjohn> URL?
[11:01:48] <mrose> jim: basic case, no changes needed
[11:02:05] <mrose> jlcjohn - i'll ask
[11:02:14] <jlcjohn> thx
[11:03:32] <mrose> jim> mailing list example: EHLO/MAIL-FROM changes, list server must add a new header (Sender) and should validate incoming email, i should also generate RFROM
[11:04:12] <mrose> sorry, "it should also generate RFROM" (not "i")
[11:05:08] <mrose> jlcjohn - no url, but we'll mail the presentation to the mailing list now
[11:05:26] <jlcjohn> thx
[11:06:35] <mrose> jim>in other words, most list servers today are already compliant (they change ehlo/mail-from and add a Sender: header); going forward, they should also validate incoming messages and add an RFROM on outgoing messages
[11:08:04] --- RBarclay has left
[11:08:12] --- RBarclay has joined
[11:09:13] <eric> slides from this talk (translation may suck)
[11:09:45] <mrose> jim>forwarder example: the forwarded must add a Resent-From: header and should use RFROM; in the real-world, many do not add a Resent-From: header, so they would break.
[11:10:04] <eric> SPF and CallerID Convergence SPF and CallerID Convergence Meng Wong(pobox.com((Harry Katz(Jim Lyon(SPF and CallerID Convergence Meng Wong(pobox.com((Harry Katz(Jim Lyon(damn, i still can't get it into text, hold on....
[11:10:42] <mrose> jim> blackberry example: gateway must add Sender: header, should use RFROM.
[11:10:54] <mrose> jim> "Mail this page" is just like the blackberry example
[11:14:18] <eric> sorry, simplest format i can get it to is rtf.
[11:14:30] <eric> or html with frames
[11:14:47] <jlcjohn> either would be gret
[11:14:56] <jlcjohn> s/gret/great/
[11:15:15] <eric> well, let me try. it will be ugly.
[11:15:16] <mrose> or both
[11:16:01] <eric> ok, how can i do better that cut&paste of ugly junk?
[11:16:34] <resnick> I can put it on my .Mac web page.
[11:16:38] <mrose> not really possible. it may be okay to just forward the .ppt file to the list...
[11:16:41] <gconnor> eric- you could email the ppt to jlc, if he's the only one who needs it
[11:17:17] <gconnor> let's not send to the list unless jim agrees
[11:20:07] <mrose> jim> important distinction: this is an anti-forgery mechanism, not a comprehensive anti-spam mechanism
[11:20:58] --- Harry has joined
[11:26:02] <eric> ppt out to the list
[11:26:26] <mrose> jim> next slide: semantics of the check\
[11:26:53] <mrose> jim> spf=sequence of operations, caller-id=set-oriented; isomorphic relationship between the two
[11:27:46] <mrose> jim> convergence: use a sequence of operations to describe the algorithm; however, receivers allowed to reorder lookups (side-effects are not advisable/allowed)
[11:31:46] <eric> hah! finally figured out how to get it to text. I'll just do the examples and the current slide
[11:32:20] <eric> Example: Simple Mail • EHLO server3.alice.com • MAIL FROM:alice@alice.com • RCPT TO: bob@bob.com From: alice@alice.com To: bob@bob.com ... • Changes: None
[11:32:31] <mrose> jim>consider +mx, -exists:%i.rbl.com, +ptr:comcast.com, -all
[11:32:34] <mrose> eric - thanks
[11:32:43] <eric> Example: Mailing List • EHLO server3.alice.com • MAIL FROM:alice@alice.com From: alice@alice.com To: list@listl.com ... • EHLO server.list.com • MAIL FROM:list-bounce@list.com RFROM:list@list.com Sender: list@list.com From: alice@alice.com To: list@list.com • Changes: ListServ MUST add new header, SHOULD use RFROM. – Most already add header
[11:33:05] --- eric has left: Disconnected
[11:34:51] --- eric has joined
[11:35:10] <eric> sorry about that, i just seem to have figured out how to hang nitro...
[11:35:15] --- eric has left: Disconnected
[11:36:23] --- eric has joined
[11:37:29] <eric> this is not a happening thing. the slide i can't seem to paste in is about blackberry and other similar services -- MUST add Sender: alice@blackberry.net; SHOULD add RFROM:alice@blackberry.net
[11:37:34] --- Harry has left
[11:37:48] --- eric has left: Disconnected
[11:38:25] --- Harry has joined
[11:38:36] --- eric has joined
[11:38:47] <eric> ok, let me try getting rid of the bullets.....
[11:39:09] --- eric has left: Disconnected
[11:39:59] --- eric has joined
[11:40:03] <Harry> Let me try
[11:40:19] <eric> Go ahead, I'll seem to have to do it line at a time
[11:40:25] --- Harry has left
[11:41:08] <jlcjohn> I've got the PPT in OpenOffice -- does anyone else want the text?
[11:41:10] --- Harry has joined
[11:41:26] --- jthielens has joined
[11:41:41] --- Harry has left
[11:42:21] --- Harry has joined
[11:42:37] <Harry> Sorry, I keep crashing myJabber.
[11:44:29] --- Harry has left
[11:44:50] <mrose> jim>third issue
[11:45:12] --- dcrocker has left
[11:45:14] <mrose> jim> format of the record: spf does TXT with a new language, TXT with XML
[11:45:18] --- dcrocker has joined
[11:45:46] --- Harry has joined
[11:46:18] <mrose> jim> convergence: MARID RR uses XML, encourage folks to look for MARID and SPF (one interpreter and two parsers); if MARID RR present, don't consult SPF RR
[11:46:31] <mrose> jim> use DNS TXT record to store data
[11:46:43] <mrose> jim> choice of xml is to make it easier to extend
[11:48:53] --- Bill has joined
[11:51:54] <mrose> greg>we need to have an explicit limit on the number of recursions or dns lookups.
[11:52:19] <mrose> meng>the dns lookup limit will behave inconsistently based on caching...
[11:56:19] <mrose> jim> final slide: produce 3 I-Ds (coverged MARID, SMTP extension, Recommendations for MUAs), do WG iterations
[11:56:52] <mrose> jim> may also be a fourth, informational I-D on rationale, etc.
[12:04:26] <hardie> are there any updates to RFC 1464?
[12:05:37] <molson> No. At least, not from the original rfc 1464 author
[12:05:44] <eric> i don't think so -- i looked around for one a couple of months ago
[12:12:19] <eric> ted is talking about extensibility -- ignoring (e.g.) xml tags that you don't understand rather than throwing up your hands
[12:13:34] --- Bill has left: Disconnected
[12:14:39] <mrose> ted> please be careful with extensibility to make sure that results are deterministic if you don't understand a particular extension
[12:17:56] --- mengwong has joined
[12:20:03] <eric> my main concern is that we are going to have two languages from day one. but ordering them makes it acceptable.
[12:20:42] <mrose> eric - yes, that's a concern. it probably reflects the "reality on the ground", which may not be that bad, even if it's not optimal.
[12:23:51] <eric> yes. camels being horses designed by committee.....
[12:23:57] <mrose> pete> complexity worries me here
[12:24:26] <mrose> pete> handy/neat/cute is one end of the spectrum, necessary is the only one, it doesn't have to be at either extreme
[12:24:33] <hardie> pete doesn't like cute things. he likes necessary things;
[12:28:21] <gconnor> jim> suggests to have some more discussion on various individual mechanisms/features.... but hopefully there is approval of the general direction?
[12:28:41] <gconnor> (there seems to be general agreement of the direction)
[12:32:56] <mrose> meeting resuming at 10:55 us/pacific
[12:51:17] <mrose> dave crocker presenting
[12:51:56] <jlcjohn> URL?
[12:52:05] <mrose> no url
[12:52:10] <jlcjohn> thx
[12:53:20] <mrose> i take that back - http://brandenburg.com/presentations/CSV-SUMMARY.ppt
[12:53:49] <gconnor> http://brandenburg.com/presentations/CSV-Summary.ppt
[12:54:00] <mrose> thanks
[12:55:29] * Harry opens http://brandenburg.com/presentations/CSV-Summary.ppt
[12:55:48] <jlcjohn> I'm still trying...
[12:56:07] <rand@sendmail.com> the second link works
[13:00:18] --- DouglasOtis has joined
[13:02:07] <jlcjohn> (opened successfully on another computer)
[13:20:22] --- Bill has joined
[13:28:50] <mrose> ted>there is a concern about having multiple independent mechanisms
[13:31:02] <jlcjohn> (I'd like to understand the concern better.)
[13:31:34] <rand@sendmail.com> independant for authentication, authorization, accreditaion?
[13:31:46] <eric> as i understand it, is checking HELO info, MAIL FROM, or From: really independent?
[13:31:47] <rand@sendmail.com> or independant as in multiple authentication mechanisms?
[13:31:48] <mrose> csv is orthogonal from spf/caller-id
[13:34:09] <eric> discussion going about how CSV is not inherently transitive, unlike MAIL FROM (which gets passed between hops)
[13:34:13] <hardie> So question is if you had TLS with one of the mechanisms that provided identity, why would you need csv?
[13:34:25] <eric> kind of like how SMTP AUTH or TLS aren't really transitive
[13:35:36] <eric> ted: maybe because all clients must use EHLO but not STARTTLS (?)
[13:38:04] <jlcjohn> I think Dave earlier said you need CSV to validate HELO because it's the only way to validate the _channel_ the message travels over.
[13:38:43] <eric> TLS with auth validates that too
[13:38:50] <hardie> But this is not true; you could use the cryptographic client identity in TLS, if you wished to use that form of TLS
[13:39:09] <hardie> to jlcjohn, obviously, not eric
[13:39:52] <hardie> dialback, anyone?
[13:40:00] <eric> i think i understand why: to validate a TLS cert you have to already have the public cert locally (or have a PKI); EHLO info can be in DNS and hence not require prior arrangement
[13:42:38] <hardie> i use the term peer here, is that not usual?
[13:45:07] <jlcjohn> ted: I don't believe MTA-to-MTA is usually considered "peer".
[13:45:16] <resnick> I think peer is fine. It's just that SMTP is asymmetric.
[14:06:19] <mrose> now breaking for lunch
[14:12:39] --- dcrocker has left: Disconnected
[14:15:02] --- hardie has left: Disconnected
[14:21:45] --- hardie has joined
[14:21:59] <hardie> Actually, now breaking; lunch is due in 20 minutes
[14:24:11] <mrose> ed lewis starts with a presentation
[14:25:19] <mrose> presentation will be sent via email...
[14:25:34] <mrose> ed> DNS considerations for the MARID WG (why TXT is bad)
[14:26:06] --- hardie has left
[14:26:06] <mrose> ed> context: presentation discusses past experience in (un)successfully extending the DNS
[14:26:19] <mrose> ed> presentation is not proposing a benchmark, it's a discussion of ideas
[14:27:19] <mrose> ed> http://www.ietf.org/internet-drafts/draft-ymbk-dns-choices-00.txt is one of the inputs to this presentation
[14:28:30] <mrose> ed> two topics: wny MARID should use a new RR, what to consider when developing a new RR
[14:28:48] <resnick> http://homepage.mac.com/resnick/copy_MARID-DNS.ppt
[14:29:37] <mrose> dns summary: query/response protocol; query: domain, class, and type; response: RR set; some ancillary data (e.g., message flags internal to DNS)
[14:30:23] <mrose> i'll stop scribing the slides and go back to scribing various comments
[14:31:06] <mrose> ed> now talking about four strategies for extending the dns
[14:31:59] <mrose> ed> subtyping: select a subset of the RRs based on what you're looking for (e.g., look at each TXT and decides which one are relevant).
[14:33:31] <mrose> unk> what about an IANA registry for TXT RRs?
[14:33:52] <mrose> ed> it's a possibility, though it's a longer road.
[14:35:01] <mrose> unrelated for the emacs users: http://ejab.sourceforge.net/
[14:35:32] <mengwong> maybe we should just use SNMP
[14:36:06] <mrose> for jabber? that might work.
[14:36:16] <mengwong> for the MARID record
[14:36:29] <mengwong> voila, namespace problems solved
[14:36:51] <eric> that's what i really want to do: open up SNMP through my firewall. NOT
[14:36:51] <mengwong> or, maybe, LDAP.
[14:37:11] <mengwong> there's also always gopher.
[14:41:10] --- hardie has joined
[14:43:53] <mrose> ed> interaction between wildcards and SRV was not as thought out as it might have been
[14:44:37] <jlcjohn> (could you give slide # once in a while?)
[14:44:44] <mengwong> 10
[14:44:44] <eric> 10
[14:44:48] <jlcjohn> thx
[14:46:02] <mrose> ed>anytime we've tried to say "by convention anytime this application wants information about this name, look at this subdomain", we've had problems
[14:48:06] --- yakovsh has joined
[14:51:51] <eric> lots of discussion about wildcards and name prefixes, e.g., _app.*.example.org doesn't work, but SRV uses it anyway
[14:53:47] --- dcrocker has joined
[14:54:31] <mrose> slide 11
[14:54:49] <mrose> slide 12
[14:56:07] <mrose> page 13
[14:58:12] <mrose> ed> only about 60 RR types allocated (about 64K possible)
[14:58:59] --- yakovsh has left
[15:00:51] <mrose> my favorite quote: "the dns is not very good at reasoning"
[15:02:37] <mrose> phil> we really do need to talk about SRV
[15:03:58] <mrose> phil> wildcards aren't a requirement, so they shouldn't be a problem.
[15:04:29] <mrose> 5 minute break to grab lunch
[15:10:19] <mrose> break over, speaking continues
[15:10:22] <mrose> slide 13
[15:12:10] --- Bill has left: Disconnected
[15:13:44] <mrose> eric> do classes still work?
[15:14:15] <mrose> ed> not really, the only deployment (HESIOD) required the two trees be isomorphic with the IN class.
[15:14:59] <mrose> ted>independently of this, there was some work on trying to get classes working again, but that's far afield from this (i.e., you don't want to fix that before doing marid)
[15:18:06] <mrose> slide 14
[15:18:06] --- rand@sendmail.com has left: Disconnected.
[15:19:30] <mrose> jim>doesn't name altering allow you to avoid subtyping issues?
[15:20:15] <mrose> ed> doesn't agree, because you still can't control who assigns labels
[15:21:24] <DouglasOtis> Labels with the '_' character avoid names in the wild. IANA should register these?
[15:22:08] <mrose> i thought the iana did something like that as a consequence of the srv rfc, but i couldn't find the actual document that said that
[15:22:47] <DouglasOtis> SRV simply overlays a field unrelated to SRV.
[15:23:01] <mrose> ??
[15:23:24] <DouglasOtis> The names called out in SRV were not dedicated to SRV.
[15:23:37] <mrose> apparently not. let me check.
[15:26:46] <mrose> i can't find any IANA-specific rules/specs with respect to SRV
[15:28:26] <DouglasOtis> If there is a convention of using targets for MX to match the names of SRV records will allow a wildcard to be used on MX to discover SRV records devoid of ehlo hints.
[15:31:09] <mrose> slide 15
[15:33:08] <mrose> slide 16
[15:35:37] <mrose> slide 20
[15:35:54] <mrose> slide 21
[15:38:08] <mengwong> perhaps it would be a useful rule that during presentations, people may ask questions if they do not understand the point being made; but if people do not agree with the point being made, they should wait until the end.
[15:38:51] <mrose> dhc> there's a long history about "new RRs don't support well"... this introduces an awkward depenency.
[15:39:11] <mrose> good idea, but i think that ed is actually done presenting at this point...
[15:39:24] <gconnor> Right... though "expository" questions could go in either type
[15:43:35] <mrose> jim> the deployment friction is much worse than it firsts appears because some resolvers make rpc calls to a firewall, rather than doing dns directly.
[15:46:55] <hardie> I don't think he's done, but he may be done with the txt vs. new rr question, and is intending to go on from there to "what would a new RR look like"
[15:47:19] <mrose> ted - true.
[15:51:27] <mrose> unk> requiring a new resolver library would be problematic; independently, firewalls are deployed that screen udp traffic for "well-formed"...
[15:52:56] <mrose> phil> i'll talk to some firewall implementors and find out if the latter part is a big issue..
[15:59:50] <mrose> ted>perhaps we should consider a transition strategy wherein we define a syntax that can be encoded in both a TXT RR and a MARID (non-TXT) RR?
[16:00:52] <mrose> pete> doesn't this assume that the final record will be textual?
[16:01:23] --- yakovsh has joined
[16:01:54] --- dcrocker has left: Disconnected
[16:02:45] --- yakovsh has left
[16:11:43] <mrose> phil> we should define a RR for XML text, irrespective of marid's needs
[16:11:59] <DouglasOtis> http://www.ietf.org/internet-drafts/draft-dougotis-srv-caa-00.txt uses TXT record with the same label...
[16:12:12] * mengwong agrees with phill.
[16:12:30] <mengwong> and then maybe in the future we can do extensibility by having SRV point to the new XML type.
[16:13:51] <mrose> fundamentally, a generic XML RR is like a generic TXT record: if you're okay with overloading, then you're okay with it; if you don't like overloading, you won't like it.
[16:24:12] <hardie> pointer to sink record: http://www.watersprings.org/pub/id/draft-eastlake-kitchen-sink-02.txt
[16:24:25] <hardie> It says April, but not April 1; I wonder, though.
[16:24:36] <DouglasOtis> DNS is a limited resource. How the records are used depends largely upon the type of record. Using a '_' to prevent overlaps in the namespace gives the worst of all.
[16:26:28] --- randal has joined
[16:26:37] --- randal has left
[16:26:49] --- rand@sendmail.com has joined
[16:31:42] --- hardie has left
[16:32:33] <mengwong> so, is the problem with SRV that we can't do _ep.*.domain.com?
[16:33:08] <mengwong> firstly, isn't that something that we can get around with a clever DNS server that uses a regex handler?
[16:33:27] <mengwong> secondly, does this "zone cut" proposal make any sense for obviating the need for wildcards? http://archives.listbox.com/spf-discuss@v2.listbox.com/200404/0461.html
[16:33:53] --- hardie has joined
[16:33:54] <mrose> i don't know if that's the "SRV problem". it is the problem with adding a leftmost label and trying to use wildcards
[16:34:00] <mengwong> ok.
[16:34:30] <mrose> well, the issue i'd like to ask about in a bit is whether wildcards are a requirement?
[16:36:38] <mengwong> 20040520-14:45:31 mengwong@meng:~% dig +short random-wildcard.apple.com mx 10 mail-in5.apple.com.
[16:36:54] <gconnor> you say!
[16:37:48] <mengwong> yeah, apple uses wildcard mx.
[16:38:11] <mengwong> stuart cheshire at apple wrote to me commenting that SPF at apple would need a * TXT "v=spf1..."
[16:38:14] <mengwong> he was right.
[16:40:22] <DouglasOtis> SRV can return both the CNAME and addresses in one query.
[16:42:04] <gconnor> Doug- You are correct... that is true of any query of a CNAME
[16:42:23] <mrose> re: apple and wildcards, the problem, of course, is when you have to do set arithmetic with wildcards. as with most well-designed things, simple things are simple to do, hard things are hard to do...
[16:42:35] --- mrose has left
[16:42:51] --- mrose has joined
[16:51:50] --- rand@sendmail.com has left: Disconnected.
[16:53:17] <mrose> andy> let's talk about whether there is a wildcard requirement
[16:53:57] <mrose> phil> there are two wildcard issues: functionality and administration
[16:54:17] <mrose> andy> let's focus on deployment: do people need wildcard MARID records?
[16:55:21] <mengwong> phill> possibility of synthetic wildcards
[16:56:17] <mrose> pete> to clarify, if we do the "name hack" then wildcards don't work... hence the question.
[16:56:42] <mengwong> (unless we have people use synthetic wildcards so servers can match _spf.*.domain.com.)
[16:57:46] <resnick> right. as we said above, synthetic wildcards are a possibility, but would require code.
[17:00:52] <mengwong> gotcha.
[17:01:17] <mengwong> edlewis comments that the zone cut finder algorithm may not work very well in practice.
[17:23:22] <mrose> andy> new business?
[17:24:36] <mrose> pete>we are approaching a point on the internet, where bounces are being tossed
[17:36:29] --- Harry has left
[17:36:43] <mengwong> i'd like to talk about using a flag day to centralize these changes.
[17:38:31] --- mrose has left
[17:39:27] --- mrose has joined
[17:41:22] <DouglasOtis> It is simpler to exclude forged mail at the ehlo domain than Mail-From.
[17:50:23] <DouglasOtis> The new scheme from Meng and Microsoft depends on adding a new header that may be written by a third-party. The ISP SMTP Proxy stops working without rewritting content....
[17:51:12] <eric> new header? which one. it does have a new MAIL parameter.
[17:52:43] <DouglasOtis> The Meng and Microsoft proposal does add a new header.
[17:52:58] <eric> what is it? i didn't catch that this morning.
[17:53:14] <DouglasOtis> It is called Fred. Or RFrom...
[17:53:27] <eric> yeah. that's a MAIL parameter, not a header.
[17:53:31] <mrose> i don't think it's a header. it goes in the SMTP envelope via an ESMTP extension
[17:53:59] <mengwong> i wrote down an outline at http://archives.listbox.com/spf-discuss@v2.listbox.com/200405/0199.html
[17:54:10] <eric> the mailing list example from this morning:
[17:54:19] <eric> EHLO server3.alice.com MAIL FROM:P<alice@alice.com> From:alice@alice.com To: list@list.com ... EHLO server.list.com MAIL FROM:list-bounce@list.com RFROM:list@list.com Sender: list@list.com From: alice@alice.com To: list@list.com
[17:54:55] <DouglasOtis> It is in the 2821 space.
[17:55:20] <eric> yeah -- headers are 2822. or are we using different words?
[17:55:39] <DouglasOtis> Sorry about the confusion then.
[17:55:56] <mengwong> we now need to distinguish, when talking about 2821, between 2821.mail-from and 2821.rfrom, which is really a foreshadowing of 2822.purported_responsible_domain.
[18:05:35] --- dcrocker has joined
[18:07:07] --- hardie has left: Disconnected
[18:18:04] <DouglasOtis> Mapping 2822 space is easier than 2821?
[18:19:12] --- hardie has joined
[18:22:14] <DouglasOtis> Hello helo?
[18:22:19] <hardie> hello
[18:22:53] <mrose> sorry, i'm putting out a fire at the moment.
[18:24:04] <DouglasOtis> Start with helo, then Mail-From and let the 2822 stuff use certs.
[18:24:22] --- molson has left: Disconnected
[18:26:19] <mengwong> what do we want? 2821! when do we want it? mmmm.
[18:27:39] --- DouglasOtis has left: Disconnected
[18:28:19] --- RBarclay has left
[18:34:06] <mengwong> draft 1: the definition of what senders ought to do to meet legitimacy standards: the RFROM, Resent-From, etc. this draft defines the semantics of what's in the enveloe and headers.
[18:34:22] <mengwong> draft 2: the description of the 2821 extension RFROM.
[18:34:33] <mengwong> draft 3: a BCP/Informational that .... um?
[18:34:46] <mengwong> draft 4: the rationale and "legislative intent"
[18:34:56] <mrose> draft 3: BCP about MUA practices
[18:35:46] <mengwong> what about "this is mx, this is a, this is ptr, this is exists, these are the macros"?
[18:36:19] <mrose> draft 1
[18:36:41] <mengwong> shouldn't we split that out in case we end up doing that check against the 2821.mail-from after all this is done?
[18:39:46] <mrose> perhaps, or probably, i think we need to see more how the docs come together to decide a few issues like that
[18:40:36] <mengwong> okay, we'll err on the side of more, modular, separated docs.
[18:40:57] <mrose> for now, i think that's a good strategy. we may need to revise it later, but it depends on how many docs, how thick, etc.
[18:43:24] <mrose> action #1: harry, jim, and meng to email a writing schedule to the mailing list on friday.
[18:47:55] <mrose> action #2: all parties to review IPR disclosures with respect to their proposals.
[18:49:16] <mrose> action #3: dave, doug to email a writing schedule to the mailing list on saturday.
[18:50:07] <mengwong> daniel quinlan will standardize the Received header format, and mention RFROM
[18:50:48] <mrose> action #4: daniel will write a draft describing a revision to the Received: header, and mention RFROM.
[18:52:28] --- gconnor has left
[18:53:24] --- resnick has left: Disconnected
[18:55:48] --- mrose has left
[18:56:32] --- mrose has joined
[18:56:53] --- hardie has left
[18:57:20] --- eric has left
[18:58:02] --- mrose has left
[18:58:19] --- yakovsh has joined
[19:00:32] --- yakovsh has left
[19:11:36] --- jthielens has left: Disconnected
[19:12:10] --- dcrocker has left: Disconnected
[19:15:09] --- anewton has left
[19:17:59] --- jlcjohn has left: Disconnected
[19:18:47] --- jlcjohn has joined
[19:25:13] --- mengwong has left: Disconnected
[19:32:48] --- gordonf has joined
[19:37:06] --- gordonf has left
[20:39:46] --- dcrocker has joined
[21:46:16] --- resnick has joined
[22:07:29] --- dcrocker has left: Replaced by new connection
[22:09:43] --- DouglasOtis has joined
[22:10:52] --- DouglasOtis has left: Disconnected