[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX] proposals
Little addition:
Network based control mechanism for MTAs and
domain based control mechanisms can co-exist very
happily.
Network based control mechanism tries to ensure that
the contacting MTA is trusted/registered at that network.
Spammer can register own network, this control mechanism
will fail (but can be detected using RBL).
Domain based control mechanism ensures that the sender
sends the messages from the registered MTA for that domain.
However, any spammer can register tens of domains for them
and send spam using his own MTA which is registered to those
domains.
Neither of the control mechanisms above can verify that
the sender is actually who (s)he claims to be, but when used
together the network based control forces the spammers use
indirect connections (using the MTAs registered for the network
they are using). Domain based control mechanism forces them
to use domains they have registered.
----- Original Message -----
From: "Tomi Panula-Ontto" <tomi@panula-ont.to>
To: <asrg@ietf.org>
Sent: Saturday, November 29, 2003 10:11 AM
Subject: Re: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX]
proposals
>
> ----- Original Message -----
> From: "Matthew Elvey" <matthew@elvey.com>
> To: <security1@awot.fi>
> Sent: Friday, November 28, 2003 7:06 PM
> Subject: [Asrg] Re: 6. Proposals: LMTP vs. rDNS / Reverse MX [RMX]
proposals
>
>
> [cut]
> > >MTAMark draft tells us the problem (from the spam point of view),
> > >and they have done great job, but I think it's a little too complicated
> > >to maintain. It may require configuration per domain if virtual
> > >domains have their own MX setup (this does not apply to all setups).
> > >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).
>
> > >RMX records (Do not confuse with Reverse MX records) is domain
specific.
> > >It's simply a list of IP addresses that can send email from some
domain.
> > >In reality, some of the users may use just about any sending SMTP
> > >server [depending on their ISP]. For example, I have a client that
> > >operates in couple of countries, each using different ISP, yet the
> > >incoming MTA is always the same, outgoing MTA is never the same.
> > >They could be using SMTPAUTH, but instead they use email server
> > >of ISP to send out messages. Do you think I could do something
> > >about it? Should I administrate a list of outgoing mail servers for my
> > >client in this case? No. It's not my job, so I'm against it and I
believe
> > >most of the administrators are against it. Also, RMX requires new
> > >record type, that some bind versions refuse to send out.
> > >
> > >
> > Argument built on a false foundation. Your client isn't using "just
> > about any sending SMTP server". A short list of the IPs of the SMTP
> > servers of the two (or 20) ISPs your client uses is 0.0% of the SMTP
> > servers on the 'net.
>
> Well, I'll give an example: client operates in more than 20 countries, has
> travelling salesmen and agents in many countries. Yet, they all use same
> email domain and everyone uses their current ISP to send out messages.
> Notice: Travelling salesman maybe connecting even from hotel network.
> From my point of view; outgoing MTA can be any server in the world.
> How could I know I should temporarily add record for MTA of some
> ISP the hotel is using ?
>
> I agree that domain specific configuration would be better, but it's
> simply another layer of control. I think we should have network
> level control (legitimate MTAs for some network) AND we should
> have domain level control. The whole problem of SMTP is that
> it has had no control mechanisms at all. Anyway, at this point I think
> the network is nearest (and easiest; IMHO) control mechanism
> and at this point my interest is on the network centric approach.
>
> When IP addresses get restricted, the spammers will have to use
> those servers that are "trusted" and it's lot easier to point the spammer
> from a known IP list than from approx. 2^32 IP addresses.
> Spammers are a moving target, changing their sending MTA all
> the time and I'd like to make them a sitting target. Bad behaving
> networks can be blocked out using RBL.
>
>
> > Under the "rMX and rDNS co-operate" scheme, this list is of IPs trusted
> > (i.e. listed) by people who have often proven untrustworthy.
>
> This is true, we will have problems if the network administrators are
> untrustworthy. However, if 20% of network administrators are untrustworthy
> and 80% are trustworthy then I'll be happy to RBL the untrustworthy
> networks away.
>
>
> > >Reverse MX
>
<http://www.awot.fi/cgi-bin/textdb/browser/showfile?cust=awkoulutus&subdir=d
> ns&doc=reverse_mx>
> > >MTAMark http://www.space.net/~maex/draft-irtf-asrg-mtamark-00.txt
> > >RMX Records http://www.mikerubel.org/computers/rmx_records/
> > >
> > >
> > LMAP:
> >
>
<http://asrg.kavi.com/apps/group_public/download.php/15/draft-irtf-asrg-lmap
> -discussion-00.txt>
> >
> >
> >
> > _______________________________________________
> > Asrg mailing list
> > Asrg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/asrg
> >
>
>
> _______________________________________________
> Asrg mailing list
> Asrg@ietf.org
> https://www1.ietf.org/mailman/listinfo/asrg
>
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg