[EMAIL PROTECTED] wrote:
On Mon, 16 May 2005, Bill Taroli wrote:
Matt Fretwell wrote:
I don't think it's a matter of reliability... it's more an issue of accountability and traceability. How can one trace back to a dynamically IP'ed MTA when it's dynamic? [...]plenty of legitimate MTA setups running on dynamic IP's. [...] What really does amaze me though, is that these are generally the admins who will turn around and say, 'Don't block (variable), you will lose too much legitimate mail'. Where is the logic in that? They will allow a crappily configured multinational corporation or ISP to connect, yet not give dynamics the slightest chance to prove their reliability.
I don't disagree that there may well be many people running wholesome MTAs on dynamic IP's that suffer for the rest. But it's that rest we're all concerned with. I honestly wonder whether an authorization framework such as SPF would be the salvation of such setups... permitting them to prove themselves worthy without the need for static IP addresses.
But until that time comes, any host who appears to lie about it's identity by giving a host name that doesn't match it's visible IP address is getting the door slammed in it's face by my MTA.
[...] For email transfer and MTA's alike, putting SPF in DNS to help
"authenticate" the source is a step in the right direction. If SPF is a
good idea, and it is dns based, then so should forward-and-back lookups.
I totally agree that some solution is desirable to these issues. There are several efforts underway, including SPF -- which now appears (according to a recent visit to http://spf.pobox.com/) to be a formal part (or companion) to Sender ID. Sender ID scares me a little, since it's proprietary. I firmly believe that we need (truly, not Microsoft's flavor of) open standards in this area. SPF doesn't come without issues, mostly in the area of how to deal with mail lists and such, but it's totally better than nothing at all.
In just the same way though, I would be curious about how far one would take the PTR lookup. Just that there is one? That it matches the actual name of the host? I mention the latter because it could cause problems in hosting situations, where a single IP address might legitimately be used by dozens (or even hundreds) of domains. And you have have just one PTR record for it. SPF handles this case nicely, because you can set up clear relationships between the domains from that host and it works well.
What discourages me, though, is that many mail admins can't seem to get their *forward* lookups right, let alone the reverse. ;-) I wavered on whether I'd strictly enforce this after I found how many were broken, and I've ultimately taken the stance that I will absolutely reject their mail, and then inform their admins (and the affected sender) that they have a problem and, yes, it is preventing their mail from being received. I don't even mind doing this for spammers in some cases... sort of making a point. ;-)
If additional mail standardization can take place (again) then spam can be reduced to a certain degree. I much like Brian Read's idea of blocking mail xfer from sites which are not authenticated (SASL) or who cannot give a proper reverse lookup.
I've already noted concerns about reverse lookup -- I'd prefer SPF in those situations. As for SASL... well, now that would be interesting wouldn't it? I can see definite advantages.. much like one would have experienced in the UUCP days. You know and trust who your neighbors are, and as long they in turn only hand off to trusted folks then the likelihood of keeping the spammers out would improve. It doesn't really do much for the trojan or worm case, so I guess some kind of ROI would need to be established before putting people through the paces of building networks of trusted MTA's.
The truth is that no solution will be perfect... we just need to find something that's effective and yet doesn't add unduly to the administration requirements or cost. I like solutions like SPF for this because with a few DNS entries and compliant MTA's, a world of good could be done. Efforts like Sender ID (and Domain ID... if I remember the name correctly) add another layer, but I fear Microsoft's entry sacrifices too much in the way of being proprietary while it insists that it's an open standard -- they love these sorts of contradictions.
Every ISP we have worked with have been happy to
create or change a PTR entry in their dns, even if it took a lot of work
to get the ISP to do so (I even offered to do it for one isp and they
finally did it themself).
Yes, people are usually just unaware that their configuration is problematic as others roll out solutions to prevent spam, etc. I've found some who'd rather bury their head in the sand -- "well it works 80% of the time" -- but most are very conscientious about keeping things working properly.
If we can standardize the set of rules and protocols required for an MTA to accept an email, then spam will reduce. Either that or we need to build a better mousetrap. [...]
I think the truth is that as long as there is a potential to mis-use the medium to financial (or other) advantage, there will be people who make all efforts to do so. That said, I see no reason we shouldn't keep the pressure on to keep things working properly and get the garbage out. Frankly, I find it easier to do this on the Internet than I can to avoid things like hardcopy spam (junk postal mail)... but in that case the delivery agent is complicit in the harassment: they benefit financially from those who would spam us. :-)
Bill _______________________________________________ http://lurker.clamav.net/list/clamav-users.html
