On 12/1/2003 6:56 AM, Tomi Panula-Ontto sent forth electrons to convey:
On 11/30/2003 1:00 AM, Matthew Elvey said:
----- Original Message -----
From: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
To: "Tomi Panula-Ontto" <tomi(_at_)panula-ont(_dot_)to>
Sent: Sunday, November 30, 2003 1:00 AM
Subject: Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX]
proposals
Reply below. Please reply to the list, quoting me.
On 11/29/2003 12:11 AM, Tomi Panula-Ontto sent forth electrons to convey:
[cut]
Also, I don't like parsing TXT records (Parsing == bugs == troubles).
Bind and Tinydns seem to differ in TXT records, too. Some Bind versions
send extra character (space or ") (parser bug?) whereas Tinydns
doesn't.
Conclusion: I'm against TXT records.
A bug in the TXT part of software that has known security holes and MUST
be replaced anyway isn't a deal breaker, IMO; I'm assuming these bugs
are only in old versions.
It's easy to say "must", but lot harder to get all the servers upgraded.
It isn't deal breaker; MTAMark has very good qualities (and I think I had
a little misunderstanding on my side here about it).
So you are no longer against TXT records, yes?
I'm still against both TXT record and parsing.
I don't like the idea of receiving multiple ASRG.<PARAMETER>=<VALUE>
that I'm supposed to parse and make the decision.
I want to keep things simple.
The original reverse mx proposition suggested that we should have
a list of IP addresses [=authorized/trusted MTAs] for a given network.
Scenario: "IP is listed => Allow"
Scenario: "IP not listed => Deny"
Scenario: "IP not listed (no list) = Work as before (Allow)" (Deny if timed
policy change?)
MTAMark was in this sence a bit better; instead of getting the LIST of IP
addresses (and using multiple dns queries) there would be one simple answer;
ASRG.MTA=YES or ASRG.MTA=NO - so there is no need to determine
whether the network admin has done the job.
Reverse MX proposition has been updated after this.
4.3.2.1.in-addr.arpa IN PTR mail.company.dom.
4.3.2.1.in-addr.arpa IN MX 10 127.0.0.2
127.0.0.2=Allow, 127.0.0.3=Deny
(I'd say priority field should be reserved and should be 10, any comments?)
If one wishes, it's still legitimate to inform reason (or whatever)
in TXT record
4.3.2.1.in-addr.arpa IN PTR dialup-127.company.dom.
4.3.2.1.in-addr.arpa IN MX 10 127.0.0.3
4.3.2.1.in-addr.arpa IN TXT "DIALUP"
There is a record type for this purpose, so why not use it?
Why invent a system on top of a system?
Well, for one thing, I fear people like me (one static DSL IP on SBC) or
using dyndns on a dynamic IP are unlikely to be able to convince their
ISPs to put such entries in DNS.
I suppose it might make RBLs need fewer entries. But should my ISP, a
common carrier, have any business deciding whether or not I should be
able to run a non-abusive mail server? I'd rather they not, when the
benefit is a very slight impact on spam that can be achieved without
such restrictions. I prefer to have RBL runners in control to ISPs in
control, but I guess that's a political question. I'd most like to have
LMTP in control.
Fewer entries? A LOT fewer entries. No more spamming from dialups,
or from unauthorized IPs, etc.
Are you saying that if this MTA registering would be mandatory
to the network owners and receiving MTAs would start using it
it would not cause any or irrelevant amount of reduction in spam?
Not that I recall. These protocols only become 'mandatory' if they
catch on and become broadly used. The IETF has no power to force people
to follow their rules.
MTAmark has less of a chance to catch on than LMTP, because it provides
a smaller incentive to adoption, as I've explained in a previous post.
If your domain is being forged, you're highly likely to adopt LMTP. If
a ISP's IPs are being used to spam, they may well not adopt MTAmark.
I'm not against MTAmark; I think LMTP should be a higher priority.
It's LOT easier to spot bad behaving IP addresses from a set of
500 000 registered MTAs than from a set of approx. 4^32 (not to mention
IPv6).
It gives us a more control; the network abuse team can block it and if they
don't or do it late, we can still RBL the spammer out.
Your network provider (aka. reverse zone administrator) should ask
you "Hey, in order to fight solicited email, we have to register all MTAs.
What's your MTA IP address?" You give them your IP(s), they add
it to the dns and everybody should be happy.
Should, should.... The ones that will are the ones that terminate their
spamming customers. I don't see MTAmark providing any incentive for
ISPs to be more responsible than they are now.
This is a little change, little check, which is easy to maintain and
easy to develop support for it. If there are no major problems with
it, then why not?
I think Eric Raymond explained why a try everything and see what sticks
plan isn't ideal. It dilutes resources.
PHB: You contribute valuably, but please stop repeatedly whining OT
about DNSSEC WG's 'bad' practices when your company's ongoing
wrongdoings (which folks don't whine about here) are so egregious, and
your proposals often promote Verisign's (patented, proprietary, contrary
to IETF policy) technology. Not to mention that certs don't cost $350
as you claimed, if bought from Verisign competitors who charge much less.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg