Subject: [Asrg] Update to DS Protocol draft

From: "Gordon Fecyk - Home" <[email-masked]>
Date: Sat, 22 Mar 2003 13:42:44 -0600

<http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt>

As I haven't yet submitted it to the IETF, the version number hasn't
changed.

The big question I was asked two weeks ago was: "What selfish reason do I
have for implementing this protocol?"  Well, I've now provided several.

I've also added notes on mail forwarding, which is still going to be
affected.  Mailing lists seem unaffected - every list I'm subscribed to
either has "[$LIST]-request@" as the envelope sender or some other envelope
sender for tracking delivery failures.

Finally I've added a note about RFC 2821 section 7.1.  That section says how
efforts like mine remove otherwise useful functionality.  I've tried to
address that.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Sat, 22 Mar 2003 22:04:19 -0800 (PST)

Some notes on your proposal:

I. ASRG can not send documents protocols to IETF for "protocols", they 
can only be or something that may become "informational" RFC
(Note: this is major difference between IRTF and IETF as was explained to me)
So your draft would have to go as individual submission especially since 
asrg is not yet at the point of submitting any kind of documents.

II. What you're proposing is just like SRV RMX record. But srv records are 
more advanced. Your point that DNS does not support it yet is not 
appropriate - you expect sites to update software to support DS draft but 
not update their dns software... I means if domain has to put this record 
in, it might as well update dns software, not that complex and if somebody 
is going to use the records, they'd have to update mail software, so I do 
not see problem updating dns software. But really this is not a main issue 
with the proposal...

III. As I already mentioned multiple times before this is typical 
"RMX/Mail-From" style proposal which has the following problems:
 1.You only authenticate MAIL FROM header but if "From:" is forged, that 
   is what user will see on their MUA, not MAIL FROM.
 2.Breaks mailing lists (all have to be whitelisted - see:
   https://www1.ietf.org/mail-archive/working-groups/asrg/currest/msg00762.html
   You do have a section in the draft regarding mailing lists. But this 
   section is not correct. Correct would be to say that those usind DS 
   records MUST NOT send email to mailing list UNLESS mailing list has been
   WHITELISTED ON THE SERVER. There just no other way to deal with mailing 
   lists (not if it supports DS records or not, does not matter).
 3.Breaks majority of forwarding configurations. Again you have to 
   whitelist servers that may forward email to your server. Here the 
   situation is little worth, because spammers often put the use the same 
   domains in their from (ok, used to do it 2 years ago, now using free 
   mail services like yahoo or hotmail is more common)
 4.Roaming users (like me on IETF conference) can not send email directly 
   and have to authentication with their "home" mail server. Actually this 
   is the list of my problems... I would really prefer to separete SUBMIT 
   and server<->server SMTP and require authentication on SUBMIT.

---

From: mathew <[email-masked]>
Date: Sun, 23 Mar 2003 10:13:52 -0500

> "RMX/Mail-From" style proposal which has the following problems:
[deleted]

Also, I don't see how this helps at all on a net where there are 
hundreds of thousands of open relays, all of which we assume would have 
valid designated-sender records and hence be allowed to relay spam to 
you.

mathew

---

From: "Gordon Fecyk - Home" <[email-masked]>
Date: Sun, 23 Mar 2003 10:50:56 -0600

> can only be or something that may become "informational" RFC

Semantics.  Whatever.  I'll submit it as a private draft.

> II. What you're proposing is just like SRV RMX record.

Actually, no.  From what I've read on RMX it's not IP based.  It's too easy
to falsify anything else.

> Your point that DNS does not support it yet is not
> appropriate - you expect sites to update software to support
> DS draft but not update their dns software...
> I means if domain has to put  this record in, it might as well
> update dns software, not that complex

Tell that to a Microsoft house[1].  Especially a M$ house not upgrading to
Win2003 Server because they don't trust it.

>    is what user will see on their MUA, not MAIL FROM.

I'm not interested in the body of the message.  Yes, it's easy to falsify
the headers or the envelope.  I'm saying these forgeries will be easier to
track for sites using DS.

I'm also not deluded into thinking this will solve all mail forgeries.  I'm
only interested in accountability, and this improves accountability
dramatically for little cost - updating the MTA only and adding a few DNS
records.

> https://www1.ietf.org/mail-archive/working-groups/asrg/currest

All mailing lists I subscribe to have either [email-masked] or
a complicated return envelope for tracking bounces.  And I subscribe to
majordomo, listserv, yahoogroups and EMWAC IMS based lists.  I'll show you
some log entries from my mail server:

<[email-masked]> [22/Mar/2003:11:19:37] 209.228.33.247
c007.snv.cp.net
[email-masked]
[email-masked]
<[email-masked]> [22/Mar/2003:22:32:04] 209.228.33.246
c007.snv.cp.net
sentto-113989-4623-1048393919-mmajor=[email-masked].
com [email-masked]
<[email-masked]> [22/Mar/2003:22:03:33] 209.119.0.109
cherry.ease.lsoft.com [email-masked] [email-masked]
<[email-masked]> [23/Mar/2003:00:51:33] 132.151.1.19
www1.ietf.org [email-masked] [email-masked]
(repeated several times)
<[email-masked]> [23/Mar/2003:06:33:12] 65.198.151.222
web8.gemini.dice.com [email-masked] [email-masked]
<[email-masked]> [23/Mar/2003:08:35:50] 207.195.213.10
poet.minstrel.com [email-masked] [email-masked]

You're telling me that these will break under DS protocol and will have to
be whitelisted?  They all have return-paths pointing back to something other
than the original sender, usually the list owner or sometimes a bounce
processor.  These would not be blocked under DS.

Mailing lists that don't do that are broken already.

>    mail services like yahoo or hotmail is more common)

Now these would require changes to MTA software and I freely admitted that.

>    and have to authentication with their "home" mail server.

SMTP AUTH, POPAUTH, etc take care of this.  It's actually my point - you
should use the resources you're authorized to use.  I can roam, hell I've
even had to sit on someone's Charter connection, then Earthlink, then some
local ISP during my last road trip, and I could still send mail through my
own server.

[1] And you're deluded if you say that anyone running MS server software is
not worthy/asking for trouble/a waste of time/etc.  Fact is, it's out there
and there isn't thing-one we can do about it.

---

From: "Gordon Fecyk - Home" <[email-masked]>
Date: Sun, 23 Mar 2003 10:52:53 -0600

> valid designated-sender records and hence be allowed to relay spam to

I cover this as a Security Consideration in the draft.

Let's see, a site running an open relay participating in DS Protocol.  That
doesn't make a whole lot of sense.  Sites choosing to use DS are likely well
aware of the spam problem and have already secured their systems against
relay theft.

---

From: David Walker <[email-masked]>
Date: Sun, 23 Mar 2003 12:28:50 -0600

Assuming the DS idea is similar to my idea (outlined at 
http://www.vorteon.com/papers/spam_reduction_through_dns.html ),
this would prevent any open relay from delivering messages to my mail server 
where the real admin of the from domain had their DNS properly configured.
i.e
open relay = 10.3.3.3
MAIL FROM domain = aol.com

my mail server will check with the DNS server at aol.com and discover that the 
open relay at 10.3.3.3 is not a valid aol.com server and will not allow mail 
delivery.  This is a tremendous help as it limits the ability of a spammer to 
abuse an open relay with false message headers.  They could, of course, still 
abuse the open relay using the domain names that it is a legitimate server 
for.

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 23 Mar 2003 13:24:09 -0500

At 10:13 AM -0500 3/23/03, mathew wrote:
>hundreds of thousands of open relays, all of which we assume would 
>have valid designated-sender records and hence be allowed to relay 
>spam to you.

It means that the spammer would have to use the relay's domain in the 
envelope from.  And that makes identify the problematic relay that 
much easier.

Of course that assumes that someone who is running an open relay 
would have bothered to update their DNS to support this.  Not likely.

Remember.  None of these non-architectural solutions are going to 
solve the entire problem.  I think what we should be thinking of is a 
jigsaw puzzle.  Can we put enough pieces in place that the entire 
picture is clear--even if there are a few  holes.

Okay, that was a lousy metaphor.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 23 Mar 2003 13:21:22 -0500

>in, it might as well update dns software, not that complex and if somebody

There's a big difference between adding new entries in your DNS 
database and updating your DNS software.  I'd do the first in a 
second.  The latter requires that I a) wait until my DNS vendor 
supports it and b) am convinced that I need the new feature and want 
to take the risk of new software.

>not see problem updating dns software. But really this is not a main issue

Again.  As I understand the proposal, it's the difference between 
adding a plugin that is very similar to existing DNS checking 
plugins, vs. new libraries and protocols.  Big difference.

People are real reluctant to add new protocols and new software. 
They are much more willing to use something hacked on top of an 
existing system.  When we are making proposals that involve changes 
to millions of computer systems--we have to take this into account. 
Even if it means doing things the "wrong" way.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: [email-masked]
Date: Sun, 23 Mar 2003 10:44:46 -0800 (PST)

That wouldnt matter as system breaks on any relay be it open or close.

---

From: [email-masked]
Date: Sun, 23 Mar 2003 13:29:08 -0800 (PST)

> Semantics.  Whatever.  I'll submit it as a private draft.
I agree. I mentioned it for others who were doing drafts.
 
> to falsify anything else.
RMX is ip based like MailFrom, like several other proposals

> Win2003 Server because they don't trust it.
I'v given up on Microsh.t software, especially its dns server portion.
I only expect them to provide client support and on last meeting they 
promised to do so if SRV becomes standard, which RFC2782 is (as opposed 
to 2052).

> track for sites using DS.
Again what do you think is seen by more users - "MAIL FROM" header which 
is kept on the server and only some clients are able to see it or "From:" 
header which everybody assumed is where email came from. As I said before, 
all this may do is to have spammers use some obscure domain for MAILFROM 
which may not have updated their dns and sysadmin there might not care or 
it might be unused domain. But "From:" will remain pointing to msn, 
hotmail, yahoo, etc and users will continue to assume it came from there 
and report it there. The number of mail bombs will not dimish seriously. 

But what will happen is that seeing all this anti-spam filters will begin 
to get updated to compare "MAIL-FROM" to "From:" and deny access when they 
are not the same and this will lead to hotmail situation and necessity to 
whitelist all mailing lists.

> processor.  These would not be blocked under DS.
Yes they  (see my answer above). Or if they are not, the system will do 
nothing more then change what is listed at mail-from which might still be 
forgery. 

> Mailing lists that don't do that are broken already.
How nice of you to not care about compatibility with existing email 
infrastracture.

> and there isn't thing-one we can do about it.
Well. If people find that if they do not run microsoft software that they 
can stop spam, this would be the good reason for them to consider switching
to something better :) Will work a loot better then any other ways to 
introduce linux as mainstream os :)

But in reality, no I do think about people running microsoft software, should
be left out, but somehow I suspect any early adapters of any shemes like this
would be the ones who would be willing to update dns and if anythink like 
this becomes mainstream by that time microsoft will support srv.

---

From: "Gordon Fecyk - Home" <[email-masked]>
Date: Sun, 23 Mar 2003 22:54:29 -0600

> I'v given up on Microsh.t software

That's enough.  The rest of your missive isn't even worth quoting.

*plonk*

---

From: Chuq Von Rospach <[email-masked]>
Date: Sun, 23 Mar 2003 20:55:14 -0800

> That's enough.  The rest of your missive isn't even worth quoting.

and what you do personally is up to you. Anything that tries to solve 
the problem we're here to solve has to consider and support Microsoft, 
or it's a non-starter.

