I've been reading about this but don't see if it would help with a problem we have sometimes. When sending some mail to several recipients externally, particularly when sending it as a result of a mail merge, it'll often end up in the recipients' spam folders. These are normal business communications, not spam, obviously.
IMO it's well worth creating an SPF record for your domain. Depending on the configuration of the recipient domain, this can definitely help prevent your outgoing messages being marked as spam by the recipient. MS (and others) have wizards that will tell you how to configure the record, which you then just add to the DNS settings for your domain. The MS one is at http://www.microsoft.com/mscorp/safety/content/technologies/senderid/....
FYI, I have greatly reduced incoming spam by configuring Exchange to consider the Sender ID info when calculating SCL. I'm not rejecting any messages based on Sender ID alone, but if a message fails Sender ID, that raises the SCL, so more messages are getting rejected. Over the past several months, this seems to have decreased spam considerably, without any reports of false positives.
> I've been reading about this but don't see if it would help with a problem > we have sometimes. When sending some mail to several recipients > externally, particularly when sending it as a result of a mail merge, > it'll often end up in the recipients' spam folders. These are normal > business communications, not spam, obviously.
Milhouse Van Houten wrote: >I've been reading about this but don't see if it would help with a problem >we have sometimes. When sending some mail to several recipients >externally, particularly when sending it as a result of a mail merge, >it'll often end up in the recipients' spam folders. These are normal >business communications, not spam, obviously.
Sender ID protects you against domain spoofing.
Unless you can get additional information from the recipients as to why your emails are being identified as spam, you're unlikely to make any significant progress in preventing it from happening.
-- Steve Foster ------------ Please reply only to the newsgroups. For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net
Although I agree that reducing false-positives usually is best done with the cooperation of the recipient, creating a SenderID record in DNS can certainly reduce false positives. It isn't *just* to protect against domain spoofing.
SpamAssassin, for example, will not raise a message's spam-score if no SenderID/SPF record is found, but if one is found and is valid, SpamAssassin will actually reduce the spam-score....in other words a valid SPF record makes it less likely that the message is spammy. MAny other engines operate similarly, so a valid SPF record can make all the difference between a message going into quarantine/junk/possibly-but-not-definitely-spam and actually being scored as legitimate mail.
As Dave said, it certainly won't hurt.
-Cliff
"Steve Foster" <steve.fos...@picamar.co.uk> wrote in message
>>I've been reading about this but don't see if it would help with a problem >>we have sometimes. When sending some mail to several recipients >>externally, particularly when sending it as a result of a mail merge, >>it'll often end up in the recipients' spam folders. These are normal >>business communications, not spam, obviously.
> Sender ID protects you against domain spoofing.
> Unless you can get additional information from the recipients as to why > your emails are being identified as spam, you're unlikely to make any > significant progress in preventing it from happening.
> -- > Steve Foster > ------------ > Please reply only to the newsgroups. > For SSL Certificates, Domains, etc, visit.: > https://netshop.virtual-isp.net
> Although I agree that reducing false-positives usually is best done with > the cooperation of the recipient, creating a SenderID record in DNS can > certainly reduce false positives. It isn't *just* to protect against > domain spoofing.
> SpamAssassin, for example, will not raise a message's spam-score if no > SenderID/SPF record is found, but if one is found and is valid, > SpamAssassin will actually reduce the spam-score....in other words a valid > SPF record makes it less likely that the message is spammy. MAny other > engines operate similarly, so a valid SPF record can make all the > difference between a message going into > quarantine/junk/possibly-but-not-definitely-spam and actually being scored > as legitimate mail.
> As Dave said, it certainly won't hurt.
> -Cliff
Just to add, it also helps with false NDRs, which of course falls under what you mentioned, domain spoofing.
Cliff Galiher wrote: >Although I agree that reducing false-positives usually is best done with >the cooperation of the recipient, creating a SenderID record in DNS can >certainly reduce false positives. It isn't just to protect against domain >spoofing.
In practical terms, yes, it is. It says nothing about the spamminess of the message.
My point about working with external recipients is that he's not going to know what aspects of his mail configuration to work on (assuming the basics are properly implremented anyway) without their help (ie they're the ones dumping his messages - they're the ones who know why).
>SpamAssassin, for example, will not raise a message's spam-score if no >SenderID/SPF record is found, but if one is found and is valid, >SpamAssassin will actually reduce the spam-score....in other words a valid >SPF record makes it less likely that the message is spammy. MAny other >engines operate similarly, so a valid SPF record can make all the >difference between a message going into >quarantine/junk/possibly-but-not-definitely-spam and actually being scored >as legitimate mail.
That strikes me as rather perverse, since it's trivial for spammers to implement SPF records (it just means they have to expend fractionally more effort). I certainly wouldn't expect a message to score as less spam-like just because there's an SPF record (it's not that sort of measure).
-- Steve Foster ------------ Please reply only to the newsgroups. For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net
Well we are getting off topic here, but here is where I disagree (and why spam products work the way they do.)
Can a spammer set up a SenderID DNS record? If they own the server, sure. But if they *own* the server then a true spam-generating server gets blacklisted by RBL services so this becomes a non-issue. A message will get marked as spam regardless of its SenderID record.
Most spam, however, is generated incorrectly configured open-relay servers and/or botnets from infected clients. In both cases the spammer CANNOT create a SenderID record. If a company has a server misconfigured as an open-relay then they have a sysadmin who is very inattentive. An inattentive sysadmin isn't going to take the time to set up a SenderID record, but they do still control their DNS (or have it hosted so they control it indirectly) so either way the spammer can't go adding SenderID records to inappropriately improve spam scores. Is it *possible* that a SenderID record exists on a server that is an open-relay? Sure. But I'm contending that it isn't likely. After all, any sysadmin going through the playbook o reduce spam is going to run a basic open-relay test (there are plenty of free ones) well before they stumble onto the SenderID/SPF tests.
In the latter, the DNS records for residential ISP blocks are owned by the ISP, so again you have a situation where a botnet that is spamming will not have a legitimate SenderID record and the spammers cannot add one because they don't control the DNS settings for the machines they are abusing to send spam.
So taken as a whole, and looking at the latest statistics and industry reports on how spam is sent, SenderID is actually a very reliable metric on determining the "spamminess" of a message.
-Cliff
"Steve Foster" <steve.fos...@picamar.co.uk> wrote in message
>>Although I agree that reducing false-positives usually is best done with >>the cooperation of the recipient, creating a SenderID record in DNS can >>certainly reduce false positives. It isn't just to protect against domain >>spoofing.
> In practical terms, yes, it is. It says nothing about the spamminess of > the message.
> My point about working with external recipients is that he's not going to > know what aspects of his mail configuration to work on (assuming the > basics are properly implremented anyway) without their help (ie they're > the ones dumping his messages - they're the ones who know why).
>>SpamAssassin, for example, will not raise a message's spam-score if no >>SenderID/SPF record is found, but if one is found and is valid, >>SpamAssassin will actually reduce the spam-score....in other words a valid >>SPF record makes it less likely that the message is spammy. MAny other >>engines operate similarly, so a valid SPF record can make all the >>difference between a message going into >>quarantine/junk/possibly-but-not-definitely-spam and actually being scored >>as legitimate mail.
> That strikes me as rather perverse, since it's trivial for spammers to > implement SPF records (it just means they have to expend fractionally more > effort). I certainly wouldn't expect a message to score as less spam-like > just because there's an SPF record (it's not that sort of measure).
> -- > Steve Foster > ------------ > Please reply only to the newsgroups. > For SSL Certificates, Domains, etc, visit.: > https://netshop.virtual-isp.net
Cliff Galiher wrote: >Well we are getting off topic here, but here is where I disagree (and why >spam products work the way they do.)
>Can a spammer set up a SenderID DNS record? If they own the server, sure. >But if they own the server then a true spam-generating server gets >blacklisted by RBL services so this becomes a non-issue. A message will >get marked as spam regardless of its SenderID record.
You do not need to own a server to set up Sender ID, just a domain.
>Most spam, however, is generated incorrectly configured open-relay servers >and/or botnets from infected clients. In both cases the spammer CANNOT >create a SenderID record.
Tripe. Spammers can create Sender ID records for any domain they control.
>If a company has a server misconfigured as an open-relay then they have a >sysadmin who is very inattentive. An inattentive sysadmin isn't going to >take the time to set up a SenderID record, but they do still control their >DNS (or have it hosted so they control it indirectly) so either way the >spammer can't go adding SenderID records to inappropriately improve spam >scores. Is it possible that a SenderID record exists on a server that is >an open-relay? Sure. But I'm contending that it isn't likely. After >all, any sysadmin going through the playbook o reduce spam is going to run >a basic open-relay test (there are plenty of free ones) well before they >stumble onto the SenderID/SPF tests.
Sender ID records don't exist "on" servers, they exist on domains. The simplest option for a spammer would be to declare "my list of authorised mail servers is the entire internet" (eg "spf2.0/pra +all"). Similarly, they can easily set up an SPF record ("v=spf1 +all").
>In the latter, the DNS records for residential ISP blocks are owned by the >ISP, so again you have a situation where a botnet that is spamming will >not have a legitimate SenderID record and the spammers cannot add one >because they don't control the DNS settings for the machines they are >abusing to send spam.
If the bad guys are sending from domains they don't control, then yes, they cannot set up Sender ID (or SPF) for those domains. But the fact that the IP blocks of the machines they're using may belong to residential grade ISPs is irrelevant.
>So taken as a whole, and looking at the latest statistics and industry >reports on how spam is sent, SenderID is actually a very reliable metric >on determining the "spamminess" of a message.
No, this is syllogism.
-- Steve Foster ------------ Please reply only to the newsgroups. For SSL Certificates, Domains, etc, visit.: https://netshop.virtual-isp.net
While we're still waiting on getting our DNS updated for SPF, I did enable Sender ID for the purposes you mention. However, we now get several annoying 7519 errors in the application log per day, where we never got them before: http://eventid.net/display.asp?eventid=7519&eventno=7958&source=MSExc...
Invariably they are triggered by a minority (less than 5%) of internally generated SMTP-sent email from things like Sharepoint and SBS itself, etc., never anything from a person (I.e. an Exchange account). It happens on mail sent to an internal address as well as to an external one. I've added both the lone server IP and 127.0.0.1 into Message Delivery Properties/General, and have examined the headers of the problem emails for any other clues. I even got desperate and added the external IP to that list, but it had no effect. I do see other threads about this but don't see a solution short of disabling Sender ID on the SMTP virtual server. Do you get them too?
> IMO it's well worth creating an SPF record for your domain. Depending on > the configuration of the recipient domain, this can definitely help > prevent your outgoing messages being marked as spam by the recipient. MS > (and others) have wizards that will tell you how to configure the record, > which you then just add to the DNS settings for your domain. The MS one > is at > http://www.microsoft.com/mscorp/safety/content/technologies/senderid/....
> FYI, I have greatly reduced incoming spam by configuring Exchange to > consider the Sender ID info when calculating SCL. I'm not rejecting any > messages based on Sender ID alone, but if a message fails Sender ID, that > raises the SCL, so more messages are getting rejected. Over the past > several months, this seems to have decreased spam considerably, without > any reports of false positives.
>>Well we are getting off topic here, but here is where I disagree (and why >>spam products work the way they do.)
>>Can a spammer set up a SenderID DNS record? If they own the server, sure. >>But if they own the server then a true spam-generating server gets >>blacklisted by RBL services so this becomes a non-issue. A message will >>get marked as spam regardless of its SenderID record.
> You do not need to own a server to set up Sender ID, just a domain.
>>Most spam, however, is generated incorrectly configured open-relay servers >>and/or botnets from infected clients. In both cases the spammer CANNOT >>create a SenderID record.
> Tripe. Spammers can create Sender ID records for any domain they control.
Why would a spammer purchase and use a domain for spamming? Their sending server will constantly get blacklisted. Most "true" spammers use virus turned zombie machines to do their bidding.
>>If a company has a server misconfigured as an open-relay then they have a >>sysadmin who is very inattentive. An inattentive sysadmin isn't going to >>take the time to set up a SenderID record, but they do still control their >>DNS (or have it hosted so they control it indirectly) so either way the >>spammer can't go adding SenderID records to inappropriately improve spam >>scores. Is it possible that a SenderID record exists on a server that is >>an open-relay? Sure. But I'm contending that it isn't likely. After >>all, any sysadmin going through the playbook o reduce spam is going to run >>a basic open-relay test (there are plenty of free ones) well before they >>stumble onto the SenderID/SPF tests.
> Sender ID records don't exist "on" servers, they exist on domains. The > simplest option for a spammer would be to declare "my list of authorised > mail servers is the entire internet" (eg "spf2.0/pra +all"). Similarly, > they can easily set up an SPF record ("v=spf1 +all").
I can't see why they would want to use their own domain name to spam thousands of messages. Whether or not the SPF shows all machines in the world are authorized for their domain, they would be traceable with a whois, etc.
>>In the latter, the DNS records for residential ISP blocks are owned by the >>ISP, so again you have a situation where a botnet that is spamming will >>not have a legitimate SenderID record and the spammers cannot add one >>because they don't control the DNS settings for the machines they are >>abusing to send spam.
> If the bad guys are sending from domains they don't control, then yes, > they cannot set up Sender ID (or SPF) for those domains. But the fact that > the IP blocks of the machines they're using may belong to residential > grade ISPs is irrelevant.
But they are sending from domain names they don't own by the use of virus mass-mailer infected workstations. One way to control this in case of an outbreak (of course having antivirus and other means in place), is to block all outbound 25 other than the mail server itself.
>>So taken as a whole, and looking at the latest statistics and industry >>reports on how spam is sent, SenderID is actually a very reliable metric >>on determining the "spamminess" of a message.
> No, this is syllogism.
That depends on what the infering conclusion was based on. SenderID is a good practice, but is only part of the whole solution.
And I'm curious, if you are aware of any spammers that use their own resources to send out their junk, and I'm not referring to legit list mailers and other 'newsletters' mailers, please let us know.
Just to chime in here (I'm enjoying the thread), in the last hour we finally got the SPF record set correctly, and I can actually say specifically what happens with the SpamAssassin score because I emailed the handy "check-a...@verifier.port25.com" alias both before and after. It accounts for -1.2 points, interestingly not showing up in the SPF_PASS category but rather the AWL one. Note that I sent the first one with a blank body and subject so had no choice but to do the same for the second. When I do a more realistic test including a body and subject, the score drops to 2.1 and it's "ham" and not "spam" (I'm assuming it would have been 3.3 before SPF).
Result: spam (6.6 points, 5.0 required)
pts rule name description ---- ---------------------- -------------------------------------------------- -0.2 BAYES_40 BODY: Bayesian spam probability is 20 to 40% [score: 0.2104] 0.0 HTML_MESSAGE BODY: HTML included in message 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO 1.4 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 1.8 MISSING_SUBJECT Missing Subject: header 1.4 EMPTY_MESSAGE Message appears to have no textual parts and no Subject: text
Result: spam (5.4 points, 5.0 required)
pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message 2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO 1.4 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 1.8 MISSING_SUBJECT Missing Subject: header 1.4 EMPTY_MESSAGE Message appears to have no textual parts and no Subject: text 1.2 AWL AWL: From: address is in the auto white-list
"Steve Foster" <steve.fos...@picamar.co.uk> wrote in message
>>SpamAssassin, for example, will not raise a message's spam-score if no >>SenderID/SPF record is found, but if one is found and is valid, >>SpamAssassin will actually reduce the spam-score....in other words a valid >>SPF record makes it less likely that the message is spammy. MAny other >>engines operate similarly, so a valid SPF record can make all the >>difference between a message going into >>quarantine/junk/possibly-but-not-definitely-spam and actually being scored >>as legitimate mail.
> That strikes me as rather perverse, since it's trivial for spammers to > implement SPF records (it just means they have to expend fractionally more > effort). I certainly wouldn't expect a message to score as less spam-like > just because there's an SPF record (it's not that sort of measure).
Yes, I get them too. I could probably figure out what's causing them by using message tracking or something like that - I know it's ShadowProtect or something else that sends me status e-mails from one of the servers. I put about an hour or two into trying to figure this out, and now I just ignore them.
I wonder if it's something sending mail through server.domain.local rather than using the IP of the SBS - seems like SPF wouldn't be able to figure out domain.local.
> While we're still waiting on getting our DNS updated for SPF, I did enable > Sender ID for the purposes you mention. However, we now get several > annoying 7519 errors in the application log per day, where we never got > them before: > http://eventid.net/display.asp?eventid=7519&eventno=7958&source=MSExc...
> Invariably they are triggered by a minority (less than 5%) of internally > generated SMTP-sent email from things like Sharepoint and SBS itself, > etc., never anything from a person (I.e. an Exchange account). It happens > on mail sent to an internal address as well as to an external one. I've > added both the lone server IP and 127.0.0.1 into Message Delivery > Properties/General, and have examined the headers of the problem emails > for any other clues. I even got desperate and added the external IP to > that list, but it had no effect. I do see other threads about this but > don't see a solution short of disabling Sender ID on the SMTP virtual > server. Do you get them too?
> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in > message news:Ow9Ha7WXKHA.4704@TK2MSFTNGP02.phx.gbl... >> IMO it's well worth creating an SPF record for your domain. Depending on >> the configuration of the recipient domain, this can definitely help >> prevent your outgoing messages being marked as spam by the recipient. MS >> (and others) have wizards that will tell you how to configure the record, >> which you then just add to the DNS settings for your domain. The MS one >> is at >> http://www.microsoft.com/mscorp/safety/content/technologies/senderid/....
>> FYI, I have greatly reduced incoming spam by configuring Exchange to >> consider the Sender ID info when calculating SCL. I'm not rejecting any >> messages based on Sender ID alone, but if a message fails Sender ID, that >> raises the SCL, so more messages are getting rejected. Over the past >> several months, this seems to have decreased spam considerably, without >> any reports of false positives.
Even if spammers were registering domain names, I doubt they'd bother to configure the SPF records. Regardless, one thing I know is that since I started having the IMF consider the SPF status, I've stopped just about all of the messages purporting to be from my own domain. I've seen a huge reduction in incoming spam since configuring this.
Steve, I'm betting all your domains have proper SPF records, right : -)
Milhouse, good info about the Spam Assassin score. Thanks.
"Steve Foster" <steve.fos...@picamar.co.uk> wrote in message
>>Well we are getting off topic here, but here is where I disagree (and why >>spam products work the way they do.)
>>Can a spammer set up a SenderID DNS record? If they own the server, sure. >>But if they own the server then a true spam-generating server gets >>blacklisted by RBL services so this becomes a non-issue. A message will >>get marked as spam regardless of its SenderID record.
> You do not need to own a server to set up Sender ID, just a domain.
>>Most spam, however, is generated incorrectly configured open-relay servers >>and/or botnets from infected clients. In both cases the spammer CANNOT >>create a SenderID record.
> Tripe. Spammers can create Sender ID records for any domain they control.
>>If a company has a server misconfigured as an open-relay then they have a >>sysadmin who is very inattentive. An inattentive sysadmin isn't going to >>take the time to set up a SenderID record, but they do still control their >>DNS (or have it hosted so they control it indirectly) so either way the >>spammer can't go adding SenderID records to inappropriately improve spam >>scores. Is it possible that a SenderID record exists on a server that is >>an open-relay? Sure. But I'm contending that it isn't likely. After >>all, any sysadmin going through the playbook o reduce spam is going to run >>a basic open-relay test (there are plenty of free ones) well before they >>stumble onto the SenderID/SPF tests.
> Sender ID records don't exist "on" servers, they exist on domains. The > simplest option for a spammer would be to declare "my list of authorised > mail servers is the entire internet" (eg "spf2.0/pra +all"). Similarly, > they can easily set up an SPF record ("v=spf1 +all").
>>In the latter, the DNS records for residential ISP blocks are owned by the >>ISP, so again you have a situation where a botnet that is spamming will >>not have a legitimate SenderID record and the spammers cannot add one >>because they don't control the DNS settings for the machines they are >>abusing to send spam.
> If the bad guys are sending from domains they don't control, then yes, > they cannot set up Sender ID (or SPF) for those domains. But the fact that > the IP blocks of the machines they're using may belong to residential > grade ISPs is irrelevant.
>>So taken as a whole, and looking at the latest statistics and industry >>reports on how spam is sent, SenderID is actually a very reliable metric >>on determining the "spamminess" of a message.
> No, this is syllogism.
> -- > Steve Foster > ------------ > Please reply only to the newsgroups. > For SSL Certificates, Domains, etc, visit.: > https://netshop.virtual-isp.net
Would that be more a reflection of the SPF record in DNS or IMF considering SPF? Did you set your record as -ALL (reject) or ~ALL (accept but mark)? I think if it's reject then messages pretending to come from your own domain would never arrive, making IMF being informed by SPF less important, but we're using the more conservative ~ALL for now.
> Even if spammers were registering domain names, I doubt they'd bother to > configure the SPF records. Regardless, one thing I know is that since I > started having the IMF consider the SPF status, I've stopped just about > all of the messages purporting to be from my own domain. I've seen a huge > reduction in incoming spam since configuring this.
> Steve, I'm betting all your domains have proper SPF records, right : -)
> Milhouse, good info about the Spam Assassin score. Thanks.
I'm so glad you get them too. I'll check to see how the sending parties are configured, whether by name or IP, though I don't know that can be the problem because it's not consistent. If the particular alerts either always triggered the problem or always didn't, it would make more sense, but the very same alerts behave differently from hour to hour.
> Yes, I get them too. I could probably figure out what's causing them by > using message tracking or something like that - I know it's ShadowProtect > or something else that sends me status e-mails from one of the servers. I > put about an hour or two into trying to figure this out, and now I just > ignore them.
> I wonder if it's something sending mail through server.domain.local rather > than using the IP of the SBS - seems like SPF wouldn't be able to figure > out domain.local.
>> Invariably they are triggered by a minority (less than 5%) of internally >> generated SMTP-sent email from things like Sharepoint and SBS itself, >> etc., never anything from a person (I.e. an Exchange account). It happens >> on mail sent to an internal address as well as to an external one. I've >> added both the lone server IP and 127.0.0.1 into Message Delivery >> Properties/General, and have examined the headers of the problem emails >> for any other clues. I even got desperate and added the external IP to >> that list, but it had no effect. I do see other threads about this but >> don't see a solution short of disabling Sender ID on the SMTP virtual >> server. Do you get them too?
Okay, obviously I need to clarify my position here.
First, yes: DNS records belong to domains. I was not thorough in my reply and a technical detail got through, but my arguments about open-relays and botnets being used as attack vectors stands. You focused on my one mistatement and used it as a bludgeon to try and disprove my underlying point.
So let me reiterate my point. SenderID protects against domain spoofing. I never said you were wrong here. My position was that it doesn't *JUST* protect against domain spoofing. It is used in spam-scoring by several products.
Now whether you agree with the logic BEHIND using SenderID for spam scoring is irrelevant. That is how the products DO work, so someone trying to reduce the appearance that their message is spam would do well to create a SenderID record for their domain. Pure and simple.
-----Off topic begins here-----
Now, I've also made it clear I agree with the idea behind using SenderID as a metric for determinig spamminess. Here is why. If a message passes a SenderID check then that means the domain owner *probably* approves of the message coming from their domain. ...obviously an open-relay server that happens to belong to a domain with a SenderID record pointing to that server could allow spammers to spoof that domain, but that is a pretty big edge case for the reasons I've pointed out previously.
So implementing SenderID forces spammers, by and large, to use domains they own. How is that not *just* domain spoofing protection? Because SenderID doesn't stand alone as a preventative measure. It gets coupled with other technologies and filters. If a domain has a legit SenderID record...even if that record is every IP in existence...and it is sending spam, then it gets added to various blacklist filters (not all operate on IP after all) and *poof*, the reduced score from the SenderID record is more than compensated for by the blacklist. So SenderID is part of a larger overall solution.
To use an analogy, one of my jobs in my younger days was checking IDs at a local pub. There were four basic scenarios:
1) The person who had a fake ID. Analogous to spoofing a domain. SenderID stops this, and most states have implemented security measures to prevent fake IDs.
2) The person who says they forgot their ID. This is similar to receiving an email that, when the headers are analyzed, the from address is checked, and all is said and done, has NO SenderID record. If the person looked 50, chances are I'd let them in even without their ID. After all, the chances of a Benjamin Buttons trying to sneak into my bar are nil. If they look 20, things get iffy. I'm not going to "trust" that the person is of age simply because they tell me they are. The lack of any (Sender)ID is a negative mark.
3) They have an ID that passes the blacklight test, barcode scan, etc. Even if they look 18 (and the older I got, the harder it was for me to tell the difference between 18 and 21...they all look the same) then I had no reason to stop them from coming in. The presence of an ID helped validate their age and thus increased my trust.
4) The "questionable ID" scenario. Bear with me on this one, because he analogy does hold up. Every few years, some college kid would figure out how to replicate the security measures on some state ID and the pub would get a police notice on what the IDs looked like with some discretionary caution to ask for a second form of ID, etc. If a kid showed up with the an ID that had made "the list", I wouldn't let them in. The ID was appeared legitimate, passed all security measures, and so on. But it was on a blacklist. See the analogy there? An ID alone engenders more trust, but coupled with another filter, actually DECREASED trust because it failed a very important test....one that could not exist in isolation. If a spammer registers a domain, creates a SenderID record that includes IP addresses from open-relay servers or residential IP blocks, and then proceeds to spam, that spam could get blocked by other filters. Whether that filter is one that says the domain-name is owned by a known spammer, a list that says the server is a known open-relay, or that the IP belongs to a known block of residential IPs...all of that *becomes* relevant in the evaluation.
Hell, it probably isn't far fetched to say that any SenderID record that declares a /16 block of IPs or larger is too generic to be trusted. It'd be trivial to add that logic to a spam filter (and probably would be if that type of abuse started surfacing) so the SenderID record itself becomes a detriment instead of an asset. That is the great thing about using SenderID as a scoring metric for judging spam, is that it, along with other methods, beings to paint the spammers into a corner and thus makes the spam problem more manageable.
So can SenderID be used to judged spamminess? I still say yes.
-Cliff
"Steve Foster" <steve.fos...@picamar.co.uk> wrote in message
>>Well we are getting off topic here, but here is where I disagree (and why >>spam products work the way they do.)
>>Can a spammer set up a SenderID DNS record? If they own the server, sure. >>But if they own the server then a true spam-generating server gets >>blacklisted by RBL services so this becomes a non-issue. A message will >>get marked as spam regardless of its SenderID record.
> You do not need to own a server to set up Sender ID, just a domain.
>>Most spam, however, is generated incorrectly configured open-relay servers >>and/or botnets from infected clients. In both cases the spammer CANNOT >>create a SenderID record.
> Tripe. Spammers can create Sender ID records for any domain they control.
>>If a company has a server misconfigured as an open-relay then they have a >>sysadmin who is very inattentive. An inattentive sysadmin isn't going to >>take the time to set up a SenderID record, but they do still control their >>DNS (or have it hosted so they control it indirectly) so either way the >>spammer can't go adding SenderID records to inappropriately improve spam >>scores. Is it possible that a SenderID record exists on a server that is >>an open-relay? Sure. But I'm contending that it isn't likely. After >>all, any sysadmin going through the playbook o reduce spam is going to run >>a basic open-relay test (there are plenty of free ones) well before they >>stumble onto the SenderID/SPF tests.
> Sender ID records don't exist "on" servers, they exist on domains. The > simplest option for a spammer would be to declare "my list of authorised > mail servers is the entire internet" (eg "spf2.0/pra +all"). Similarly, > they can easily set up an SPF record ("v=spf1 +all").
>>In the latter, the DNS records for residential ISP blocks are owned by the >>ISP, so again you have a situation where a botnet that is spamming will >>not have a legitimate SenderID record and the spammers cannot add one >>because they don't control the DNS settings for the machines they are >>abusing to send spam.
> If the bad guys are sending from domains they don't control, then yes, > they cannot set up Sender ID (or SPF) for those domains. But the fact that > the IP blocks of the machines they're using may belong to residential > grade ISPs is irrelevant.
>>So taken as a whole, and looking at the latest statistics and industry >>reports on how spam is sent, SenderID is actually a very reliable metric >>on determining the "spamminess" of a message.
> No, this is syllogism.
> -- > Steve Foster > ------------ > Please reply only to the newsgroups. > For SSL Certificates, Domains, etc, visit.: > https://netshop.virtual-isp.net
I'm using -all, but I don't think most recipients are outright rejecting messages that fail sender ID. For example, I have Sender ID set to "Accept (the Sender ID status will be attached to the message for further anti-spam processing)." So if someone sends me a message spoofed to say it's from me, the Sender ID will fail, and that info gets passed along to the IMF. So what I'm thinking is that messages that previously would have ended up in the Junk Mail folder are now getting a higher SCL due to Sender ID, passing the IMF threshold to reject rather than send to Junk.
I'm not comfortable deleting or rejecting messages based solely on Sender ID. We have a lot of clients who send e-mail from small ISP's, or from their own mail servers, who may have missing or incorrect SPF records. I don't want to act negatively on legitimate messages, due to a configuration that's probably outside the sender's control. Also, I think there may be DNS providers that don't even accommodate SPF records at all.
> Would that be more a reflection of the SPF record in DNS or IMF > considering SPF? Did you set your record as -ALL (reject) or ~ALL (accept > but mark)? I think if it's reject then messages pretending to come from > your own domain would never arrive, making IMF being informed by SPF less > important, but we're using the more conservative ~ALL for now.
> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in > message news:OoYrxb$YKHA.1596@TK2MSFTNGP06.phx.gbl... >> Even if spammers were registering domain names, I doubt they'd bother to >> configure the SPF records. Regardless, one thing I know is that since I >> started having the IMF consider the SPF status, I've stopped just about >> all of the messages purporting to be from my own domain. I've seen a >> huge reduction in incoming spam since configuring this.
>> Steve, I'm betting all your domains have proper SPF records, right : -)
>> Milhouse, good info about the Spam Assassin score. Thanks.
The response to a missing SPF record should be simply to pass the mail, because there is nothing there to fail. In the case of misconfigured or invalid SPF records, the receiving server should treat them differently than an outright fail, at least according to this http://www.openspf.org/SPF_Record_Syntax page.
Until recently, NetSol could not do SPF TXT records, and I am sure there are others. But then again, if they don't have an SPF record, the receiving side should just accept it.
> I'm using -all, but I don't think most recipients are outright rejecting > messages that fail sender ID. For example, I have Sender ID set to > "Accept (the Sender ID status will be attached to the message for further > anti-spam processing)." So if someone sends me a message spoofed to say > it's from me, the Sender ID will fail, and that info gets passed along to > the IMF. So what I'm thinking is that messages that previously would have > ended up in the Junk Mail folder are now getting a higher SCL due to > Sender ID, passing the IMF threshold to reject rather than send to Junk.
> I'm not comfortable deleting or rejecting messages based solely on Sender > ID. We have a lot of clients who send e-mail from small ISP's, or from > their own mail servers, who may have missing or incorrect SPF records. I > don't want to act negatively on legitimate messages, due to a > configuration that's probably outside the sender's control. Also, I think > there may be DNS providers that don't even accommodate SPF records at all.
> "Milhouse Van Houten" <b...@myrealbox.com> wrote in message > news:u9xITsAZKHA.1648@TK2MSFTNGP05.phx.gbl... >> Would that be more a reflection of the SPF record in DNS or IMF >> considering SPF? Did you set your record as -ALL (reject) or ~ALL >> (accept but mark)? I think if it's reject then messages pretending to >> come from your own domain would never arrive, making IMF being informed >> by SPF less important, but we're using the more conservative ~ALL for >> now.
>> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in >> message news:OoYrxb$YKHA.1596@TK2MSFTNGP06.phx.gbl... >>> Even if spammers were registering domain names, I doubt they'd bother to >>> configure the SPF records. Regardless, one thing I know is that since I >>> started having the IMF consider the SPF status, I've stopped just about >>> all of the messages purporting to be from my own domain. I've seen a >>> huge reduction in incoming spam since configuring this.
>>> Steve, I'm betting all your domains have proper SPF records, right : -)
>>> Milhouse, good info about the Spam Assassin score. Thanks.
What I meant by "if they don't have an SPF record, the receiving side should just accept it" is only in reference to the SPF record. Of course, it will still be subject to any other tests.
> I'm using -all, but I don't think most recipients are outright rejecting > messages that fail sender ID. For example, I have Sender ID set to > "Accept (the Sender ID status will be attached to the message for further > anti-spam processing)." So if someone sends me a message spoofed to say > it's from me, the Sender ID will fail, and that info gets passed along to > the IMF. So what I'm thinking is that messages that previously would have > ended up in the Junk Mail folder are now getting a higher SCL due to > Sender ID, passing the IMF threshold to reject rather than send to Junk.
> I'm not comfortable deleting or rejecting messages based solely on Sender > ID. We have a lot of clients who send e-mail from small ISP's, or from > their own mail servers, who may have missing or incorrect SPF records. I > don't want to act negatively on legitimate messages, due to a > configuration that's probably outside the sender's control. Also, I think > there may be DNS providers that don't even accommodate SPF records at all.
> "Milhouse Van Houten" <b...@myrealbox.com> wrote in message > news:u9xITsAZKHA.1648@TK2MSFTNGP05.phx.gbl... >> Would that be more a reflection of the SPF record in DNS or IMF >> considering SPF? Did you set your record as -ALL (reject) or ~ALL >> (accept but mark)? I think if it's reject then messages pretending to >> come from your own domain would never arrive, making IMF being informed >> by SPF less important, but we're using the more conservative ~ALL for >> now.
>> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in >> message news:OoYrxb$YKHA.1596@TK2MSFTNGP06.phx.gbl... >>> Even if spammers were registering domain names, I doubt they'd bother to >>> configure the SPF records. Regardless, one thing I know is that since I >>> started having the IMF consider the SPF status, I've stopped just about >>> all of the messages purporting to be from my own domain. I've seen a >>> huge reduction in incoming spam since configuring this.
>>> Steve, I'm betting all your domains have proper SPF records, right : -)
>>> Milhouse, good info about the Spam Assassin score. Thanks.
I'd be interested to see if spam went down noticeably if I bounced or deleted based on SPF. I can't really test that - we're pretty sensitive to missing messages due to false positives, and as a result we tolerate a little more spam than we'd have to otherwise.
> The response to a missing SPF record should be simply to pass the mail, > because there is nothing there to fail. In the case of misconfigured or > invalid SPF records, the receiving server should treat them differently > than an outright fail, at least according to this > http://www.openspf.org/SPF_Record_Syntax page.
> Until recently, NetSol could not do SPF TXT records, and I am sure there > are others. But then again, if they don't have an SPF record, the > receiving side should just accept it.
> Gregg Hill
> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in > message news:uDacDWJZKHA.740@TK2MSFTNGP04.phx.gbl... >> I'm using -all, but I don't think most recipients are outright rejecting >> messages that fail sender ID. For example, I have Sender ID set to >> "Accept (the Sender ID status will be attached to the message for further >> anti-spam processing)." So if someone sends me a message spoofed to say >> it's from me, the Sender ID will fail, and that info gets passed along to >> the IMF. So what I'm thinking is that messages that previously would >> have ended up in the Junk Mail folder are now getting a higher SCL due to >> Sender ID, passing the IMF threshold to reject rather than send to Junk.
>> I'm not comfortable deleting or rejecting messages based solely on Sender >> ID. We have a lot of clients who send e-mail from small ISP's, or from >> their own mail servers, who may have missing or incorrect SPF records. I >> don't want to act negatively on legitimate messages, due to a >> configuration that's probably outside the sender's control. Also, I >> think there may be DNS providers that don't even accommodate SPF records >> at all.
>> "Milhouse Van Houten" <b...@myrealbox.com> wrote in message >> news:u9xITsAZKHA.1648@TK2MSFTNGP05.phx.gbl... >>> Would that be more a reflection of the SPF record in DNS or IMF >>> considering SPF? Did you set your record as -ALL (reject) or ~ALL >>> (accept but mark)? I think if it's reject then messages pretending to >>> come from your own domain would never arrive, making IMF being informed >>> by SPF less important, but we're using the more conservative ~ALL for >>> now.
>>> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in >>> message news:OoYrxb$YKHA.1596@TK2MSFTNGP06.phx.gbl... >>>> Even if spammers were registering domain names, I doubt they'd bother >>>> to configure the SPF records. Regardless, one thing I know is that >>>> since I started having the IMF consider the SPF status, I've stopped >>>> just about all of the messages purporting to be from my own domain. >>>> I've seen a huge reduction in incoming spam since configuring this.
>>>> Steve, I'm betting all your domains have proper SPF records, right : -)
>>>> Milhouse, good info about the Spam Assassin score. Thanks.
Just to touch on the small clients that may have missing or incorrect SPF records...
If the record is missing then that is not a "fail" as far as SPF is concerned. Setting Exchange to reject SenderID failures will still accept messages if no SenderID record can be resolved and pass that on to IMF.
The incorrect bit...depends on what you mean. If you mean that the record isn't valid, then it'll be treated like a non-existent record. See above.
If, however, you mean incorrect in the sense that the record creator failed to list a server in the record, so the record itself is valid and can be parsed, but generates failures because messages are coming from a legitimate server not in the record....well...all I can say is I'd like to think that even a small firm, if their IT manager went far enough to create an SPF record, he tested it...so I'd think that even an organization sensitive to false positives can accept that this is such an extreme edge-case that it should never come into play in the "real world."
I've been using SenderID filtering for many of my clients for many years, and not once have I traced a missing message back to an improperly configured SPF record. It is anecdotal evidence, to be sure, but still, just food for thought.
Of course your logic about a message getting a higher SCL because of a SenderID fail is spot on, so that works too. Just a little more overhead on the server because it accepts the message and IMF has to do some scanning. Same result from two slightly different methods. :)
> I'm using -all, but I don't think most recipients are outright rejecting > messages that fail sender ID. For example, I have Sender ID set to > "Accept (the Sender ID status will be attached to the message for further > anti-spam processing)." So if someone sends me a message spoofed to say > it's from me, the Sender ID will fail, and that info gets passed along to > the IMF. So what I'm thinking is that messages that previously would have > ended up in the Junk Mail folder are now getting a higher SCL due to > Sender ID, passing the IMF threshold to reject rather than send to Junk.
> I'm not comfortable deleting or rejecting messages based solely on Sender > ID. We have a lot of clients who send e-mail from small ISP's, or from > their own mail servers, who may have missing or incorrect SPF records. I > don't want to act negatively on legitimate messages, due to a > configuration that's probably outside the sender's control. Also, I think > there may be DNS providers that don't even accommodate SPF records at all.
> "Milhouse Van Houten" <b...@myrealbox.com> wrote in message > news:u9xITsAZKHA.1648@TK2MSFTNGP05.phx.gbl... >> Would that be more a reflection of the SPF record in DNS or IMF >> considering SPF? Did you set your record as -ALL (reject) or ~ALL >> (accept but mark)? I think if it's reject then messages pretending to >> come from your own domain would never arrive, making IMF being informed >> by SPF less important, but we're using the more conservative ~ALL for >> now.
>> "Dave Nickason [SBS MVP]" <gwdib...@NOSPAM.frontiernet.net> wrote in >> message news:OoYrxb$YKHA.1596@TK2MSFTNGP06.phx.gbl... >>> Even if spammers were registering domain names, I doubt they'd bother to >>> configure the SPF records. Regardless, one thing I know is that since I >>> started having the IMF consider the SPF status, I've stopped just about >>> all of the messages purporting to be from my own domain. I've seen a >>> huge reduction in incoming spam since configuring this.
>>> Steve, I'm betting all your domains have proper SPF records, right : -)
>>> Milhouse, good info about the Spam Assassin score. Thanks.
|
