[08:20:35] --- anewton has joined
[09:26:53] --- jlcjohn has left: Disconnected
[09:31:08] --- jlcjohn has joined
[11:30:17] --- wayne has joined
[11:40:10] <wayne> hello?
[11:47:12] <anewton> hola
[11:49:38] <wayne> Well, I missed the last two week's sessions. maybe Gaim will be more reliable than Jabber....
[11:55:45] --- wayne has left: Disconnected
[12:01:06] --- wayne has joined
[12:36:32] --- wayne has left: Disconnected
[12:37:34] --- wrs1864 has joined
[12:45:19] --- dcrocker has joined
[12:53:14] --- Maexl has joined
[13:06:51] --- wrs1864 has left: Disconnected
[13:17:42] --- wayne has joined
[13:30:10] --- Maex has joined
[13:30:13] --- Maexl has left
[13:31:42] --- Maex has left: Disconnected
[13:38:33] --- Maex has joined
[14:40:00] --- tonyhansen has joined
[14:44:54] --- gordonf has joined
[14:49:14] --- jgmyers has joined
[14:52:43] --- resnick has joined
[14:52:55] --- mrose has joined
[14:55:13] <mrose> let's wait one minute to see if andrew can join us
[14:56:39] <mrose> ok, who wants to start
[14:56:56] * gordonf hits on hands waiting for firefight
[14:57:00] <gordonf> s/hits/sits
[14:57:21] <mrose> ok, who would like to discuss the identity associated with HELO/EHLO?
[14:57:34] <gordonf> heh, OK, I can say something about HELO/EHLO
[14:57:37] <jgmyers> It's not useful
[14:58:01] <gordonf> Useful for verifying DSNs (mail from:<>) I think, also might be useful for allowing store-and-forward
[14:58:34] <jgmyers> Not useful for verifying DSN's. From: would be more useful for verifying DSNs.
[14:58:39] <gordonf> Basically, accountability shifts to the MTA's operators.
[14:58:48] <resnick> I think it would be useful for accreditation/reputation once a database is there and we should design keeping it in mind.
[14:59:12] <jgmyers> Accreditation/reputation would be better keyed off of ip address
[14:59:16] <gordonf> JG: What about where from: and sender: are different?
[14:59:37] <jgmyers> They aren't for DSNs
[14:59:52] <jgmyers> List expansion never results in an empty Return-Path
[14:59:53] <resnick> IP Address: Control of the forward is often different than control of the reverse.
[14:59:58] <gordonf> Still no guarantee from: is actually where the DSN came from.
[15:00:20] <jgmyers> If DSN went through list expansion, it will no longer have empty return-path
[15:00:21] <resnick> Would be nice for the forward domain to OK it even if the reverse isn't changeable.
[15:00:42] <jgmyers> If it went through alias expansion, well, alias expansion is broken by Return-path checking anyway
[15:00:44] <gordonf> List expansion is a new sender/receiver session though.
[15:01:10] <jgmyers> gordonf: don't understand your last statement
[15:01:33] <gordonf> Is list expansion somewhat like a mailing list? Ie: mail to hostmaster@domain copied to several people?
[15:01:43] <jgmyers> resnick: you talking about sending hosts that can't change reverse lookup dns delegations?
[15:02:01] <resnick> jgmeyers: yup.
[15:02:22] <jgmyers> gordonf: yes, i'm talking about 1123 list expansion. In other words, mailing lists. They are defined to change the return-path
[15:03:16] <mrose> ok, let me step in for a second, now that there's a pause
[15:03:32] <gordonf> OK, the mailing list expander (mailing list software, role account, etc) is going to retransmit the e-mail to each recipient. The original delivery (to the role account/whatever) is done by now.
[15:03:37] <mrose> pete: tell us what you think the pluses and minues are for using the ehlo identity
[15:03:39] --- hardie has joined
[15:04:20] <mrose> hmmm. we lost pete.
[15:04:26] <mrose> okay, john, your turn.
[15:04:28] <resnick> Sorry, I'm back.
[15:04:33] <mrose> oops, never mind.
[15:04:36] <mrose> john - control S
[15:04:49] <mrose> pete - tell us what you think the pluses and minus are for using the ehlo identity, please.
[15:05:25] <resnick> Plus: Get to have a "chain of authorization" back to the domain. Useful for simple whitelist stuff, into the future for accred/rep database.
[15:05:34] <resnick> minus: little short term gain.
[15:05:40] --- wayne is now known as wrs1864
[15:05:55] <resnick> <eot>
[15:05:59] <mrose> ok. john - your take on ehlo?
[15:06:16] <jgmyers> Much simpler and more direct to use ip addresses
[15:06:30] <jgmyers> lots of experience using ip addresses in various dnsbls
[15:06:58] <jgmyers> significant work getting sending mtas to send real info in HELO commands
[15:07:26] <gordonf> JG: I disagree, re: significant work - usually this is a config problem easily solved (providing correct domain to MTA, etc)
[15:07:46] <mrose> gordonf - let's wait until jgmeyers sends <EOT>, then i'll ask you
[15:07:50] <gordonf> sorry
[15:08:13] <jgmyers> it's one more thing that would need to be configured that mtas woudl otherwise be able tofind out from environment
[15:08:33] <jgmyers> effort better sent on securing other identities
[15:08:39] <jgmyers> I'll <eot> for now
[15:08:53] <mrose> ok. gordonf, your turn, send <eot> when done
[15:09:42] <gordonf> thanks - The WIn32 MTAs I worked with almost always use the machine's host and domain name as HELO/EHLO data. Easy to configure and supply.
[15:10:26] <gordonf> MUAs are another matter but MTAs alone, I don't think this is a problem. How hard are we talking about for properly setting up HELO/EHLO? <eot>
[15:10:42] <mrose> ok, anyone else want to talk about the EHLO identity?
[15:10:56] <jgmyers> There's the issue of what the "correct" value is.
[15:11:02] * resnick <rts>
[15:11:04] <gordonf> May I address that?
[15:11:10] <jgmyers> is it the MTA's machine domain name or the domain for which it is sending mail?
[15:11:10] <wrs1864> <rts>
[15:11:35] <mrose> wrs1864 - go
[15:11:42] <jgmyers> Also, there are situations, such as "bridge mode" MTAs where the machine's host name is not always easy to figure out.
[15:11:43] <wrs1864> has the session started?
[15:11:46] <jgmyers> <eot>
[15:12:04] <wrs1864> I thought it wasn't supposed to start until 21:00 UTC, and I'm pretty sure it is 20:00 UTC now.
[15:12:07] <wrs1864> <eot>
[15:12:28] <mrose> heh, heh... the clocks got turned ahead an hour here in california. i thought it was time to start.
[15:12:31] <hardie> wrs1864: DST started in the U.S. over the weekend
[15:12:33] <gordonf> heh
[15:12:51] * resnick dope slaps self
[15:13:07] <mrose> anyone object to keep plowing through... for another 90 minutes?
[15:13:21] <gordonf> I'm OK with going on unless we are expecting others
[15:13:32] <wrs1864> Not me, but I suspect that some people won't show up until later
[15:13:52] <resnick> your call, boss.
[15:13:54] <wrs1864> for example, I mentioned to Meng that the session would start at 21:00
[15:14:09] * wrs1864 tries to catch up on the logs
[15:14:19] <mrose> that's my point. if we keep going now, we have to keep going until and past the top of the next hour. alternatively, we stop now and start again in 40 minutes. either way works for me
[15:14:23] <mrose> ted - do you have an opinion?
[15:14:38] * dcrocker catching up. distracted by contractor working on kitchn
[15:14:44] <tonyhansen> keep going
[15:14:58] <hardie> your call. I'd keep going, since this informal, but no real worries either way
[15:15:10] <mrose> ok, let's keep going...
[15:15:12] <wrs1864> <rts: RE HELO>
[15:15:22] <mrose> wrs1864 - go
[15:15:32] <resnick> <rts>
[15:15:39] <wrs1864> I think the HELO domain is important because it shows up in the REcieved: headers.
[15:16:09] <wrs1864> there are a lot of people who know enough about email to be dangerous and assume that they can find the source of spam by looking at the headers
[15:16:19] <jgmyers> <rts>
[15:16:28] <wrs1864> Unfortunately, spamers have gotten very good at making misleading headers
[15:16:31] <wrs1864> <eot>
[15:16:45] <mrose> ok, anyone else want simplex, or can we go back to free-for-all mode?
[15:16:57] <gordonf> <rts: headers>
[15:16:59] <resnick> I'm fine with free-for-all.
[15:17:45] <mrose> back to free-for-all.
[15:17:55] * gordonf ducks
[15:17:55] <mrose> so, question: do we understand the issues with EHLO?
[15:17:56] <jgmyers> People are much more likely to be fooled by From: than Received:
[15:18:19] <jgmyers> A better solution to people being fooled by Received: is to stop putting the EHLO value in Received:
[15:18:33] <gordonf> JG: MTA's fully qualified name (machine name and domain name together) was what I meant
[15:18:51] <resnick> I agree that headers are not the big issue here.
[15:19:07] <gordonf> re: headers, MTAs will do rDNS and insert correct IPs besides
[15:19:36] <resnick> I still think that being able to let a domain specify that it's OK for an IP address to act as an MTA a la EHLO.
[15:19:39] <jgmyers> HELO seems to be based on the relative costs of broken reverse-ip delegations versus legitimate MTAS sending bad HELO values.
[15:19:51] <wrs1864> can we make an RFC that says "get rid of EHLO string in Received: headers?
[15:19:53] <resnick> ...is good.
[15:19:56] <wrs1864> If so, I'm very cool with that
[15:20:22] <gordonf> wrs: I hope youre kidding
[15:20:41] <dcrocker> the DNS geeks have been quite forceful and consistent in cautioning against relying on using in-addr.arpa. so why are folks calling for relying on it here?
[15:20:53] * gordonf agrees with dave
[15:21:25] <jgmyers> Most DNSBLs use domains other than in-addr.arpa
[15:21:36] <gordonf> Though I think we're not talking about relying on it specifically, but providing a means to verify HELO/EHLO irrespective of wether that verification uses .arpa
[15:22:02] <dcrocker> gordon - i do not understand what you just said
[15:22:15] <jgmyers> So the benefit of verifying HELO is that we get a domain that we can use for some unspecified reputation/authorization service?
[15:22:16] <gordonf> I mean: verify HELO but don't rely in .arpa to do it.
[15:22:59] <dcrocker> jg - anything doing authentication involves a second, separate step of applying the authenticated string to some sort of "acceptability" analysis.
[15:23:35] <gordonf> JG: Repudation perhaps, accountabilty certainly. Authorization, I'm not comfortable defining here.
[15:23:40] --- dmayne has joined
[15:23:45] <gordonf> reputation I mean
[15:24:35] <resnick> jgm: Do you think that EHLO is useless, or just not enough bang for the buck?
[15:24:43] <jgmyers> The HELO proposal so far is too underspecified for me to be able to implement anything useful.
[15:24:56] --- Maexl has joined
[15:25:10] <mrose> i didn't know there was a particular "proposal" being considered... i thought we were talking about identities
[15:25:15] <jgmyers> Not enough bang for the buck. There's not much bang there to be had.
[15:25:26] <dcrocker> i'm guessing that what you consider missing is the acceptability stuff that would build on the autnentication. is there more that is missing?
[15:25:38] --- mengwong has joined
[15:26:18] <jgmyers> So we can verify the identity. I don't see what we have gained by having that identity be verified.
[15:26:44] <gordonf> JG: I can at least see this gained: Holding the MTA's administration accountable. Nothing much beyond that.
[15:26:54] <resnick> gf: +1
[15:26:55] <jgmyers> You can hold them accountable by ip address
[15:27:16] --- Maexl has left
[15:27:21] <gordonf> Not by IP address _alone_ though
[15:27:23] <resnick> You can hold the *domain* owner responsible, which you can't do by IP address.
[15:27:45] <dcrocker> depending upon the accountability chain that is authenticated, i'd expect to be able to hold the hosting network's admin accountable, not just the mta's "local" admin.
[15:27:52] <jgmyers> If you can verify any of the other identies, say, return-path, you can also hold the domain owner responsible.
[15:28:00] <dcrocker> big if
[15:28:22] --- Maexl has joined
[15:28:22] --- robert_sanders_earthlink has joined
[15:28:34] <dcrocker> and, by the way, i believe all those other identities are tied to the origination. only Helo is tied to the peer MTA and network.
[15:29:34] <resnick> regarding "if": If you get no answer on any other identity, EHLO is a nice thing to check.
[15:29:50] <mrose> ok, who wants to take an action to summarize the ehlo pluses/minuses in 23 minutes, when the "official" start time rolls around?
[15:30:10] <gordonf> resnick: As a fallback or worst case. And there are better cases.
[15:30:32] <Maexl> /who
[15:30:35] <jgmyers> I'm getting the sense that people want to check HELO because it can be checked, not because checking it is worth the cost.
[15:30:37] <dcrocker> Let me suggest that we consider identities in terms of two worlds of validation and acceptability.
[15:30:55] --- Maexl has left
[15:30:56] <resnick> jgm: Cost yet to be established.
[15:31:01] <dcrocker> One world is the email object. We validate stuff about the object itself, to decide that this one message is not spam.
[15:31:03] <mengwong> i'd like to mention a change that has gone into the SPF spec since draft version 00 --- now SPF checking can be done in two parts. first, test the HELO FQDN, if it is an FQDN; and if it fails SPF, reject. otherwise, proceed to the return-path. this way, SPF tests both the HELO and the return-path, in a defined order, with maximum benefit and minimal harm to existing practice.
[15:31:18] <gordonf> JG: I want to check HELO only if nothing else can be checked. And I think I have an idea of costs (network-wise) in some stats gathered some time ago.
[15:31:25] <mengwong> if the HELO is not an FQDN, do not apply SPF tests.
[15:31:40] <mengwong> live testing shows that this actually helps block a lot of abuse right off the bat.
[15:32:01] <resnick> jgm: Depending on the mechanism, we might get EHLO checking for close to free.
[15:32:31] <wrs1864> I think checking the HELO domain is worth the cost and it prevents spammers from just sending everything with a MAIL FROM:<> (This assumes that we are going to check the latter.)
[15:32:35] <dcrocker> The other world is the transfer service. We evaluate participants in the service, in effect to decide whether we can 'trust' the aggregate traffic coming through it.
[15:32:35] <gordonf> resnick: I can see a scalability argument coming on where "close to free" is mentioned. "close to free" still isn't free.
[15:32:51] <jgmyers> mengwong: Spammers are able to change their behavior to fit the ecosystem. Checks that few people do can be effective short term, but become useless once the checks become widespread.
[15:33:20] <resnick> gf: no disagreement.
[15:33:35] <gordonf> JG, MWW: I think this is digressing for the moment
[15:34:06] <jgmyers> If spammers send everything with MAIL FROM:<>, we have gained something. We have reduced the collateral damage of boucne messages.
[15:34:18] --- Maexl has joined
[15:34:42] <gordonf> JG: +1 (I think this is the equivelant of "good point")
[15:34:54] <mrose> all - brb, andrew will facilitate for a few minuts
[15:35:00] <dcrocker> jg -- we have permanently lost return notifications.
[15:35:33] <jgmyers> dcrocker: how? Legitimate mail will have non-empty return-path, so will get return notifications
[15:35:34] <wrs1864> dc: we *have* now, or would if spammers start to use <> a lot?
[15:35:36] --- Maexl has left
[15:35:38] <resnick> dc: not necessarily, depending on what we put in place.
[15:35:55] <dcrocker> it is difficult to believe that an approach to solving spam problems by systematically and permanently disabling basic email service is a very good long-term approach.
[15:35:55] --- Maex has left: Lost connection
[15:36:25] <dcrocker> we have a _current_ disabling of the service, by spammers. solving that by disabling it permanently is an entirely different matter.
[15:36:32] <robert_sanders_earthlink> why would a spammer use MAIL FROM:<> if he can register a domain and authorize an MTA with it for $15?
[15:36:33] <gordonf> Dave: This is going back to arguments at leastI'm very familiar with. I know it's never a good idea to break the system for the good of the system.
[15:37:13] <resnick> rs: Because if his domain gets blocked in EHLO checks, it'll get harder to do that.
[15:37:21] <gordonf> May I suggest we continue with benefits/costs of verifying RFC2821 MAIL FROM?
[15:37:25] --- Maex has joined
[15:37:47] <jgmyers> My point was that if we somehow manage to get spammers to use <>, we have gained, not lost. There is a separate issue of if and how we can get spammers to use <> and what the costs are.
[15:38:41] <wrs1864> jg: I disagree. If spammers start to use <>, people will start automatically blocking all DSNs. (More so than they already are.)
[15:38:44] <resnick> rs: Sorry, missed your point there. Got it now.
[15:39:23] <wrs1864> jg: there may be an upside that DSNs won't go to the wrong people, but I think it would still be a net loss
[15:39:41] <gordonf> JG, WRS: If spammers get forced into using <>, then that's when we fall back to HELO/EHLO. If not to stop them, to hold the MTA admins accountable.
[15:39:49] <anewton> Let's go back to moderation and Gordon's suggestion. Who wants to go over the list of +/- with MAIL FROM?
[15:39:56] <mengwong> i agree with gordon that we can then fall back to HELO.
[15:40:08] <jgmyers> There are other things that can be checked to distinguish spam from DSN in the case of <>
[15:40:20] <resnick> <rts - MAIL FROM>
[15:40:36] <jgmyers> One of my points was in that case we would be better off checking From: than HELO
[15:40:37] <wrs1864> gf: that was my point for one reason why HELO checking is useful.
[15:40:52] <anewton> Gordon, do you want to go first?
[15:40:57] <Maex> why don't we simply require a matching quadruple: HELO <-> fwdDNS <-> revDNS <-> connecting IP
[15:41:00] <gordonf> OK thanks...
[15:41:46] <gordonf> ...MAIL FROM is at a minimum where to send a delivery statis notification to. I believe that a sender wants to know if their mail bounces, wheras an abusive mailer does not...
[15:42:04] <jgmyers> <rts>
[15:42:10] <gordonf> ...so verifying this identity is useful if only to know that there's a valid address to send bounces to.
[15:42:39] <gordonf> And at best, to hold the domain, if not the original sender, accountable. <eot>
[15:42:56] <anewton> resnick - <eot> when done
[15:42:57] * wrs1864 agrees with GF
[15:43:20] <resnick> Is there anyone who *doesn't* think we should at least be dealing with MAIL FROM?
[15:43:39] <mengwong> am i allowed to speak on behalf of microsoft?
[15:43:47] <gordonf> <rts: mail from vs phishing>
[15:43:55] <resnick> I don't think there's a whole lot of debate about pluses. Are any negs really that important?
[15:43:57] <resnick> <eot>
[15:44:04] <dcrocker> res - me. mailfrom is a derived value and it comes from origination. dealing with it ties transfer channel to object origin.
[15:44:14] <mengwong> bob atkinson explicitly excluded return-path from the caller-id document because he found a lot of problems went away if they just focused on 2822.
[15:44:30] <mengwong> same arguments as what dave's making, probably.
[15:44:47] * resnick thinks we were supposed to <rts> before commenting. We're in moderation mode.
[15:45:19] * anewton thanks pete
[15:45:42] <anewton> jg: ready? <eot> when done
[15:46:09] <jgmyers> Minor point: spammers may well want bounces. They do like feedback.
[15:46:19] * dcrocker wishing the moderation protocol were described.
[15:46:55] <resnick> (Point of order -- Ad hoc moderation protocol:
[15:47:10] <resnick> <rts> to request the floor. Chair gives you the floor.
[15:47:17] <resnick> <eot> to end your comment.)
[15:47:19] <anewton> resnick: go
[15:47:25] * dcrocker <acks>s
[15:47:29] <jgmyers> I'm not sure what derived means or how it's relevant here. In list expansion, it is explicitly configured.
[15:47:52] <dcrocker> <rts>
[15:47:55] <wrs1864> (optimisation: type your spew into the text box so you can immediatley hit send when you get the go)
[15:48:01] <jgmyers> Dealing with it does limit the architecture of mail transefer somewhat, but within reason. <eot>
[15:48:12] <anewton> dcrocker: <eot> when done
[15:48:37] <dcrocker> 1. "Derived" means that the value in MTA.mailfrom actually is set by another identity (Msg.Sender)
[15:48:45] <dcrocker> that can be checked separately.
[15:49:00] <wrs1864> <rts: mail from origin>
[15:49:09] <dcrocker> 2. The Mailfrom also is very indirect, by virtue of it being relayed as a channel construct
[15:49:18] <dcrocker> when it really is an origin-object value.
[15:49:35] --- robert_sanders_earthlink has left
[15:49:37] <resnick> <rt>
[15:49:42] <dcrocker> 3. The architectural limitations imposed by tieing the channel mechanism to the
[15:49:45] <resnick> <rts>, that is.
[15:50:08] <dcrocker> origin object require breaking valid store-and-forward scenarios, either completely or
[15:50:22] <dcrocker> by virtue of making them administratively too cum bersome to manage. <eot>
[15:50:37] <anewton> gordon: <eot> when done
[15:50:47] <gordonf> thanks. Verifying MAIL FROM alone doesn't work with phishers and others who deliberately try to misdirect complaints (from: line). But it does at minimum hold the sender accountable.
[15:52:20] <jgmyers> <rts: architectural limitations>
[15:52:20] <gordonf> DC: A lot of systems broken by verifying this do have workarounds that are in use today. Even store-and-forward could possibly fall back to HELO, if necessary. Of course we're trying to limit the architecture here...
[15:53:01] <Maex> <rts: problem description>
[15:53:05] <gordonf> ...to linit the actions of the abusive users. Unfortunately I'm not sure how to avoid it. <eot>
[15:53:17] <anewton> wrs: <eot> when done
[15:53:19] <wrs1864> mailing lists and such also set the MAIL FROM, as do MTAs when sending DSNs. I don't consider it that closely tied to the msg sender. I don't agree that it breaks the store-and-forward nature of email. only certain (untrusted) hops are restricted. <eot>
[15:53:52] * anewton on deck: resnick, jg, maex
[15:54:33] <resnick> pass
[15:54:37] <jgmyers> Verifying return-path limits architecture to sequence-of-outgoing followed by sequence-of-incoming. It breaks alias expansion and third party message submission. <eot>
[15:54:38] <resnick> <eot>
[15:55:14] <gordonf> <rts: alias expansion>
[15:55:23] <mrose> i'm back
[15:55:30] <wrs1864> <rts: msg sub>
[15:55:31] <mrose> gordonf - go
[15:55:33] <dcrocker> <rts> breakage and bypassing
[15:55:55] <mrose> besides wrs and dcrocker, anyone in the queue?
[15:56:12] * anewton maex
[15:56:16] <Maex> one of the basic questions is "what do we want to solve". checking MAIL FROM e.g. against a SPF system solves spoofing/joe jobs, but not those 1 USD throw away domains. They can use a SPF like system and short TTLs <eot>
[15:56:17] <gordonf> tx - internal alias expansion wouldn't touch SMTP, external alias expansion most mailing lists rewrite the sender already. Third-party? The third-party becomes the MAIL FROM sender and they become the accountable ones. <eot>
[15:56:37] <mrose> wrs - go
[15:56:39] <wrs1864> I don't see how return-path checking limits third party message submissions. Could you please explain/elaborate? <eot>
[15:56:51] <mrose> dcrocker - go
[15:57:27] <dcrocker> jg - pls explain the two "sequence" terms you used. i'll guess that you meant you are referring to discrete transmission sequences, which of course is all that smtp does
[15:57:30] <jgmyers> <rts - third party message submission>
[15:57:42] <dcrocker> In any event, DSN's are new messages from new senders.
[15:58:21] <dcrocker> Now the problem with breakage of intermediaries, including mailing lists is not that they set mailfrom but that mailfrom is tied to from or sender. (the difference is non-trivial.)
[15:58:52] <dcrocker> for example, if we are now going to require that all bounce addresses, set by mailing lists, be registered to the sender address, then
[15:59:08] <dcrocker> we have lost the original purpose of sender. the fact that some mailing lists set sender does not mean
[15:59:29] <dcrocker> that it is reasonable to require that they all do. in other words, there are configurations of
[15:59:47] <dcrocker> group communication being prohibited, without any apparent discussion or concern for that impact.
[15:59:49] <dcrocker> <eot>
[15:59:51] <gordonf> <rts: purpose of "sender">
[15:59:55] <mrose> maex - go
[16:00:21] <Maex> see above :((( <eot>
[16:00:38] <mrose> sorry, jgmeyers- go
[16:01:09] <wrs1864> <rts: maling lists and mail from>
[16:01:23] <jgmyers> By third party message submission, I mean user a@example.com submits through a third party, say mobile phone network example.net, using their example.com identity in the return-path. By sequence terms, I mean a bunch of mta hops that are considered "internal", followed by one hop over the public internet, followed by a bunch of mta hops that are considered "internal". List expansion may then repeat the sequence
[16:02:09] <jgmyers> List expansion by 1123 definition changes the return-path. If it doesn't change the return-path, then it is alias expansion, which is indeed broken by checking return-path <eot>
[16:02:17] --- Maex has left: Disconnected
[16:02:31] --- Maex has joined
[16:02:42] <mrose> wrs - go
[16:02:45] <wrs1864> dc: rfc2821 (section 3.10) says that mailing lists must change the mail from <eot>
[16:02:53] <hardie> <rts--what to solve>
[16:03:14] <mrose> ted - go
[16:03:54] <hardie> Maex pointed out above that using Mail From doesn't solve the 1 dollar throw-away domain case; I agree--they could buy domains, configure records, toss them.
[16:04:04] <hardie> But does it solve enough of a problem to be worthwhile
[16:04:15] <jgmyers> <rts: throw-away domains>
[16:04:21] <hardie> this group can't solve the whole spam problem (in my opinion, happy to be proved wrong)
[16:04:40] <hardie> but it needs to be clear about the trade-offs between the work required to bite off a chunk
[16:04:51] <hardie> and the value of that chunk to the continued health of the mail system
[16:04:53] <hardie> <eot>
[16:05:21] <mrose> jgmyers - go
[16:05:22] <jgmyers> If spammers use throw-away domains, we have gained something. We have reduced the collateral damage caused by bounces to forged return-paths.<eot>
[16:05:39] <wrs1864> <rts: throw away domains>
[16:05:54] <mrose> ok, do we need to keep doing the speaking protocol, or can we go back to free for all mode? here's an idea. let's focus on throw away domains for a few minutes...
[16:06:05] <mrose> no talking stick required, let's just stay on that one subtopic
[16:06:15] * dcrocker has changed the subject to: throw away domains.
[16:06:26] <wrs1864> domains also have a lot more publicly available tracking information. For example, their name servers can not be as quickly changed as many ohter identitieds<eot>
[16:06:31] <gordonf> Hold the domain registry accountable then.
[16:06:56] <hardie> For having valid contact data, maybe, but they are otherwise not accountable parties for the behavior.
[16:07:13] <anewton> How are throw-away domains not a problem for the other identities?
[16:07:14] <hardie> And only maybe, as there are cases where legal restrictions allow anonymous or role contact
[16:07:18] <gordonf> That's when I'd start impersonating their DNS servers, but that's just me. :-)
[16:07:24] <mengwong> i think throwaway domains are an acceptable next-move, because we have a next-next move planned for that: partly, http://spf.pobox.com/faq.html#churn and partly we can move toward accreditation.
[16:08:11] <wrs1864> an: how would throw-away domains be a problem for other identities?
[16:08:13] <mengwong> also, there's the .tm and .mail kind of response to the throwaway problem.
[16:08:26] <Maex> even with a quelifetime of 24 hours I have sometimes some 10000 bounces in queue from throwaway domains that have MX and A records for the MX but don't accept SMTP connections. So tosing themn to throw away domains does not solve but shift the problem.
[16:08:27] <dcrocker> (if this is OT, let me know) Meng's comment highlights a community problem, namely the idea that any of these mechanisms are useful without an accreditation phase.
[16:08:29] <hardie> turkmenistan?
[16:08:34] <gordonf> Would there not also be ways to tell a throw-away domain from another domain? Like some domain granting the entire IPv4 space sending privilege?
[16:09:31] <wrs1864> gf: not with DMP or SPF. you would have to check a complete rDNS tree
[16:09:48] <dcrocker> forcing a moving towards authenticated domain names -- throwaway or otherwise -- eliminates joe-jobbing. Permanently.
[16:09:49] <gordonf> WRS: Look up domain + 192.168.x.x or 0.0.0.0
[16:09:56] <mengwong> there'll be lots of ways to do it, but ultimately we can move these kinds of decisions to the space of accreditation / reputation.
[16:10:01] <hardie> I think greylisting throw-away domains might be a short term benefit as well, but that is focused on a second phase (actions to take to gain accreditation)
[16:10:23] <hardie> where accreditation may not be by a third party, but by behaving as requested by receiving domain.
[16:10:33] <dcrocker> my guess is that there is a more useful path towards building servces to do whitelisting than to do blacklist.
[16:10:35] <gordonf> hardie: +1
[16:10:43] <hardie> (greylisting amounts to: hold state for N hours and I'll deliver for you)
[16:10:49] <gordonf> <mantra> The recipient decides </mantra>
[16:10:59] <dcrocker> whitelisting can be relatively stable -- if we can eliminate joe-jobbing -- while blacklisting will remain an arms race.
[16:11:09] <jlcjohn> dcrocker: +1
[16:11:37] <mengwong> i don't want to digress too far, but spammers can handle greylisting even more easily than regular senders, so greylisting won't be a permanent solution either.
[16:11:40] <Maex> accrediation systems will not work, IMHO, because they try to accrediate for things they cannot check.
[16:12:17] <gordonf> My worry for accreditation systems is trusting a third party to say "yes." I'd sooner trust a third party to say "no."
[16:12:22] <dcrocker> maex -- every system that does BL or WL does accreditation, in some fashion. (I am now preferring to call it "acceptability" assessment, but the terms are all similar.
[16:12:27] <hardie> mengwong: Hmm. The NANOG folk seem to have come to the opposite conclusion, since holding state is relatively expensive for spammers. Offline, can you explain to me your conclusion?
[16:12:40] <gordonf> I'd rather hear the first party (sender) say "yes" even if it is a spammer from one of his own hosts. He's accountable.
[16:12:44] <mengwong> you don't trust a third party to say yes. receivers trust reputation providers. reputation providers evaluate accreditation providers.
[16:13:04] <gordonf> So you have a fourth party to say "yes" instead of a third? Hm.
[16:13:37] <hardie> But the key question is: is this action useful in its own right, or only useful as a precursor to some later state? If the latter, will there not be very slow deployment?
[16:13:41] <wrs1864> does anyone see throw away domains as a problem? (minor or major?)
[16:13:41] <dcrocker> we seem to be wandering off of throw-away domains. i think the key point about this is that they are another aspect of spammers being flexible; more flexible than the rest of us. To me this means that focusing on throwaways means we are going down an unproductive path.
[16:14:27] * dcrocker seeing a meta point: solving symptoms vs. solving core system issues
[16:14:34] <gordonf> So when do we start holding domain registries accountable for the $1/domain issue? Sounds like a social problem.
[16:14:57] <jgmyers> Throwaway domains are one attack in the threat model. Others are the <> return path, subverting legitimate domains, and subverting DNS.
[16:15:12] <wrs1864> DNS or DSN?
[16:15:17] <jgmyers> DNS.
[16:15:47] <mrose> are we ready to move on to 2822 identities?
[16:15:50] <Maex> dcrocker: accrediation: DNSBL yes, but they are based on facts. If I run double opt-in mailinglists and I swear I will only use DOI, and I put 5% non-DOI on the list, how will any neutral party find out and how?
[16:16:06] <dcrocker> jg -- good point. so let's talk about the basic threats rather than the specific symptom relief mechanisms. this might help us understand how protecting different identities makes sense.
[16:16:08] * resnick nods at mrose
[16:16:14] * anewton nods yes
[16:16:27] --- mengwong has left: Disconnected
[16:16:50] <wrs1864> if the goal is to eliminate spam, then throw-away domains *may* mean designated sender systems won't help. However, if the goal is to stop bogus bounces or abuse of a domain owner's name, then they are irrelevant
[16:17:14] * anewton has set the topic to: 2822 identities (moderated)
[16:17:21] <wrs1864> <rts>
[16:17:23] <resnick> <rt>
[16:17:26] <resnick> <rts>
[16:17:27] <dcrocker> maex - 'based on facts' just argues the goodness of an accreditation mechanism. my point was that all of these things involve some sort of acceptability assessment. i wasn't trying to get into one being better than another.
[16:17:27] <anewton> wrs: go
[16:17:39] <wrs1864> I think RFC2822 identities are very important and we need to consider them.
[16:17:44] <gordonf> <rts>
[16:17:48] --- mengwong has joined
[16:17:49] <jgmyers> wrs: agree, though misleading but different domain names are still a problem for phish targets.
[16:17:54] --- mengwong has left: Disconnected
[16:18:11] <wrs1864> however, I think there are lot more issues with them and the problem of RFC2821 identities is much better understood.<eot>
[16:18:33] <jgmyers> <rts>
[16:18:57] <anewton> resnick: go
[16:19:07] <resnick> If we come up with a mechanism that simply answers "go" or "no go" for a domain name (even if we specify for MAIL FROM or HELO), people will use it for 2822.
[16:19:19] <resnick> They think it's important to check those things and they will do so.
[16:19:54] --- mengwong has joined
[16:19:57] <resnick> I think it's important to check those things, and though I agree that signed stuff is a better solution, using the DNS is a quick and dirty one that folks can use.
[16:20:28] <mengwong> i think i've found a way to give people 2822 checking based on 2821 matching.
[16:20:31] <Maex> <rts checking point>
[16:20:36] <resnick> I think it's worth keeping 2822 headers on the list and design the mechanism to be useful for them too. <eot>
[16:20:47] <anewton> gordon: go
[16:20:57] <gordonf> Verifying from: is more visible to the user (the mailbox user) and will halt joe-jobs AND phishing Whitelisting like IM systems use becomes viable.
[16:21:04] <gordonf> Verifying from: is expensive in that we have to receive the entire message first. May also be legal and social issues from messing with content. It also breaks third-party sending if used alone.
[16:21:18] <gordonf> <eot> (I like having a notepad)
[16:21:33] <anewton> jg: go
[16:21:44] <jgmyers> DNS-based checking of 2822 ids breaks list expansion, which is common enough to prevent general deployment. A minority of domains may well be willing to trade list expansion for 2822 id checking.<eot>
[16:21:52] <resnick> <rts>
[16:22:16] <anewton> maex: go
[16:22:25] <Maex> the problem with checking 2822 is where to check? Are we going to have MTAs check 2822 header fields? How do we handle multiple 2822 from addresses (allowed in 2822). if 2822 checks are after the MTA received the message we have problems with the bounces
[16:22:47] <Maex> it is better to reject at SMTP level (blieve me, we're using qmail :)
[16:22:52] <Maex> <eot>
[16:22:59] <anewton> resnick: go
[16:23:01] <resnick> jg: I agree that a minority can use 2822 checking. But for those who want to use it (Citibank and PayPal, e.g.), I think it's a win.
[16:23:14] <gordonf> <rts>
[16:23:47] <resnick> gf: I think some MTAs make it quite easy to check as you go, so I don't think that's as big a problem.
[16:23:54] <dcrocker> <rts> generic dns-based checking
[16:24:34] <resnick> Maex: I think checking 2822 is going to be tricky and need explicit instructions. But that's all the more reason to take it on and not leave people to do it without our help. <eot>
[16:24:47] <anewton> gordon: go
[16:24:56] <gordonf> re: Phishing: A MTA could insert "may be forged" to help, while not breaking lists etc, resnick: I'd leave it to the admins of the receiving MTA to check From as they go, but if they want to, ok by me. They decide.
[16:25:00] <gordonf> <eot>
[16:25:13] <anewton> dcrocker: go
[16:25:37] <dcrocker> (skip one; i've been cogitating the comments.) re-queue me. <eot>
[16:25:43] <wrs1864> <rts: priorities: 821 vs 822>
[16:25:48] <anewton> wrs: go
[16:26:03] <wrs1864> I think that RFC2821 should be our first priority, RFC2822 second.
[16:26:09] <wrs1864> <eot>
[16:26:20] <anewton> dave?
[16:26:28] <dcrocker> perhaps the best thing about discussing 2822-based identities is that it makes that much clearer the difference between authentication and acceptability.
[16:27:04] <dcrocker> Any mechanism that does some sort of validation must separately do an acceptability assessment. I think we are tending to
[16:27:13] <dcrocker> conflate these steps, for some mechanisms.
[16:27:27] <jgmyers> <rts:priorities>
[16:27:30] <Maex> <rts signing>
[16:27:38] <dcrocker> So there is a difference between saying something like "the name is being used by its owner", versus
[16:27:55] <dcrocker> the owner of the name is a good person. If we can abstract this enough,
[16:28:11] <dcrocker> so that the DNS is the registry for the (domain) names and we can do an authentication that the name
[16:28:40] <dcrocker> is being used by its owner, then perhaps yes it can apply to 2821 domains as wells as 2822 ones. <eot>
[16:28:47] <anewton> jg: go
[16:28:51] <jgmyers> 2822 checking is of greater benefit to a smaller set of domains, compared to 2821 checking. 2821 probably has the greater overall benefit<eot>
[16:29:03] <anewton> maex: go
[16:29:04] <wrs1864> jg +1
[16:29:11] <Maex> 2822 checks are IMHO someone near PGP checks
[16:29:26] <Maex> <eot>
[16:29:56] <anewton> ok. there seem to be differing views on the difficulty of checking mail content.
[16:30:06] <dcrocker> <rts> dns-based checking through s/f
[16:30:13] <anewton> do we want to discuss this in detail?
[16:30:40] <jlcjohn> I'd prefer to discuss later.
[16:31:02] <dcrocker> andrews - the track record of pgp and s/mime mean we do need to discuss it, but i agree we don't need to do it right nhow.
[16:31:11] <jgmyers> <rts checking mail content>
[16:31:14] <wrs1864> (I think it is hard, but would be interested in hearing out it would be easy.)
[16:31:16] <anewton> ok.
[16:31:18] <anewton> dave: go
[16:31:44] <dcrocker> dns is an interactive service. it is checked some number of hops after the data has been created.
[16:32:02] <dcrocker> this means that it is inherently subject to all sorts of man in the middle hassles. it therefore means
[16:32:15] <gordonf> <rts: dns flaws>
[16:32:18] <dcrocker> that the current checker needs some way to believe that the original information is valid.
[16:32:18] <hardie> rts: dns
[16:32:27] <hardie> <rts: dns>
[16:32:39] <dcrocker> if the original information is one-hop back, then we are home free. otherwise, we get into complex or very
[16:33:02] <dcrocker> rigid mechanisms for tieing the original data usage to the current data checking. So, for example, this
[16:33:22] <dcrocker> distinguishes mailfrom from helo. Helo is one hop back. mailfrom is an arbitrary number back.
[16:33:45] <dcrocker> <eot>
[16:34:24] <anewton> godon: go (jg: let's hold that thought until after the dns topic)
[16:34:32] * gordonf will defer to ted
[16:34:35] --- mrose has left
[16:34:46] <anewton> ted: go
[16:34:51] * jgmyers has set the topic to: DNS
[16:34:58] <hardie> For DNS threats: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-threats-07.txt is a very useful read. Cache poisoning and related problems can be very real threats. For much spam, though, it is too much work as you have to poison the cache for each domain's recursive resolver
[16:35:02] <Maex> <rts: dcrocker: why do hops make a difference>
[16:35:32] <resnick> <rts DNS>
[16:35:37] <wrs1864> <rts DNS attacks>
[16:35:53] <hardie> This may be worthwhile for a high profile domain and a high value recursive resolver, but it is far outside the scope of the current set of attacks. DNSSEC, though not deployed, is also very much designed to thwart this particular issue
[16:36:09] <hardie> It may be a useful tool for those very high profile domains.
[16:36:13] <hardie> <eot>
[16:36:20] <anewton> resnick; go
[16:36:48] <resnick> Mostly +1 Ted. I think that once we get to the point of DNS attacks, we're far afield of what this group can really address.
[16:37:05] <resnick> And the cost is high enough (in the short term) for us not to worry about it. <eot>
[16:37:16] <anewton> wrs: go
[16:37:17] <wrs1864> I've read that draft a couple of times, and my understanding is that the latest binds are pretty resistant to these attacks. If spammers could screw up DNS by poisoning caches, they would have done it with DNSBLs already. <eot>
[16:37:31] <gordonf> <rts>
[16:37:43] <anewton> gordon: go
[16:37:52] <gordonf> +1 resnick: We're not here to fix DNS. Many DNS problems can be or were fixed in implementations, and eventually DNSSEC will replace it. This might be digressing also. +1 hardie also: as DNS attacks could be too expensive for just sending mail, and also for DNSSEC reference.
[16:37:52] --- mrose has joined
[16:37:55] <gordonf> <eot>
[16:38:07] <mrose> sorry, system crash
[16:38:22] <anewton> anyone else on DNS?
[16:38:40] <anewton> ok. jg: go
[16:38:42] <jgmyers> I think we're already at the point where MTA-level pre-accept content checking is common.<eot>
[16:38:49] <dcrocker> rts - "registration" vs. storage in dns
[16:39:01] <anewton> maex: go
[16:39:16] <Maex> solved <eot>
[16:39:24] <anewton> dave: go
[16:39:55] <dcrocker> we either use the dns as a direct proof mechanism, such as MTA registration, or we use it to store a value
[16:40:28] <dcrocker> that gets used variously and could be obtained from somewhere else. For exmaple, RMX, et al, have the DNS actually register goodness. by contrast, dkeys just uses
[16:40:44] <dcrocker> it to hold some data that can be obtained through other channels, perhaps.
[16:41:12] <resnick> <rts>
[16:41:24] <dcrocker> I know this is not coming out all that coherently, but there is a difference between "registration" schemes, eg, rmx, and hash/key schemes. I think
[16:41:59] <dcrocker> that difference has a big effect on the channel-vs-object model and, therefore on the handling flexibility we get. <eot>:
[16:42:10] <Maex> <rts>
[16:42:13] <anewton> resnick: go
[16:42:39] <resnick> dc: I don't think the distinction you're making is all that important. I can either fake the "goodness" claim in the DNS or I can fake where to look for the other info. Either way, you can mislead someone by breaking the DNS. <eot>
[16:43:03] <anewton> maex: go
[16:43:13] <Maex> DNS could also be abused special gateways as e.g. highly dynamic access to LDAP and user validation (even if this without provisions would alow for adress harvesting)
[16:43:15] <hardie> <rts: channel v. object>
[16:43:51] <Maex> currently we IMHO focus on static infos, so this could be a direction to think about <eot>
[16:44:00] <anewton> ted: go
[16:44:18] <hardie> I think Pete missed Dave's point. If you have a pointer to a public key, you can check that a message or message part signed by the private key is valid
[16:44:41] <hardie> you can change what is validated by the signature on the fly, by changing what is signed
[16:45:16] <hardie> With a registration-in-the-store version, you are more limited, as the zone maintainer must know what to store (as that has to match what is checked)
[16:45:37] <hardie> I think both are useful, as there are times when you want a standard place to look as well as a standard way to check
[16:46:12] <hardie> The other, more flexible method may be just the ticket for items which need to be checked according to a logic specific to a particular situation <eot>
[16:46:58] <Maex> <rts>
[16:47:08] <anewton> maex: go
[16:47:49] <Maex> with signing parts of message data we must be careful, to not attackableby relay attacks
[16:48:15] <Maex> that means that static information for e.g. all messages of a MTA are bad
[16:48:22] <Maex> <eot>
[16:48:47] <gordonf> <rts>
[16:48:49] <Maex> replay attacks that is
[16:48:56] <anewton> gordon: go
[16:49:25] <gordonf> Are we going to be introducing crypto here? Otherwise I think we're digressing. <eot>
[16:50:04] <anewton> let's go unmoderated for the next 5 minutes. That should finish up our time, unless somebody has a major topic they think we have missed.
[16:50:12] <gordonf> 2822 sender?
[16:50:23] <gordonf> .arpa was also mentioned
[16:50:42] <anewton> go on 2822 sender.
[16:50:42] <tonyhansen> <meta comment: time check>
[16:50:55] <jgmyers> I thought we did all 2822 id's at once.
[16:51:07] * wrs1864 points @ jg
[16:51:07] <gordonf> If we did all 2822 headers at one, ok
[16:51:21] <anewton> we did, but I thought there was a specific point on sender.
[16:51:23] <anewton> guess not.
[16:51:38] <gordonf> I just missed the sender stuff eg: is Sender the same as 2821 MAIL FROM?
[16:51:52] <dcrocker> gordon - NO!!!
[16:52:01] <gordonf> Making sure - it's OK dave... :-)
[16:52:27] <wrs1864> Does this group have a rough consensus on which identities to address first?
[16:52:35] <jgmyers> I think .arpa was sort-of covered with EHLO
[16:52:38] <wrs1864> (of course, we need to get the mailing list consensus also)
[16:53:15] <jgmyers> I sense some consensus on MAIL FROM, excepting Dave.
[16:53:26] <Maex> maybe it would be needed to simplify and clarify 2822 fields ... just like the "auto-submitted" draft started with
[16:53:54] <mengwong> i think we should focus first on 2821 and bring in 2822 later.
[16:53:56] <gordonf> MAIL FROM seems to be a definite "yes" - I wanted to do HELO too but didn't get the same feeling.
[16:54:11] <resnick> I argued that we should do "all of them", i.e., design a mechanism that can handle HELO, MAIL FROM, and 2822.
[16:54:15] <jgmyers> HELO is much more mixed.
[16:54:16] <wrs1864> my vote: RFC2821 MAIL FROM/HELO first
[16:54:27] <tonyhansen> resnick: +1
[16:54:42] <mengwong> i think HELO is also worth protecting.
[16:54:57] <dcrocker> "let's do everything" is only slightly worse than "let's do multiple". either way, it says that we do not really know what we are trying to accomplish or why.
[16:55:15] <mengwong> i think that HELO and MAIL FROM are more amenable to protection using LMAP style technologies, and 2822 From and other headers can be grafted on later or should use crypto.
[16:55:21] <dcrocker> to be fair --
[16:55:37] <jlcjohn> dcrocker: I disagree -- we have very good reasons for each.
[16:55:39] <dcrocker> i know that pete really was arguing for a generic mechanism, rather than for pointedly validating everything.
[16:55:45] <resnick> dc: What I'm proposing is "Let's do domains" and leave where we get that domain until later.
[16:55:55] <dcrocker> pete ack.
[16:56:00] <resnick> dc: yup.
[16:56:25] <dcrocker> jlc - oh? I think I'm missing a clear statement of those "good reasons", in a fashion that lets us see incremental, long-term benefit.
[16:56:32] <jgmyers> If we want to be able to do 2822, we also need way to express whether the domain wants a policy applied to 2822.
[16:56:44] <dcrocker> I say long-term because this level of standards work cannot ever do anyhthing that is "interim".
[16:56:54] <wrs1864> pete: I don't feel that RFC2822 checking is well enough understood right now. There is no working code available to study the details.
[16:57:20] <jlcjohn> dcrocker: happy to discuss in detail on list...
[16:57:23] <resnick> jgm: correct. We're going to need a mechanism for the domain to express "here's what I think this IP address associated with this domain name is allowed to do."
[16:57:25] <gordonf> Dave: is doing HELO and MAIL FROM enough to be not-interim?
[16:57:51] <jgmyers> we understand that 2822 checking breaks list and alias expansion and would be wanted by a minority of domains. I'm not sure those domains truly understand the limitations of using it.
[16:57:59] <Maex> and we should avoid a multi step thing, were everyone is more than happy t make the first or even second step, but everyone is afraid to make the final step
[16:58:03] <gordonf> Rather, can those be defined and "set in stone" while still allowing for 2822 checks later, in your opinion?
[16:58:12] <dcrocker> gordon -- they provide entirely different information. as I said, having tackling multiple identities strongly suggests taht we are not clear about either.
[16:58:28] <wrs1864> (moderate?)
[16:58:37] <anewton> Ok. I think we are out of time.
[16:58:52] <dcrocker> jg -- huh? how does message signing break lists and aliases?
[16:58:57] <gordonf> I'll get going anway - thanks for the organization, mrose and anewton
[16:59:02] --- hardie has left
[16:59:06] <gordonf> /quit
[16:59:08] <jgmyers> dns-based 2822 checking, without crypto
[16:59:09] <anewton> It would seem that the rough consensus is 2821 helo/mail from first, with an eye towards 2822.
[16:59:14] <gordonf> (ops - this isn't IRC)
[16:59:15] <mengwong> agreed.
[16:59:16] --- gordonf has left
[16:59:26] <dcrocker> ohh. you mean the sort of mechanism also being proposed for checking mailfrom?
[16:59:42] <wrs1864> dc: yeah, I think so
[16:59:58] <jgmyers> dcrocker: correct
[17:00:22] <anewton> Let's consider this session closed. But everyone should feel free to stick around and chat.
[17:00:32] <resnick> jgm and dc: glad to continue offline, but I've gotta run right now. l8r.
[17:00:43] <resnick> Thanks Andrew and Marshall. Good session.
[17:00:47] <wrs1864> yes, thanks
[17:00:48] <dcrocker> i think this means that pursuing dns-based mailfrom checking means agreeing to breaking mailing lists, alias expansion (and, oh by the way, various kiosk, greeting card, and mobility scenarios.)
[17:00:51] <wrs1864> I think it was productive
[17:01:00] --- resnick has left
[17:01:16] <jgmyers> dcrocker: dns-based mailfrom checking does not mean breaking list expansion.
[17:01:25] <wrs1864> dc: it doesn't break any mailing lists that conform to RFC2821
[17:01:47] <dcrocker> if it means it for 2822 values, why does it not mean it for mailfrom, especially since mailfrom is set by sender?
[17:02:07] <mengwong> it also breaks .forwarding, dave, to complete that list :)
[17:02:27] <dcrocker> .forwarding is actually a kind of alias expansion, architecturally.
[17:02:28] <jgmyers> list expansion changes the mail from to a value that works with validation
[17:02:41] <jgmyers> .forwarding is alias expansion
[17:03:10] <Maex> but both make no difference to the 2822from
[17:03:28] <Maex> they only differ for 2821from
[17:03:54] <jgmyers> maex: correct, both list and alias expansion break with 2822 dns verification
[17:04:06] <jgmyers> only alias expansion breaks with 2821 dns verification
[17:04:44] <jgmyers> third party submission breaks under both 2821 and 2822 dns verification
[17:04:54] <jlcjohn> I'd like to understand better the cases where alias expansion would break
[17:05:04] <dcrocker> forgive my confusion, but all of this sounds as if, for absolutely sure, mailfrom is tied to 822.sender and not 822.from.
[17:05:24] <jlcjohn> I don't believe it's "tied to" either.
[17:05:27] <jgmyers> And it's cross-domain alias expansion that breaks. intra-domain alias expansion still works
[17:05:33] * wrs1864 points @ jlc
[17:05:59] <jgmyers> MAIL FROM is tied to 2822 Return-Path:
[17:05:59] <jlcjohn> Can someone explain the cross-domain breakage?
[17:06:19] <jgmyers> it is not the same as either From: or Sender:
[17:06:43] <mengwong> jlcjohn, see http://spf.pobox.com/slides/apcauce2004/7012.html and click on the rhs of the image to proceed through.
[17:07:08] <mengwong> MTA7 has the role of /etc/aliases
[17:07:50] <Maex> jlc: alias expansion keeps the 2821from intact. so a alias expansion in another domain breaks 2821 verification
[17:07:57] <mengwong> http://spf.pobox.com/slides/apcauce2004/7502.html specifically shows how 2821 checking breaks traditional forwarding.
[17:08:31] <jlcjohn> Why must alias expansion keep 2821-from (as opposed to 2822-from)?
[17:08:55] <Maex> jlc: because of routing bounces back to the original sender
[17:09:07] <jgmyers> jlcjohn: that is the definition of alias expansion, per 1123
[17:09:28] <jlcjohn> How does this avoid being a haven for spammers?
[17:09:42] <jgmyers> One solution would be to define a new type of expansion, that is neither list nor alias expansion but works across domains
[17:10:03] <Maex> jlc: it doesn't and that is exactly the problem and that this method is really widely used
[17:10:47] <jgmyers> jlcjohn: how does what avoid being a haven? how being a haven?
[17:10:54] <Maex> that would be a SRS mechanism ... but this has the problem to avoid replay attacks
[17:11:20] <Maex> and this is what makes SRS complicated
[17:11:45] <mengwong> it's like source routing, only with crytpo signatures. it's yucky. but it works!
[17:11:51] <jlcjohn> jgmyers: If alias expansion trusts 2821-mailfrom, why doesn't that invite abuse by spammers?
[17:12:17] <jgmyers> The forward address of alias expansion is not under the control of the sender.
[17:12:46] <jlcjohn> jgmeyers: It doesn't need to be: the bounce goes out unverified.
[17:13:13] <jgmyers> But spammers can cause bounces to unverified addresses with direct sending. They don't need alias expansion.
[17:14:01] <jlcjohn> jgmyers: wouldn't they use this if we closed the direct path?
[17:14:30] <mengwong> by "use this", what do you mean?
[17:14:43] <jlcjohn> use alias-expansion...
[17:14:46] <jgmyers> If we close the direct path, then it is closed going into alias expansion. But closing the direct path happens to break alias expansion anyway.
[17:14:48] <Maex> that's where HELO and a pseudo sender postasmaster@helohost comes into play
[17:15:11] <jlcjohn> doesn't break unless alias-expander checks it...
[17:15:21] <mengwong> alias expansion is broken anyway. people are filtering mail based on whether mail from @yahoo.com really came from a yahoo server. they don't care about forwarding setups.
[17:15:37] <mengwong> the benefit of blocking all that forged spam way exceeds the cost of blocking some FPs that came through a forwarded site.
[17:15:53] <mengwong> they expect the forwarders to do the rewriting. and lots of forwarders are responding.
[17:16:11] <jgmyers> mengwong: If they are doing that, then they are also breaking third party submission.
[17:16:19] <Maex> mengwong: is that still the case?
[17:16:37] <jgmyers> Effectively, the've implemented nonstandard 2821-checking.
[17:20:10] <Maex> mengwong: on one of our smaller MTAs we had yesterday: 27445 SMTP connections, 5903 messages were rejected due to filter rules, only 196 of them came with a sender @hotmail.com, additionally 4301 were blocked due to our own DNSBL.
[17:21:23] <Maex> those 196 messages make up for about 3%
[17:21:29] --- tonyhansen has left: Disconnected
[17:21:57] <mengwong> interesting numbers.
[17:22:02] <mengwong> but how many of the messages you had had forged 2821?
[17:22:28] <mengwong> 3% hotmail, 3% yahoo, 3% mail.com, etc ... and pretty soon we're talking real percentages :)
[17:22:42] <mengwong> i can give you a list of the top 20 most forged domains if you want to run the numbers on those.
[17:23:31] <mengwong> jgmyers: yes, they have implemented nonstandard 2821 checking, and nothing we can say will convince them to stop.
[17:24:25] <Maex> but will
[17:24:30] <Maex> *grmbl*
[17:25:43] <Maex> agreed :) 190 yahoo.com (and 5 of them spam via web*.mail.yahoo.com)
[17:26:08] <jgmyers> mengwong: Giving them standard 2821 checking might get them to stop. But I don't see the relevance of the argument.
[17:26:54] <mengwong> well, the argument is that forwarders and web-generated email providers are having to do SRS anyway.
[17:27:19] --- dmayne has left
[17:27:19] <Maex> but as I get the feeling they already do, spammers will turn away from the "big" names to joe user domains then, and joe users will have big problems to get SPF working, I fear
[17:27:31] <mengwong> let's try to make it as easy as possible for them.
[17:27:35] <mengwong> email is not cheap.
[17:27:51] <mengwong> email has been perceived to be cheap in the past, but the cost has fallen on antispam.
[17:28:10] <mengwong> we are shifting the cost away from antispam, and it is going to go in other directions.
[17:28:45] <mengwong> and if that may make life harder for the vanity domain owner, well, maybe $8 a year is less than what email really costs.
[17:29:44] <mengwong> if a user pays $8 a year to do vanity domains, but their ISPs pay $80 a year per user to block their spam, the real cost is $88.
[17:30:11] <mengwong> all this is about cost-shifting some of that $88 away from the receiver ISPs toward the sender domains, that's all. and at the end of the day, the total cost will be less than $88, we're hoping.
[17:30:21] <mengwong> maybe it'll be $22 for a vanity domain and $44 for the receiver ISPs.
[17:30:26] <mengwong> strictlly economic analysis.
[17:30:53] <mengwong> but at least we'll be living in a better world.
[17:31:14] <Maex> but the price dumping for internet access is also one of the reasons spammers still exist, IMHO
[17:31:36] <mengwong> hey, i want internet to be free for everyone :)
[17:32:23] <mengwong> hmm. that just made me realize i need to block outgoing port 25 on my home wifi router.
[17:32:44] <Maex> all the ISPs have a hard life currently, so dropping a customers that pays two employees a month but sends a newsletter with not so strict opt in (aka spam) a month is a mostly financial decision
[17:32:47] <mengwong> i want to be able to provide free wifi to my block, but i also don't want my neighbour's spam-infested windows 98 machine to send spam through my connection.
[17:33:07] <mengwong> spam doesn't come from colocated machines anymore. spam comes from virused windows broadband boxes.
[17:35:17] <Maex> a lotof spam, yes, but I own two or three domains in DE that are well-liked (lamer.de) and often mistyped (e.g. magazin.de) and I get tons of emails each day from newsletters that have valid senders and addresses but don't handle bounces nor do double optin
[17:35:28] <Maex> and those also are a pain in the ass
[17:35:42] <mengwong> for those, i recommend callback verification.
[17:35:45] <mengwong> sender verification.
[17:36:05] <mengwong> to me, "valid sender" = "handle bounces"
[17:36:23] <mengwong> if the return-path doesn't accept a RCPT TO ... it's not valid. return 4xx.
[17:37:02] <Maex> the problem is not that I cannot deal with it, but they are configured at a large mailsystem with tousands of boxes and whether the email is valid is decided when the backend server tries to deliver
[17:37:39] <Maex> to a mailbox. So all the messages get in anyway ...
[17:39:11] <Maex> and that makes more costs for bandwidth ... it could be solved (e.g. with LDAP or the like) at the from SMTP servers, but this also has costs associated with
[17:39:29] <Maex> s/from/front/
[17:40:20] <mengwong> mmm.
[17:46:52] <mengwong> anyway, i wrote up some thoughts at http://archives.listbox.com/spf-discuss@v2.listbox.com/200404/0060.html
[17:47:02] <mengwong> there are a couple followups ... by me!
[17:51:20] <Maex> Hmmm ... there are a lot of marketing companies ... they get the addresses from e.g. Sony who take them from their newsletter lists.
[17:52:49] <Maex> They do some marketing research for Sony. I have often noticed that while the 2822from is something within Sony the envelope isn't. And it are not mailinglists in any way
[17:53:12] <mengwong> sure.
[17:53:47] <mengwong> the bulk mailer industry eg digital impact, silverpop, etc all do that.
[17:54:11] <mengwong> and in my classification i suggest they be considered second class mailers by default because 2821 won't match 2822.
[17:54:39] <mengwong> but if they then want to get accreditation with eg. bondedsender.com or ISIPP's iadb, then they can move to first-class.
[17:54:46] <Maex> Large companies often outsource this kind of things and they don't want to deal with bounces or the like, they want the results, but to look "official" they use a 2822from within sony.com
[17:55:04] <mengwong> agreed.
[17:55:23] <Maex> Hmmm ... I don't believe in accrediation systems ...
[17:55:25] <mengwong> and whatever we come up with should allow them to keep doing that.
[17:55:59] <Maex> IMHO the biggest problem they have is to verify their terms ...
[17:56:14] <mengwong> just because something is hard doesn't mean it's impossible.
[17:56:51] <Maex> talk spamhaus and the .mail proposal ... imagine the ietf pays the USD 2000 and gets ietf.org.mail
[17:57:12] <Maex> and they say they will only run double opt-in lists
[17:57:23] <Maex> so thes do get the entry
[17:58:18] <Maex> fine ... and now me and some friends of mine fake 10 emails each and we exchange them so the headers are consistent and the times match and so on
[17:58:45] <Maex> and then we write to the .mail rgistry and demand that the IETF gets their listing revoked
[17:58:56] <mengwong> er, but your mail didn't pass SPF, so it was a forgery.
[17:59:11] <mengwong> you should assume everything in .mail and in .tm publishes SPF, so their names can't be forged in 2821.
[17:59:35] <Maex> and as a proof we show our "trimmed" emails
[18:00:01] <mengwong> i think you'd report that kind of thing to your reputation provider.
[18:00:10] <mengwong> and your reputation provider would also track your reputation as a reporter for honesty.
[18:00:15] <mengwong> that's how things work today with things like spamcop.
[18:00:34] <mengwong> so you have sender / accreditor <-> reputation service / receiver
[18:00:40] <Maex> and that exactly show that it doesn't work
[18:01:10] <Maex> we only run double optin lists for our customers
[18:01:30] <Maex> and still I get spamcop mails claiming users get spammed from double optin lists
[18:02:13] <mengwong> yes, and when we get that from spamcop we write to spamcop and spamcop pulls that user's reporting privileges.
[18:02:17] <mengwong> don't you?
[18:02:41] <anewton> meng: are your model of accreditor <--> reputation service seems very similar to the concepts of RA's and CA's in the PKI world.
[18:02:52] <anewton> s/you are/your/
[18:03:07] <Maex> write to whom? for me spamcop has always been a black hole ... ever got any feedback for years ... sometime I stopped
[18:03:10] <mengwong> mmm, that's not surprising.
[18:03:15] <mengwong> re the RA/CA thing.
[18:03:38] <mengwong> all i can say is, we've written to spamcop with reasonable success, you should try them again if your last experience was a few years ago.
[18:04:06] <Maex> mengwong: it was more likely a few weeks ago :)
[18:04:07] <mengwong> also, accreditation and reputation providers will rise and fall with the market. and for this space i think the market is a pretty good arena to solve the problems.
[18:04:41] <mengwong> if spamcop is not responsive, or if their users are irresponsible, then they are a poor provider of value, and they will fare poorly in the market, and fewer people will use them.
[18:04:47] <mengwong> we are still in the early days.
[18:05:12] <mengwong> we have to wait for a market in accreditation / reputation to establish itself before we can judge it.
[18:05:58] <Maex> but a CA has the advantage of neutral and easily checkable third party information ... e.g. SSL for HTTP checks if the owner of a domain matches the correct address and name of e.g. the company the domain is registered to
[18:06:03] <mengwong> the model of accreditor / reputation service isn't just my model. it came out of the aspen institute conference in december and the language has been adopted by most of ASTA, the deliverability industry, etc.
[18:06:14] <mengwong> so i'm just following the current thinking there :)
[18:06:40] <mengwong> the accreditor likewise can provide various kinds of accreditation.
[18:07:03] <Maex> but I find it rather complicated to validate terms like "is a spammer" or "strictly adopts to doube optin"
[18:07:21] <Maex> or better it is IMHO impossible
[18:07:53] <mengwong> fortunately, other people don't think it's impossible :)
[18:08:20] --- millenix has joined
[18:08:31] <Maex> but until now they didn't provide information on how they will do the verification ...
[18:08:34] <mengwong> i suggest we let them have a go at it and see how they fare, rather than saying it'll be impossible.
[18:12:33] <Maex> but it is rather dissatisfactory ... Anne Mitchell updated the ASRG lists constantly about how great the IADB is, but she cannot answer how they will do the verfification process
[18:12:55] <mengwong> "of what use is a newborn baby?"
[18:13:01] <mengwong> give them time to mature, i'm sure they'll work all these things out.
[18:13:22] <mengwong> impatience with imperfection is not productive at this time.
[18:13:56] <mengwong> iadb is in a special position because anne knows firsthand most of the people in the deliverability industry, and can vouch for them personally.
[18:14:06] --- anewton has left
[18:14:07] <mengwong> other accreditation providers can establish other kinds of relationships with their customers.
[18:15:26] <Maex> but verification is imho an integral component of an accrediation system ... it's like "bring us all your money and we'll make gold out of it" and then delaying the problem to really turn it into gold to the point whehn the first one really wants to see gold for the money
[18:15:56] <mengwong> right, and you can start a reputation service that says "this accreditor sucks".
[18:17:06] <mengwong> if you think you can do accreditation better than they can, you should start an accreditation service :)
[18:17:37] <wrs1864> (amusing note: I recently recieved a spamcop complaint about a post I made to the MXCOMP list. (and sent *only* to the list))
[18:18:10] <wrs1864> sent a response to spamcop, the user and my ISP's abuse desk and got an immediate response from spamcop and the user.
[18:18:27] <wrs1864> The user said "OOOPPPS! my fault!"
[18:18:38] <Maex> mengwong: *g* if I thought I could run a accrediaion syervice at all I wouldn't they that IMHO they don't work at all :)
[18:19:37] --- dcrocker has left
[18:19:43] <wrs1864> I gotta admit that I'm surprised that the IETF runs unconfirmed opt-in lists...
[18:20:05] <mengwong> i remember having to double opt-in for mxcomp.
[18:20:12] <mengwong> so the MARID working group is actually MXCOMP, right?
[18:20:16] <Maex> *sigh* what letter salad am I writing ... better should go to bed :( 1:30 am over here ...
[18:20:17] <wrs1864> yeah
[18:20:34] <mengwong> what did we decide at today's meeting?
[18:20:37] <Maex> I have never had to double optin with lists @imc.org
[18:20:58] <wrs1864> this meeting can't decide anything, it is the mailing list that controls.
[18:21:46] <Maex> 2821from has highest prio, eventually in combination with EHLO, 2822info is a nice to have, my mtamark has been dropped it looks :)
[18:30:14] <mengwong> i'm glad we discussed 2821 vs 2822.
[18:30:54] <mengwong> if we'd started talking syntax before subject of authentication, it would be like arguing about which side of the street to walk on, when the real question is which way you want to go.
[18:31:31] <mengwong> i still think 2821 return-path and HELO attract designated-sender approaches, and 2822 attracts crypto approaches.
[18:32:00] <mengwong> but as an intermediate solution, we can connect 2821 and 2822 together using imperfect means to deliver acceptable interim results.
[18:34:19] <Maex> yep ... 2822 should be subject to pgp or s/mime and that should be pushed ...
[18:34:56] <Maex> but there is too less infrastructure for pgp and s/mime to really be used ... just think of revocations ...
[18:35:03] <mengwong> and we can still describe pgp and smime using SPF syntax, too. oh well.
[18:40:39] <mengwong> goodnight to you, maex.
[18:40:57] <Maex> night, have to run too, my girlfriend will kill me :)
[18:41:11] --- Maex has left
[18:48:24] --- jgmyers has left
[18:48:43] --- Maex has joined
[18:48:57] --- Maex has left
[18:59:08] --- mrose has left
[19:18:40] --- anewton has joined
[19:20:13] <mengwong> thanks for running this thing, anewton.
[19:20:21] <mengwong> sorry for my blurting. i'm new to moderation.
[19:20:24] <mengwong> goodnight.
[19:21:03] --- mengwong has left
[21:41:07] --- millenix has left
[22:20:06] --- anewton has left
[23:36:09] --- gconnor has joined