Bruce on CircleID

Bruce

Joined on May 16, 2005
Total Post Views: 0


	About


	Send Message


	RSS

Information about this member is not available yet.

Comments

Port 25 Blocking, or Fix SMTP and Leave Port 25 Alone for the Sake of Spam?

Comment posted May 16, 2005 1:43 pm PDT — by Bruce
Suresh; We can debate this all day long. This will not change either my position or the fact that we have already chosen to adopt SPF, along with other control measures. With regard to Microsoft, we will NEVER purchase a license to use an anti-spam product they might developed. We already have the ability to run free software on unix systems, why would we want to pay a company that has set a new standard in corrupt vaporware for a product that they basically stole from another software author? If there is a major shift in the industry, we will consider looking at the tools that are used by other ISPs. For now, I stand by what I have written above and implemented for our users and customers - they are happy. Stop your feat, yell and scream, give me and the developers of SPF as many �technical (de)merits� as you like, it will not change my position.

Comment posted May 16, 2005 11:57 am PDT — by Bruce
PS: SPF does NOT require a license from Microsoft.

Comment posted May 16, 2005 11:56 am PDT — by Bruce
Doug et al; We handle substantially more than just family members. Our user base is extremely diverse and ranges from hospital surgery centers to e-commerce sites to conventions that are in Chicago only once a year but get e-mail and…

Comment posted May 16, 2005 3:08 am PDT — by Bruce
ISPs already have the ability to force compliance to anti-spam policies. . . 1. Force authentication - if everyone who wants to send e-mail must send a username and password to send, that substantially cuts our all non-authorized e-mail. If a machine is infected, the account can be disabled as soon as the rough operating system is noted by the service provider. No free rides for anyone. 2. Use SPF1 with �-all� on all domains. We do this quite successfully. No one can send mail via our servers unless someone they authenticate and then our SPF records validate the fact that the message actually came from the server. We have an SPF record created for every one of our customers and only mail that originates from our mail servers passes the SPF tests. 3. Make anyone sending e-mail to use IDENTICAL information in the E-MAIL ADDRESS and REPLY TO ADDRESS of all outgoing messages. The information contained within those fields must exactly match the e-mail address under which the message is being sent. If your customer�s e-mail client is set up any different, refuse to transport the message - no exceptions. 4. Enable port 587, as defined by RFC 2476 for the use of roaming users. 5. Mandate authentication on port 587. No free rides for anyone. 6. If a user violates the policy, disconnect them. 7. If another ISP violates the anti-spam policy, block all incoming messages from them. 8. Block all incoming messages from any domain where the mail server does not have a PTR (reverse DNS) record. Refuse them before they are ever received. AOL already does this and any legitimate mail server now has a PTR record that can be validated. 9. Check all mail servers for the acceptance of DOMAN LITERALS, ie: user@[XX.XX.XXX.XXX]. This is already mandated by RFC2821 4.5.1. We do this and quarantine all messages that will not accept queries for the domain literals. If we find a domain that does not comply, we refer them to www.dnsreports.com and have them run a report on their name. It sometimes requires some additional explanation on our part, but many of them not only comply, but begin to check for acceptance of domain literals as well. 10. Block all incoming messages from domains listed in the SPAM DATABASES. We run a check on all incoming messages against SPAMCOP. If a domain is listed, the message is dumped. SPAMCOP only lists for 48 hours and then rescinds the listing. If the sender�s domain is listed frequently enough and they ignore the messages they receive from SPAMCOP, the don�t deserve to be sending e-mail and adding to the bandwidth on the internet. 11. A suitable period of time after SPF is accepted and becomes part of the RFC, refuse to accept messages from any domain that does not publish an SPF record using �ALL. Yes, there will be some yelling, screaming and stomping of feet in the beginning, but, eventually, the dust will settle and we�ll all be able to get back to the task of running our businesses instead of allowing spam to raise our blood pressure! The problem is not controlling spam. The problem is getting ISPs to quit being afraid of their customers and take a stand.

Topic Interests

Cyberattack, Spam, Security, Internet Protocol, DNS, Cybercrime

Recent Blogs

There are no featured blogs by this member yet. View More

CircleID

Bruce

Comments

Port 25 Blocking, or Fix SMTP and Leave Port 25 Alone for the Sake of Spam?

Topic Interests

Recent Blogs

Popular Posts