At 02:14 PM 12/15/2003, you wrote:
Hi Burzin,
I wasn't thinking from an individual standpoint, but globally, as in cooperative efforts by all mail system providers to provide traceability and valid sender enforcement. I certainly realize that I individually have no control over others' systems to prevent spam, but with cooperative efforts between all providers we can make a difference.
I think what you are saying (traceability and valid sender) can be summed up as good email server management. RFCs provide a good place to start, but as many people on the list have pointed out, many server admins don't abide by these practices. Sometimes it's out of ignorance, sometimes its out of laziness, and sometimes admin knows what they are doing and has a valid reason for it. This doesn't even address RFC compliance by the software developers on the server or client side.
Ultimately some of this may be "fixed" by a successor to SMTP. This may not be a bad route to pursue, but there's always this thing about backwards compatibility.
As an Imail admin., I use the Delcude, Sniffer, and Imail forums/resources to make sure I'm following "best practices". There are other flavors out there. Is there better forum, or site that can be used by admins to secure their servers, understand the dos and don'ts, and correctly implemement them?
Not sure about the second part of your argument regarding FPs and business risk, and how it relates to this topic. Certainly I've always taken the stance that we have to err on the conservative side to ensure all legitimate business correspondence gets delivered, even if it means some spam gets through.
SMTP is a dual edged sword it works very well on a technical and social/business levels. However, its precisely because it works well on these levels that we have to deal with spam. If a large enough ISP or a group of ISPs takes action to prevent spam and if these efforts prevent enough mail from being delivered or make it a hastle for email to be delivered, it dimishes the utility of email.
My point is again that I'd like us to all put our heads together to see what measures we can initiate that will prevent spam from being sent in the first place. Outbound port 25 blocking from dynamic addresses is a start, but would only be partially effective as trojans, open relays, and port redirectors allow spammers to get around it.
I guess what I was thinking is if we all could come up with a scenario to all but eliminate spam through cooperation by all providers, we could write up our recommendations and publish the results to the major players, lobbyists, and independent and government agencies to try to make it happen.
As I mentioned before I'm wary of efforts that encourage spammers to develop viruses and worms to circumvent the blocks we put in place, as that could be a much bloodier battle than the one we're currently in, but here's what I think the initial pieces to this are. There are obvious holes in this list, though, and it doesn't completely solve the problem.
I think we are only a step or two (at most) away from spammers developing viruses/worms.
1. All SMTP servers verify the sending IP and add it to the headers for traceability. Some mailservers and ISPs do this, but most do not. Thankfully, this is something that Declude assists us with.
I do this myself, but I can imagine organizations where they may not want this information out there for all to see.
2. Port 25 blocking for all dynamic addresses with all network providers. This could cause some problems as I'm sure there are many legitimate networks that send from internal networks that are only connected via dynamic addresses, but it seems to be a critical piece to this effort. Forcing businesses that run internal mail servers to static addresses might not be a bad thing, though.
A subject of much discussion and consternation. I weight dynamic addresses.
3. Globally managed open relay list and blacklist, preferably maintained by some sort of non-profit internet council. This could help close many open relays if an authoritative, complete list was formed and maintained. This organization should be responsive to removal requests, but require the burden of proof on the petitioner.
I think we have several defacto lists out there already. Some of these are free,
but I suspect that the better ones will become non-profits and charge a subscription.
4. SMTP AUTH required on all SMTP servers, forcing users to properly authenticate in order to send. This might help reduce the virus threat. This is far from foolproof as the virus could use local mail profiles that have been set up with SMTP AUTH instead of embedding it's own SMTP component, but it's a start.
I do this now, but had to get all my users upgraded to correct clients.
I know that this won't be easy, but if we could make it happen, the end result would be extremely satisfying.
Any comments, or other ideas to add to this list?
Scott, sorry if this is too far off-topic, but I thought this would be a good community to discuss the possibilities. Let me know if you'd rather we take this discussion to another list.
Darin.
-
--- [This E-mail scanned for viruses by Declude Virus]
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