-- 
Chuq Von Rospach, Architech
[email-masked] -- http://www.plaidworks.com/chuqui/blog/

---

From: [email-masked]
Date: Sun, 23 Mar 2003 19:14:32 -0800 (PST)

> the problem we're here to solve has to consider and support Microsoft, 
 
I agree (unfortunetly). But the particulars of SRV and Microsoft has been
discussed on many many other lists before. Allmost everyone is in agreement
that Microsoft will have to support this and every other protocol is being
developed with SRVs in mind. Just look at multiple RFCs that already have 
that in them and even more drafts.

As far as various dns-mail-from proposals, I find DSDNSBL the best one as
far as dns portion of it. But all these proposals are too easy to 
circumvent by spammers and are too restrictive for existing email 
communication, that is the main reason I'd not support them. Nothing to do 
with SRVs or Microsoft. 
 
-- 
William Leibzon
Elan Communications Inc. 
[email-masked]

---

From: David Walker <[email-masked]>
Date: Sun, 23 Mar 2003 23:57:11 -0600

Obviously you're entitled to your opinion but I don't see this as anything 
more than the slightest bit restrictive for existing communication.

It will require domains to set up authenticated ways of sending e-mail when 
not on your home network which just seems like good sense to me.  And if you 
don't feel like doing that you can just leave it unconfigured and continue to 
enjoy the same lax measures we enjoy today.

As far as being easy to circumvent by spammers, the more you limit what they 
can use in their fake headers the greater the chances they will have to use 
real headers.  Once they're using real headers sensible blocking and/or legal 
complaints actually become feasible.

Currently open relays is a major problem.  This would limit the usefulness of 
open relays and eventually shift the focus from people who had open relays to 
people that didn't have their DS configured.

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 23 Mar 2003 22:58:26 -0700 (MST)

> From: Chuq Von Rospach <[email-masked]>

> ...

That is true only of solutions that require large critical masses.  Not
all spam defenses are like that.  Various blacklists are the canonical
example of defenses without significant critical mass requirements.

It is worth remembering that anything that blocks all spam from all
targets is a non-starter.  Some of the net will always be spam-friendly
and will demand and require the right to have lots of spam.  Spam is
always only determined at the mailbox of the target. 

Speaking of Microsoft, it would be swell if the Bcentral sources of
unsolicited bulk email that have been pounding at my mailbox and traps
for years and even this week would stop.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 24 Mar 2003 08:39:41 -0500 (EST)

> complaints actually become feasible.

This point needs some expansion. Is the purpose of the proposal to allow
receipients to block on characteristics other than connection address? To
block only the spammers, and allow the legitimate mail to go through? Why
doesn't this have dangerous incentive effects, that is, MTA maintainers
will lose part of their incentive to block spam at the source because
their own legitimate mail will no longer be at risk of being blocked.

I can certainly see some ISPs giving up on spam control, and just telling
receipients that they should drop forged header mail rather than forward
it to abuse@.

Daniel Feenberg

---

From: David Walker <[email-masked]>
Date: Mon, 24 Mar 2003 09:47:45 -0600

abuse@ where?  It takes research and guesswork to determine that.

I really don't understand your question.  The purpose of the proposal, (as I 
see it, it isn't my proposal) is to provide a tool I can use to check and see 
if the mail is being sent from an legitimate, acceptable machine under the 
control of the the sender's domain.  Presumably if someone is trying to send 
mail FROM my domain from a machine I have disallowed, then they are not a 
legitimate mail user (a spammer and/or a forger) and should not see their 
message delivered.

There is no reason this proposal would encourage ISPs of spammers to allow 
spam through.  Dropping forged header mail (with an SMTP error code) is just 
good practice.

I think you're confusing MTA maintainers at the forged from site with the MTA 
maintainers running open relays.  With the current design, when someone sent 
out a mail with a forged @grax.com from address the bounce messages came to 
me.  But I have no control whatsoever on who sends mail "from" my domain 
until we get this implemented.