[09:29:45] --- anewton has joined
[09:30:06] --- anewton has left
[09:58:21] --- mrose has joined
[12:47:20] --- jlcjohn has joined
[13:41:25] --- stpeter has joined
[13:43:36] --- stpeter has left
[13:43:36] --- stpeter has joined
[13:44:26] <stpeter> mrose: you should be good to go
[13:44:32] --- jhildebrand has joined
[13:44:43] <stpeter> jhildebrand: not much actually happening here :-)
[13:44:56] <jhildebrand> for the log: gordonf: presence.
[13:45:09] <stpeter> heh
[13:45:31] <jhildebrand> in IRC, there are only rooms, no "real" user2user stuff.
[13:49:06] <stpeter> does IRC have any security features? (authentication, channel encryption, etc.?)
[13:52:30] <jhildebrand> i am not an IRC expert. is RFC 1459 still canonical?
[13:52:38] <stpeter> AFAIK
[13:54:14] <stpeter> plus IRC has those problems with room hijacking I think (though I've not looked at it in a while)
[13:59:26] <jhildebrand> looks like rfcs 2810-2813 obsolete 1459, but are informational.
[13:59:47] * stpeter surfs
[14:31:23] --- gordonf has joined
[14:35:16] --- resnick has joined
[14:41:59] --- mrose has left
[14:42:05] --- mrose has joined
[14:46:43] --- yakovsh has joined
[14:52:04] <mrose> starting in two minutes.
[14:53:10] --- hardie has joined
[14:54:39] --- dcrocker has joined
[14:54:50] <mrose> welcome to the bi-weekly marid chat. a conflict has just come up for andrew, so he won't be joining us today.
[14:54:55] <mrose> a few administrative things before we start:
[14:55:20] <mrose> 1. depending on wg feedback, we may change the time/frequency of these chats.
[14:55:43] <mrose> 2. the chatroom is available 24/7, so if some folks need a place to chat about marid stuff, feel free to use this room if you wish.
[14:56:07] <gordonf> "Please keep the room clean and pick up after your dog." :-)
[14:56:12] <gordonf> (sorry)
[14:56:15] <mrose> 3. i'd like to limit these chats to an hour, though that's just a guideline, of course.
[14:56:37] <mrose> gordonf - that does remind me of one point, this room is logged!
[14:56:43] <gordonf> I noticed
[14:56:54] <mrose> ok, that's it. the topic is ...
[14:57:08] <mrose> open mic.
[14:57:47] <mrose> should i call on people?
[14:57:51] <hardie> Hmm. Interestingly, the chat room does not allow me to set a topic
[14:58:00] <hardie> we'll just have to remember where we are
[14:58:10] <yakovsh> the big debate has been so far between RFC2821 and RFC2822 identities
[14:58:41] <jlcjohn> perhaps Ted would like to explain his hangup about the difference.
[14:58:49] <gordonf> I think others have introduced some related debates re: rfc2822 identities
[14:58:53] <mrose> ted - let me fix that. just a minute
[14:59:32] <mrose> dfone.
[15:00:25] <yakovsh> we got MAIL FROM, HELO, IP address (MTA MARK) and the various RFC2822 headers (From, Sender, etc.)
[15:01:06] <yakovsh> addressing the RFC2821 identities combats false bounce addresses and mail bombing via that
[15:01:14] <yakovsh> but does not help with phishing
[15:01:29] <yakovsh> RFC2822 identities combat phishing but not false bounce addresses
[15:02:00] <mrose> what about whether the remote peer is authorized to be acting as an MTA (in general) or for a particular domain?
[15:02:33] <jlcjohn> authorized by who (in the "general" case)?
[15:02:45] <yakovsh> the domain owner
[15:02:56] <jlcjohn> that's not the "general" case.
[15:03:05] <mrose> the example that i typically hear is that someone's pc shouldn't be sending mail, period.
[15:03:25] <jlcjohn> "should" meaning?
[15:04:20] <jlcjohn> seriously, ISPs authorize customers, employers authorize emplyees...
[15:04:29] <resnick> (Sorry, I'm slow) Can I backup to Yakov's list of identities? It seems that comparing MAIL FROM and IP address is a category error.
[15:04:32] <mrose> depending on site configuration and preference, sometimes only certain machines are the ones that are configured to relay mail. if a machine not intended to be doing so starts sending mail, that indicates a problem
[15:04:34] <gordonf> I can think of examples, the home machine running a virus with a built-in MTA, but otherwise I believe a domain's owner would authorize
[15:04:50] <dcrocker> Permission to Send mail: there is a difference between asserting that a host does have permission, versus explicitly saying they do not, versus making no statement at all. We need to be very careful about assumptions. If nothing is said, nothing is known. Default no works only for some environments, but definitely not others.
[15:04:56] <mrose> i think the spectrum (bottom to top) is: remote IP address, HELO/EHLO, MAIL FROM:, 2822 headers
[15:05:01] <gordonf> Dave: agreed
[15:06:09] <yakovsh> four identities
[15:06:13] <resnick> mrose: No. IP address is a reverse piece of data. In HELO/EHLO/MAIL FROM, I'm asking whether this IP address goes with the domain.
[15:06:28] <dcrocker> perhaps we can do some clumping. for example, ip addr and HELO probably have the same utility
[15:06:42] <resnick> In the IP address, I'm asking whether the domain goes with the IP address.
[15:06:50] <gordonf> Dave: Most of the time that's right, but not for MUAs and for misconfigured MTAs
[15:07:02] --- yakovsh has left: Disconnected
[15:07:15] --- yakovsh has joined
[15:07:30] <jlcjohn> Dave: what means "same utility"?
[15:07:34] <dcrocker> gordon - pls explain
[15:07:43] <gordonf> MUAs, bad MTAs, or noth?
[15:07:46] <gordonf> s/noth/both
[15:08:19] <dcrocker> jlc - by utility i mean that the useful in getting something validated is probably the same. in general, we need to be clear about the benefit of validating any particular identity. what is the validation good for?
[15:08:21] --- tonyhansen has joined
[15:08:43] <yakovsh> the MTA MARK proposal does not tie in IPs to domains at all, rather it marks a specific IP as a MTA or a non-MTA; therefore the only identity present there is the IP address
[15:09:02] <gordonf> Most of the time a MUA has no clue what domain it belongs to so it HELOs using the only thing it knows: the machine's hostname.
[15:09:15] <dcrocker> gordon - pls explain more completely; i have no idea what your "but not for" text actually means, as a counter to my comment on ipaddr/helo
[15:09:30] <resnick> yakov: But in all of the other schemes, you're checking the IP address too.
[15:09:31] <gordonf> Hm lemme try again
[15:09:33] <dcrocker> gordon - i typed to slow
[15:09:46] <dcrocker> now i understand
[15:10:07] <gordonf> Re: MUAs, just using my own server's logs as an example, most of the HELO strings are hostnames only.
[15:10:26] <dcrocker> In effect the MUA example raises the question of using an MUA as an SMTP relay. After all, we are not trying to solve initial submission, are we?
[15:10:55] <dcrocker> Second of all, a misconfigured or limited bit of software is never going to do what is needed, pretty much by definition.
[15:10:59] <gordonf> The SMTP server doesn't know the difference between a MUA and another MTA (relay).
[15:11:11] <gordonf> Agreed, misconfigs are easy to solve
[15:11:50] <dcrocker> gordon - that's changing. and rapidly. in fact there will be an internet draft submitted on that in the next few days. but perhaps we digress.
[15:11:59] <gordonf> Draft title?
[15:12:28] <mrose> we digress.
[15:13:05] <gordonf> That's OK, if the issue of what goes into HELO is addressed elsewhere, no worries.
[15:13:16] <jlcjohn> do we agree with Pete that IP address is checked for most identities?
[15:13:49] <yakovsh> "checked" against the domain?
[15:14:13] <resnick> Or in the case of MTA Mark, looked up in the reverse map for a yes/no answer.
[15:14:22] <gordonf> "checked" against the domain, rDNS, whois, or what?
[15:14:25] <resnick> Either way, IP address is what you're checking.
[15:14:35] <hardie> At the moment, it seems like you have someone checking a set (what's the set of permitted $FOOs for your domain) by doing a lookup at the domain; the members of the set are identified by IP addresses in the proposals
[15:15:29] <hardie> There could be other ways to name the members of the set; IP address is one of the easiest, though, and important because you know that you're getting packets to that IP
[15:15:49] <gordonf> TCP is funny like that
[15:16:03] <gordonf> (heh)
[15:16:03] * resnick nods to Ted's comments
[15:16:04] <hardie> Except in MTA Mark,it doesn't seem like you check the record at the IP address; you check set membership instead
[15:16:47] <dcrocker> ted - this uses the underlying internet routing service, with the dns, to provide the basis for validation. it requires trusting that ip addresses have not been coopted. (that's ok with me, but we need to be clear about the assumption.)
[15:17:11] <tonyhansen> I think we can assume that
[15:17:16] <resnick> So the basic operation we're going to perform (no matter what the mechanism) is:
[15:17:26] <mrose> tony - sure, let's just be sure we note it.
[15:17:37] <dcrocker> mta mark has the same reliance, although the mapping is in the reverse direction, but the reliance on ip routing is the same.
[15:17:42] <resnick> See if the IP address is in a particular set. Do this by doing a DNS lookup on something.
[15:18:16] <jlcjohn> ... including the IP address in MTA Mark...
[15:18:26] <jlcjohn> ;^)
[15:18:31] <gordonf> John: Yeah, for example.
[15:18:49] <resnick> john: No, you're looking up something in the in-addr.arpa domain.
[15:19:01] <resnick> (just to be anal retentive)
[15:19:27] <jlcjohn> but aren't we still checking whether that IP address is in "some particular set", even if we get more info too?
[15:19:58] <yakovsh> john: you're checking whether the IP owner marked the IP as a non-MTA
[15:20:02] <yakovsh> or MTA
[15:20:07] <yakovsh> kind of like a DUL
[15:20:28] <jlcjohn> exactly: "some particular set".
[15:20:43] <yakovsh> i guess u can look it at that way
[15:21:51] <resnick> I think I'm violently agreeing with lots of people. I guess what I want to be clear is that the IP address is on one side of a formula, and you look that up in the result of a DNS query to see if it matches.
[15:22:02] <hardie> There is a slight difference. In the set check method, you either know that all of the members of the set have the same characteristics or you use a macro language to describe their characteristics; with an IP-based lookup, the person looking doesn't know anything else about which IPs are in the set or what there characteristics are.
[15:22:11] <yakovsh> sounds good to me
[15:22:12] <hardie> That could be important, if you want long-term caching of the data
[15:22:26] <gordonf> That would also have an impact of bandwidth usage, Ted
[15:22:36] <gordonf> (the choice of set check vs ip check I mean)
[15:22:41] <hardie> or if you are concerned about bandwidth usage or disclosure of the other data
[15:22:54] <jlcjohn> Ted: I'm not sure we WANT long-term cacheing, but we must live with it.
[15:23:09] <gordonf> Roaming users who insist on dynamic IP MTAs might want short term caching
[15:23:33] <tonyhansen> time-to-live will come into play for caching
[15:23:38] <hardie> explicit caching, then; with a none ttl
[15:23:44] <hardie> s/none/known/
[15:24:25] <jlcjohn> Marshall: is long-term vs. short-term on-topic?
[15:24:46] <dcrocker> ted - sorry, but i'm not seeing the distinction you are making.
[15:25:28] <mrose> jlcjohn - great question. i'm not prepared to rule it out of order (or not) until i get a sense of the group...
[15:25:48] <gordonf> Is long term vs short term something we can leave for a domain or DNS administration to choose?
[15:26:16] <gordonf> I mean when a domain sets up records they could optioanlly set TTL
[15:26:32] <jlcjohn> they WILL choose, but the choice has non-obvious effects...
[15:27:08] <hardie> david: If I look up the set after getting a connection from one IP, I may have long term data on multiple IDs which I can cache; that might speed up later transactions; I may also be disclosing which other IPs are my MTAs, which our paranoid friends might find problematic. They may only want you to know that *this* one is, not what the set is
[15:27:17] <gordonf> Effects like more hits on their DNS server for s shorter TTL, but supporting dynamic IP, vs fewer hits but not supporting dynamic IP as nicely?
[15:27:46] <gordonf> (making sure I'm on the right wavelength - not intentionally being obstructuve)
[15:28:33] <jlcjohn> Gordon: yes, but also MTA retry times...
[15:28:35] <yakovsh> back to pete's statement - given an IP address of the incoming SMTP connection - i.e. the MTA address - we are doing a lookup in DNS
[15:28:37] <tonyhansen> can we support both styles of set specification, to cater to both those who are more worried about speed/caching and those who are more worried about privacy?
[15:28:43] <gordonf> john: ok
[15:29:15] <gordonf> Tony: At first it looks like we could but at the expense of duplicating information in the DNS.
[15:29:27] <dcrocker> ted - ok, thanks. getting additional ips, for possible, later use, is a strange but interesting optimization.
[15:29:44] <hardie> tony: That adds to the check time, as an MTA would need to check both; also easily get into silly states where one says explicit yes and the other says explicit no.
[15:31:22] <jlcjohn> Tony: in practice, we'd need some DNS trickery...
[15:32:07] <gordonf> What would be an example of "dns trickery?"
[15:32:48] <jlcjohn> I think that IS off-topic...
[15:32:51] <gordonf> ok
[15:33:36] <tonyhansen> Since we haven't defined the mechanism yet, wouldn't the answer depend on how the mechanism worked and how the set specification were defined?
[15:33:52] <jlcjohn> yes
[15:34:04] <dcrocker> who should "authorize" a value given to the receiving MTA (SMTP server)? MailFrom is really authorized by RFC2822 From or Sender entities. (The bulk re-distribution cases for validly redirectly bounces fits under "sender", in my view). HELO's value is authorized by the network containing the client MTA.
[15:34:06] <tonyhansen> I think people have ideas in their minds as to how to do this, but the ideas are different and we're talking past each other a bit here.
[15:34:08] <yakovsh> let me rehash; when looking up the IP, that look up is done either (1) against the rDNS record of the IP; (2) domain in HELO; (3) domain in MAIL FROM; (4) domain in 2822 headers; to check if the IP is part of a set: (1) of MTAs or non-MTAs'; (2) of MTAs authorized to relay for that domain; (3) of MTAs authorized to use the domain in the bounce address; (4) of MTAs authorized to use the domain in RFC2822 headers
[15:34:44] --- molson has joined
[15:34:50] <gordonf> Yakov: Would simplifying (2) to "of MTAs authorized to _send_ for that domain" be appropriate?
[15:35:00] <jlcjohn> Dave: isn't mailfrom RFC 2821?
[15:35:52] <dcrocker> yeah, but what is the actual _use_ of the string: directing bounces. who cares about that? the folks responsible for the original posting.
[15:36:37] <jlcjohn> Is there some reason the sending MTA shouldn't SET bounces-to?
[15:36:39] <resnick> Dave: On a mailing list, 2822 headers have nothing to do with the MAIL FROM.
[15:36:52] <yakovsh> aren
[15:37:15] <resnick> John: Yes, in some cases.
[15:37:54] <resnick> (MDNs come to mind where it should be empty.)
[15:38:48] <dcrocker> pete -- on the average, rfc2822 sender is the same as rfc2821 mailfrom. exceptions are primarily when the bulk mailer needs to handle large amounts of bounces.
[15:39:58] <dcrocker> jlc - the SMTP client in a relaying sequence will not have a basis for knowing anything about where bounces should go, except what it has been told by the upstream entity.
[15:41:01] <dcrocker> Let's see. MDN's are a kind of returned control message. Yes, mailfrom needs to be null. i'm happy to treat null as a special case.
[15:41:29] <jlcjohn> Dave: there's no reason a relaying SMTP sender shouldn't know it's relaying, and set bounces-to to something known good.
[15:41:32] <gordonf> Dave: Nothing wrong with treating MDNs special
[15:42:20] <tonyhansen> half-facetiously: too bad 821 didn't define a special address "noreply@domain" instead of a null address.
[15:42:21] <dcrocker> jlc - sorry, no. random mtas in a sequence of mtas must no go around arbitrarily setting bounces addresses.
[15:42:31] <resnick> Dave: Are we saying that the "secretary as Sender:" use is just DOA and we throw away the original "Sender:" in a mailing list?
[15:42:42] <jlcjohn> Dave: why not?
[15:42:44] <hardie> yeah, the "known good" address could get bounce storms from that pretty fast
[15:43:29] <jlcjohn> Ted: why "bounce storms"?
[15:43:56] <dcrocker> pete - huh? i certainly did not mean to say that. on the average, the "processing authority' that is working on behalf of the author -- ie, the secretary -- is the one that needs to know if delivery failed. A mailing list is a kind of processing authority.
[15:44:24] <mrose> all -- 10 minute warning. time to start branching in. we can go over, but let's not make it a habit...
[15:44:33] <dcrocker> jlc - if delivery fails, who needs to know, to take corrective action? certainly not a stray mta in the middle of a transfer sequence.
[15:45:18] <resnick> Dave: You said that MAIL FROM corresponds to a 2822 field. I said no. You said even in the list case, mail-from==sender. That would mean that a secretary sending mail to a mailing list loses the sender field. Correct?
[15:45:23] <gordonf> Dave's got it right
[15:47:01] <yakovsh> btw, do we even agree on what identities we are talking before deciding which ones to choose?
[15:47:09] <gordonf> heh
[15:47:09] <dcrocker> pete - i said 'on the average'. perhaps a better statement would be something like: the from/sender combination of entities are typcially the authority that sets the mailfrom. ... usually == sender.
[15:47:14] <hardie> jlcjohn: setting to a "known good" address that isn't specific to the message means that address gets all the bounces, which it may not be able to address. A bad hat in the middle could use that to send bounces to a "known good" address, dos'ing that account. Dave's main point is more important though--MTAs should not be arbitrarily resetting these.
[15:48:39] <dcrocker> pete - so, no, the secretary does not lose the sender field. i'm finding myself thinking that the posting authority (sectretary or equivalent agent-of-the-author role) sets the bounces address.
[15:48:43] <jlcjohn> Ted: yes, DOS is possible -- but if the MAIL-From can't be verified, aren't bounces to forged addresses worse?
[15:49:21] <resnick> dave: agreed it's mostly true. My worry is that we not automatically conflate them when we're trying to sort out which identity to use and who gets to set the bounce address.
[15:50:30] <dcrocker> pete - let's try it a different way: who _else_ can/should have authority to set the bounces address? when would the identification of them _not_ be in rfc2822 sender?
[15:50:44] <gordonf> I don't think we should state who sets the bounce address - the sender always has, even if the sender is a machine (mailing list, for example)
[15:51:09] <resnick> dave: when my secretary sends a message to a mailing list from me, bounce address is the list, sender is my secretary, from is me.
[15:51:36] <jlcjohn> Dave: Bounces-To SHOULD be set to something known-good by the originating MTA...
[15:51:53] <hardie> jlcjohn: why is the intermediate MTA setting the Mail from to a new address not forgery or to use a more neutral term "impersonation"?
[15:52:13] <dcrocker> from the mua to the mailing list, bounces and sender are your secretary. mailing lists that set bounces usually set sender, too.
[15:52:17] <jlcjohn> Ted: I'll be happy to discuss that on the list.
[15:53:00] <hardie> okay.
[15:53:05] <hardie> I've got to run folks; thanks
[15:53:08] --- hardie has left
[15:53:21] * dcrocker and the bells sounds
[15:53:34] <mrose> ok. do folks have some things to take to the list?
[15:53:57] <tonyhansen> I liked yakov's last attempt at a summary
[15:54:00] <mrose> i suggest that before firing off an email, everyone takes just a little time to clearly state their comments and edit things a bit...
[15:54:26] <resnick> or take some discussion to private mail and hone the comments before posting to the list.
[15:54:37] <mrose> sure!
[15:55:00] <mrose> ok then. i think this has been a good conversation. let's do it again two weeks from today!
[15:55:34] <jlcjohn> what do folks think about doing this weekly?
[15:55:45] <yakovsh> might be too much on some people
[15:55:48] <gordonf> Might be a little much for me personally
[15:55:54] <stpeter> log: http://www.xmpp.org/ietf-logs/marid@ietf.xmpp.org/2004-03-22.html
[15:56:39] --- molson has left: Disconnected
[15:56:47] <tonyhansen> personally I think it would be a good thing to have them weekly until the major issues get hashed out a bit, then lighten up into every other week
[15:56:57] * dcrocker agrees
[15:57:19] <yakovsh> sounds like a good idea except my schedule might not agree :)
[15:57:57] --- jhildebrand has left
[15:58:07] <gordonf> I'll come back next week
[15:58:31] <jlcjohn> me too -- remember nothing is _decided_ here.
[15:59:11] --- yakovsh has left
[15:59:26] --- yakovsh has joined
[15:59:59] <tonyhansen> c u l8r
[16:00:34] --- gordonf has left
[16:00:55] --- yakovsh has left
[16:01:55] <mrose> l8r
[16:01:56] --- mrose has left
[16:03:55] --- tonyhansen has left
[16:04:21] --- dcrocker has left
[16:04:36] --- resnick has left
[16:06:17] --- stpeter has left
[16:17:02] --- yakovsh has joined
[16:17:15] --- yakovsh has left
[16:24:50] --- millenix has left: Disconnected
[16:25:28] --- dcrocker has joined
[17:11:32] --- anewton has joined
[17:14:25] --- anewton has left
[17:47:20] --- Aredridel has joined
[18:09:04] <Aredridel> Hm. Good log.
[18:09:33] --- Aredridel has left
[22:06:16] --- mrose has joined
[22:06:33] --- mrose has left