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?
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?
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.
Then, go ahead and generate spam as much as you wish, but don't
come wondering what happened when your network abuse team
unauthorizes your MTA IP address for spamming.
We need rules. One rule would be that you will have to register your
MTA with your network provider. I do know some networks
would propably set every IP they got as trusted IP - and we'll be
happy to RBL them away.
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?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg