RE: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc
Figures we would have to upgrade. We are at 7.1x as it has been very stable. Not sure we want to upgrade to problems. If someone sends an email and it shows up on our server as a 64. address. What about when the message is delivered to someone at AOL? Will it also see the 64. address, therefore fail the SPF test on their end also? Sincerely, Grant Griffith EI8HT LEGS Enhanced Web Management A Division of ETC http://www.getafreewebsite.com 877-483-3393 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of R. Scott Perry Sent: Wednesday, June 30, 2004 9:44 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc This brings up a good point, if I client is located in another part of the US and we have no way to know what IP Address they might be using. How can this be setup? For example, our server has around 16 IP's, 12.177.8.48 to 12.177.8.63, but we have clients that will not be connected within this range. They might be something like 64.77.164.248 or something. That is a good question. The best way to look at this is ask How does IMail let this client send mail, while not allowing spammers to send mail? The answer to that is SMTP AUTH. If you're using a version of IMail before IMail v8, you're stuck there -- previous versions do not record in the information that Declude JunkMail gets that SMTP AUTH was used. In that case, you would need to be creative (perhaps a filter that subtracts points for MAILFROM's that contain your domain). Does the SPF test use the 64. address when doing the test or the mail server that the message is being sent from which would be in the IP range listed above? It uses the IP that connects to the IMail server. So if the user connects directly, SPF would see the 64. address. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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. --- [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.
RE: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc
If someone sends an email and it shows up on our server as a 64. address. What about when the message is delivered to someone at AOL? Will it also see the 64. address, therefore fail the SPF test on their end also? No. AOL will only see the IP address of your server, and use that for determining if the E-mail should fail SPF. Since your mailserver is listed as one of the IPs that are allowed to send per your SPF record, AOL will pass SPF. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc
Sorry to butt in on this one...Yes, SPF would fail on other systems as well in that situation. If the client connects directly to AOL, SPF would fail. But if it is sent through the mailserver, it should not fail. As far as I can tell, SPF-PASS is not useful because there is nothing stopping a spammer that owns a server to set SPF up for it. True -- but that makes it easier to detect the spammers. Once they have a domain to use, it can be blocked. People will likely start RHSBLs listing domains that have sent out spam that appear to be owned by spammers. Setting up SPF for your domain is also IMO a bad idea unless you can guarantee that all of your users will only come from certain IP's when they send E-mail. For instance, although I prefer to be the outgoing SMTP server for my clients, some of them are either blocked by their ISP from sending E-mail through my server (port 25 blocking), or they just simply chose to set up their computers to use their ISP's mail server instead of our own. Therefore, I don't have a single client that I can guarantee that they will be coming from a particular range of IP's. In this case, what you should do is use v=spf1 mx ?all. That says If the E-mail is coming from an IP in our MX record, we authorize it. If it is coming from any other IP, we can't say whether or not it is legitimate -- treat it the same as if we have no SPF record. If you don't know all the IPs that users may send mail from, using -all at the end (anyone not listed in the SPF record is not authorized to send mail from this domain is bad. But using ?all at the end lets users who do send mail through your mailserver pass SPF, whereas nobody else will fail. Yes, it provides less protection from joe jobs (spammers using your domain may or may not get their mail through, since SPF won't prevent them), but it also allows your other users to get their mail through. You can set up SPF for you domain that states that the domain can be used from any IP, however I don't see any value in stating that something can come from anywhere when that in effect is the status quo. Using +all is definitely bad (you're giving spammers permission to send mail from your domain). But ?all is fine. Practically speaking, it's the openness of E-mail and the fact that it was never designed or implemented to prevent spoofing that is the cause of this problem, and the best way to get at the issue might be to simply re-write SMTP to allow for authentication of non-local E-mail. I believe that would be the best answer. Unfortunately, that is a huge undertaking -- the amount of time it would take to get a good group of people to write it and agree to it, plus the time it would take to implement (all mail clients would need to be re-written), would make it very time consuming. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers since 2000. Declude Virus: Ultra reliable virus detection and the leader in mailserver vulnerability detection. Find out what you've been missing: Ask for a free 30-day evaluation. --- [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.
Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc
R. Scott Perry wrote: In this case, what you should do is use v=spf1 mx ?all. That says If the E-mail is coming from an IP in our MX record, we authorize it. If it is coming from any other IP, we can't say whether or not it is legitimate -- treat it the same as if we have no SPF record. In theory this works perfectly, but even on this list people have suggested adding at least some points for the ?all condition. You have to consider the idiot factor and the problems that this can cause (such as blocking on ?all results, and to a lesser extent adding points). For instance, even AOL is using a system that allows for blocking perfectly legitimate IP's when messages are forwarded to their servers and someone presses their spam submit button. Challenge/Response is another perfect example of mass lunacy, in fact some C|Net figurehead was on CNN just a few days ago talking about how all E-mail will eventually move into a scenario that requires C/R. Mass idiocy abounds, and spam protection has become the same thing as the Internet circa 1996. So while the danger is minimal with ?all, it is there and I would prefer to not contribute my domains until I can be sure that people can't use their systems to punish my users for not coming from my own server. I have no idea what that would take to accomplish unfortunately. Even scoring SPF-FAIL is somewhat problematic because I'm sure that there are many administrators that don't list ?all conditions when they should, and the potential of false positives aren't worth the benefit currently in spam blocking. The stats that Scott Fisher shared are certainly interesting, although anecdotal without my ability to verify them. I believe that would be the best answer. Unfortunately, that is a huge undertaking -- the amount of time it would take to get a good group of people to write it and agree to it, plus the time it would take to implement (all mail clients would need to be re-written), would make it very time consuming. Well, I'm not holding my breath waiting for that to happen :) I would of course support it if it did. As far as I can tell, the only things that are worth whitelisting are local authenticated users whereas whitelisting (or crediting in a weight system) seems to be what all of this SPF/Caller ID stuff was primarily designed for early on, yet it is it's biggest failure thus far. I don't see any possibility of that working in the foreseeable future. What I do think would work much better in the near term would be for every mail server to support and require SMTP AUTH through port 587 as proposed, and then have every ISP out there block port 25 which would be used exclusively for non-AUTH'ed E-mail between systems. That would cut the zombie problem down dramatically without interrupting service, but this will probably take 5 years or more to widely implement. I think this would have a much larger effect than SPF in terms of blocking forging E-mail, the majority of which comes from PC's attached to these residential ISP's presently. AUTH hacking, or even server hacking however will become much more predominant when the bar is raised in this manner, but there should be many fewer machines to track. For now, I consider broadband ISP's to be honeypots for both the spammer and for my system of blocking spammers, and I like it that way :) Probably 90% of what gets through my system is from spammers that have their own IP space assigned to them, but haven't yet been tagged. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [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.
Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc
I agree that SPF is not very useful in the situation Matt outlined. We're in the same boat with users that may use their ISP or us to send mail from their domain. While SPF attempts to handle it through a switch that references other providers' SPF records, It's just not practical to list all possible ISPs that an end user could use to send mail. However, I have seen benefit from specifying domains that do not send mail. Spam that spoofs the from address as one of these domains is getting blocked...some of which was not previously getting blocked (sorry don't have firm numbers yet). Also, it is useful for corporate customers that can guarantee that all email will pass through one of a few mail servers. Only problem there is travelers who would then need to VPN or otherwise authenticate with one of those servers in order to pass SPF. Darin. - Original Message - From: Matt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 30, 2004 11:24 AM Subject: Re: [Declude.JunkMail] Question on SPF Setup. Was under You **May** etc **May** etc Grant Griffith - Declude JM wrote: If someone sends an email and it shows up on our server as a 64. address. What about when the message is delivered to someone at AOL? Will it also see the 64. address, therefore fail the SPF test on their end also? Sorry to butt in on this one...Yes, SPF would fail on other systems as well in that situation. As far as I can tell, SPF-PASS is not useful because there is nothing stopping a spammer that owns a server to set SPF up for it. Setting up SPF for your domain is also IMO a bad idea unless you can guarantee that all of your users will only come from certain IP's when they send E-mail. For instance, although I prefer to be the outgoing SMTP server for my clients, some of them are either blocked by their ISP from sending E-mail through my server (port 25 blocking), or they just simply chose to set up their computers to use their ISP's mail server instead of our own. Therefore, I don't have a single client that I can guarantee that they will be coming from a particular range of IP's. While some people around here might only add a few points for such a failure, some have said that they will automatically hold any such messages that fail and I'm sure that there are people out there that will delete on such failures. You can set up SPF for you domain that states that the domain can be used from any IP, however I don't see any value in stating that something can come from anywhere when that in effect is the status quo. SPF is an interesting idea, but they're missing a step or two that would really make it useful IMO. The SPF folks recently agreed to merge their spec with Microsoft's and that might produce a more accurate test, but I haven't been following developments closely and can't say for sure. Practically speaking, it's the openness of E-mail and the fact that it was never designed or implemented to prevent spoofing that is the cause of this problem, and the best way to get at the issue might be to simply re-write SMTP to allow for authentication of non-local E-mail. I'm sure that Scott, Sandy and others have a different perspective. They are both fans of SPF and I am not. Who knows, maybe it is me that is missing something. I won't implement SPF on my domains at this time because of the possibility of some other admin blocking their E-mail in that 1% that doesn't come through my server, and to list them as non-specific to address space caries no apparent value. Matt -- = MailPure custom filters for Declude JunkMail Pro. http://www.mailpure.com/software/ = --- [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. --- [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.
