Re: [Declude.JunkMail] SPF support to be added to next beta
Scott, I've been looking over this trying to figure out how to best implement it for my domains. It seems that since they are all on one class C, I should do the following: v=spf1 +a/24 +mx/24 -all Now three very important questions... 1) If I implement this, will intra-server E-mail fail this test? i.e. local mail customer at client IP 123.123.123.123 E-mail's me, where 123.123.123.123 is not a local address, but the address of the border router at the client's location. 2) When my clients who are SMTP blocked by their ISP (port 25), and forced to use their ISP's mail server, am I correct in assuming that this will fail? 3) If the answer is yes to either one of these, does this make more sense to implement against HELO instead of MAILFROM? This would seem to be more problematic than SPAMDOMAINS if it operates on MAILFROM, even if local domains could be excluded. Naturally, I might not be understanding this fully. If I changed the test to +all in order to prevent these issues (if real), then it seems that it would only be useful as a negative weight test when my data is used. Thanks, Matt R. Scott Perry wrote: We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- [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] SPF support to be added to next beta
Matt: That is the conclusion that I have reached .. Our employees who check messages at home with ISP's blocking SMTP - will naturally fail this. Also I am still trying to figure out web responses. Based on all that I have seen and read it appears a slight negative weight to reduce FP's is all the use I see for this test... I think a positive test will only increase our FP rate. Regards, Kami -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Bramble Sent: Friday, December 19, 2003 12:14 AM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] SPF support to be added to next beta Scott, I've been looking over this trying to figure out how to best implement it for my domains. It seems that since they are all on one class C, I should do the following: v=spf1 +a/24 +mx/24 -all Now three very important questions... 1) If I implement this, will intra-server E-mail fail this test? i.e. local mail customer at client IP 123.123.123.123 E-mail's me, where 123.123.123.123 is not a local address, but the address of the border router at the client's location. 2) When my clients who are SMTP blocked by their ISP (port 25), and forced to use their ISP's mail server, am I correct in assuming that this will fail? 3) If the answer is yes to either one of these, does this make more sense to implement against HELO instead of MAILFROM? This would seem to be more problematic than SPAMDOMAINS if it operates on MAILFROM, even if local domains could be excluded. Naturally, I might not be understanding this fully. If I changed the test to +all in order to prevent these issues (if real), then it seems that it would only be useful as a negative weight test when my data is used. Thanks, Matt R. Scott Perry wrote: We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- [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] SPF support to be added to next beta
I've been looking over this trying to figure out how to best implement it for my domains. It seems that since they are all on one class C, I should do the following: v=spf1 +a/24 +mx/24 -all Now three very important questions... 1) If I implement this, will intra-server E-mail fail this test? i.e. local mail customer at client IP 123.123.123.123 E-mail's me, where 123.123.123.123 is not a local address, but the address of the border router at the client's location. Yes. Think of it this way -- is there any way to know that 123.123.123.123 belongs to your client and not a spammer? OTOH, you could use WHITELIST AUTH to whitelist their E-mail. 2) When my clients who are SMTP blocked by their ISP (port 25), and forced to use their ISP's mail server, am I correct in assuming that this will fail? Correct. In this case, it sounds like you would instead want to use: v=spf1 +a/24 +mx/24 ?all That way, you are saying that legitimate E-mail might come from IPs other than the ones that you list. This way, neither #1 nor #2 will fail. If I changed the test to +all in order to prevent these issues (if real), then it seems that it would only be useful as a negative weight test when my data is used. +all is a very bad thing -- it says Spammers, you are welcome to forge my domain from any IP. While -all wouldn't work for you (it says that nobody from IPs you do not list can send mail from your domain), ?all would work (it says that anybody trying to send mail from your domain using an IP you do not list *may* be legitimate). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Is there a way that I can setup this test to only check incoming messages? I set up the DNS record and it will work fine except when one of my dial-up users sends an outgoing message. The test does exactly what I would like it to do. When one of my dial-up users bypasses my SMTP server, the message could be flagged as spam at the receiving end using an SPF test. However, if the user is sending mail correctly, through my SMTP server, the test flags there dial-up IP as an invalid SMTP server! I would like to turn off this test for outgoing messages while still doing other spam testing on outgoing messages. Is there some way to do this? Here is an example: Received: from wamgfk19jmdhqi [63.252.12.191] by wamusa.com with ESMTP (SMTPD32-8.04) id A5ECDE20074; Fri, 19 Dec 2003 12:39:40 -0600 From: Bill Morgan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: test Date: Fri, 19 Dec 2003 12:39:40 -0600 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Declude-Sender: [EMAIL PROTECTED] [63.252.12.191] X-Spam-Tests-Failed: SPFFAIL [1] X-Note: This E-mail was sent from 63-252-12-191.ip.mcleodusa.net ([63.252.12.191]). X-Declude-Date: 12/19/2003 18:39:40 [0] X-RCPT-TO: [EMAIL PROTECTED] Status: U X-UIDL: 367544318 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, December 15, 2003 5:54 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] SPF support to be added to next beta We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Is there a way that I can setup this test to only check incoming messages? No (although you can set it up so that no action would be taken for outgoing mail, the weight would still be applied). In this case, WHITELIST AUTH (with works with Declude JunkMail v1.75 and higher, and IMail v8 and higher) might be the best option. Alternatively, you could use WHITELIST IP 192.0.2.0/24 to whitelist the dialup IPs, or set up a filter that would subtract weight for E-mails coming from those IPs. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Thanks. I set up my primary domains. I still have to review client domains to determine the proper setup for those that are used for emailing. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Monday, December 15, 2003 06:54 PM To: [EMAIL PROTECTED] Subject: [Declude.JunkMail] SPF support to be added to next beta We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. For those that are interested, we now have an interim release with SPF support in it. It can be downloaded from http://www.declude.com/interim (a new URL that we are going to be using for interim releases, that explains a bit more about them). To use the new SPF test, you can add lines such as: SPFPASS spf passx -5 0 SPFFAIL spf failx 8 0 to your global.cfg file. SPF returns PASS for E-mail that passes SPF (that comes from an IP that is acceptable to the owner of the domani that it claims to be coming from), FAIL for E-mail that fails SPF (that does not come from an acceptable IP for the domain), or UNKNOWN (for E-mail from domains that do not use SPF yet, or for some other reason should return UNKNOWN). This will help reduce false positives (for domains that have SPF support), and help capture more spam (as spam comes in from domains that have SPF support, but the spammer isn't using an acceptable IP). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Any chance we can seperate fail unknown into two different tests? via spf we have ?all or -all which are supposed to be treated differently from what I understand. I would rather seriously penalize any domain that is configured with a -all and the sending IP is fails and would NOT want to penazlize unconfigured or ?all transitional domains. Ideally I would like something like this: SPFPASS spf pass x -5 0 SPFUNKN spf unknown x 4 0 SPFFAIL spf fail x 8 0 -Original Message- From: R. Scott Perry [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 1:34 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] SPF support to be added to next beta We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. For those that are interested, we now have an interim release with SPF support in it. It can be downloaded from http://www.declude.com/interim (a new URL that we are going to be using for interim releases, that explains a bit more about them). To use the new SPF test, you can add lines such as: SPFPASS spf passx -5 0 SPFFAIL spf failx 8 0 to your global.cfg file. SPF returns PASS for E-mail that passes SPF (that comes from an IP that is acceptable to the owner of the domani that it claims to be coming from), FAIL for E-mail that fails SPF (that does not come from an acceptable IP for the domain), or UNKNOWN (for E-mail from domains that do not use SPF yet, or for some other reason should return UNKNOWN). This will help reduce false positives (for domains that have SPF support), and help capture more spam (as spam comes in from domains that have SPF support, but the spammer isn't using an acceptable IP). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Any chance we can seperate fail unknown into two different tests? via spf we have ?all or -all which are supposed to be treated differently from what I understand. They are treated differently. An SPF lookup can result in PASS, FAIL, or UNKNOWN. So: Ideally I would like something like this: SPFPASS spf pass x -5 0 SPFUNKN spf unknown x 4 0 SPFFAIL spf fail x 8 0 This will work fine. At this time, though, I would not recommend penalizing for the UNKNOWN response, as most domains do not yet have an SPF record. However, we plan to soon add a way of letting you force SPF records for domains that don't have them, as well as having a default SPF record. This would allow the UNKNOWN result to be more useful. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Gotcha, all 3 are already setup :) I don't really want to penalize for unknown, was just making an example. ( I just setup spf on my postfix box yesterday as well to help get past some restrictions for pass) Sounds like you are setting the the spf-guess (which defaults to mx/24 a/24 right?) -Original Message- From: R. Scott Perry [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 2:30 PM To: [EMAIL PROTECTED] Subject: RE: [Declude.JunkMail] SPF support to be added to next beta Any chance we can seperate fail unknown into two different tests? via spf we have ?all or -all which are supposed to be treated differently from what I understand. They are treated differently. An SPF lookup can result in PASS, FAIL, or UNKNOWN. So: Ideally I would like something like this: SPFPASS spf pass x -5 0 SPFUNKN spf unknown x 4 0 SPFFAIL spf fail x 8 0 This will work fine. At this time, though, I would not recommend penalizing for the UNKNOWN response, as most domains do not yet have an SPF record. However, we plan to soon add a way of letting you force SPF records for domains that don't have them, as well as having a default SPF record. This would allow the UNKNOWN result to be more useful. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Hi Scott: A) Is there an %SPFSTATUS% variable for use in the headers (that will show FAIL/PASS/UNKNOWN)? B) If not, is there a generic SPF test in the global.cfg, so that I can use one line to create a WARN action e.g. SPF spf * x x x Best Regards Andy Schmidt HM Systems Software, Inc. 600 East Crescent Avenue, Suite 203 Upper Saddle River, NJ 07458-1846 Phone: +1 201 934-3414 x20 (Business) Fax:+1 201 934-9206 http://www.HM-Software.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of R. Scott Perry Sent: Thursday, December 18, 2003 02:34 PM To: [EMAIL PROTECTED] Subject: Re: [Declude.JunkMail] SPF support to be added to next beta We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. For those that are interested, we now have an interim release with SPF support in it. It can be downloaded from http://www.declude.com/interim (a new URL that we are going to be using for interim releases, that explains a bit more about them). To use the new SPF test, you can add lines such as: SPFPASS spf passx -5 0 SPFFAIL spf failx 8 0 to your global.cfg file. SPF returns PASS for E-mail that passes SPF (that comes from an IP that is acceptable to the owner of the domani that it claims to be coming from), FAIL for E-mail that fails SPF (that does not come from an acceptable IP for the domain), or UNKNOWN (for E-mail from domains that do not use SPF yet, or for some other reason should return UNKNOWN). This will help reduce false positives (for domains that have SPF support), and help capture more spam (as spam comes in from domains that have SPF support, but the spammer isn't using an acceptable IP). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Wow, seeing positive results already! Thanks Scott for getting this implemented so quickly! Guess I will need to setup my SPF records now. I've some questions: Our situation here is, that we host mailservices for several customers. We have also our own DNS servers and so we're able to set up SPF TXT records. But as I understand we can't set up silently this records for all our domains because we can't be sure that all of our clients send all their outgoing (legit) mail traffic trough our Mailserver. (that we've authorized in the SPF records) For example if there is on customer side an Exchange Admin that has set up his server to make MX lookups and route outgoing SMTP traffic directly to the recipients server. I know it's risky to do this from a dynamic IP or without REVDNS-entry ..., but this is not under our control. So as I can understand we have to parse trough our smtp-logfiles to find out which customer send his outgoing mail trough our server. Then we can add SPF records only for this domains. Otherwise we risk to penalize our customers outgoing mail traffic if it's not send trough our server and the destination makes also SPF lookups. Right or do I miss something? Markus --- [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] SPF support to be added to next beta
Our situation here is, that we host mailservices for several customers. We have also our own DNS servers and so we're able to set up SPF TXT records. But as I understand we can't set up silently this records for all our domains because we can't be sure that all of our clients send all their outgoing (legit) mail traffic trough our Mailserver. (that we've authorized in the SPF records) What you can do in this case is something like v=spf1 +mx ?all. This will give a PASS response to anyone sending mail from the domain(s) you add the SPF record for, if they are coming from an IP in their MX record. Otherwise, an UNKNOWN result will be returned (the same thing that they would get if you did not have an SPF record). This will provide positive benefits, without having any negative benefits. If you know a domain will only be sending mail through your mailservers, you can instead use -all at the end (which gives a FAIL result for E-mail sent from other IPs). -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
A) Is there an %SPFSTATUS% variable for use in the headers (that will show FAIL/PASS/UNKNOWN)? No. But we will look into this. B) If not, is there a generic SPF test in the global.cfg, so that I can use one line to create a WARN action e.g. SPF spf * x x x I don't think this would be useful, as it wouldn't know whether the E-mail passed or failed the test (or returned an UNKNOWN result). Instead, you could use: SPFPASS WARNX-Note: This E-mail passed SPF SPFFAIL WARNX-Note: This E-mail failed SPF -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
This will provide positive benefits, without having any negative benefits. If you know a domain will only be sending mail through your mailservers, you can instead use -all at the end (which gives a FAIL result for E-mail sent from other IPs). Ok, thank you for this information. But I have to know in any case of all the domains that send out legit messages trough our server. Is there any way to gather this information from already present logfiles (smtp, declude jm, ...) ? If not: Would it be possible to have something like LOGSPFINFO ON that can be enabled temporary for some days to write one line for every outgoing message. (eventually also in a separate logfile) Then we can uniq and sort this list and know about all domains where we can add safely the SPF TXT records. Markus --- [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] SPF support to be added to next beta
But I have to know in any case of all the domains that send out legit messages trough our server. No, you do not. You can simply add the v=spf1 +mx ?all to all your domains. However, if you want to take the time to find ones that only send through your server, you can change them from v=spf1 +mx ?all to v=spf1 +mx -all. If not: Would it be possible to have something like LOGSPFINFO ON that can be enabled temporary for some days to write one line for every outgoing message. (eventually also in a separate logfile) With the current interim release, a C:\spf.log will be recorded for domains with SPF entries, and C:\spf.none for domains without SPF entries. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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] SPF support to be added to next beta
Scott, Great idea! This is the kind of idea I was hoping for. Certainly it can be spoofed until all mailservers utilize this test, but it can at least add to negative weighting in the meantime...except for the trojan issue, of course. Darin. - Original Message - From: R. Scott Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 15, 2003 6:54 PM Subject: [Declude.JunkMail] SPF support to be added to next beta We will be adding support for SPF (Sender Permitted From, at http://spf.pobox.com ) to the next beta of Declude JunkMail. This is a system that lets owners of domains publish information on what mailservers people can use to send mail from the domain. We expect that this can be very useful in blocking spam (similar to the SPAMDOMAINS test), as well as helping ensure that legitimate mail gets through. http://spf.pobox.com/dns.html covers how to add an SPF record for your own domain. At its simplest, if all your E-mail is coming from your mailserver, and your mailserver is listed in your MX record, you would add a TXT record of v=spf1 +mx -all for your domain. The SPF records always start with v=spf1; the +mx means that any E-mail from an IP listed in your MX records is good, and the -all is a default so that any other E-mail is bad. The SPF system is much, much more flexible than the SPAMDOMAINS test, and it lets domain owners control the settings (which allows them to be much more accurate). If widely implemented, it will make it much more difficult for spammers to get their spam delivered. -Scott --- Declude JunkMail: The advanced anti-spam solution for IMail mailservers. Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection. Find out what you've been missing: Ask about our 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 virus scanned by 4C Web] --- [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.
