Re: [spamdyke-users] DKIM etc.
On Wed, Oct 8, 2008 at 10:33 PM, Sam Clippinger <[EMAIL PROTECTED]> wrote: > Well, not necessarily. At the moment, spamdyke is only vulnerable to a > very small part of the DNS spoofing attack. Most of the danger Dan > Kaminsky discovered comes from caching -- a vulnerable host could cache > incorrect DNS data sent by the attacker. spamdyke doesn't cache DNS > information, so that's a moot point. > > To be completely honest, there is a small danger that spamdyke could > receive spoofed responses from an attacker, if the attacker sends > packets with the correct ID numbers to the correct port before the > "real" nameserver could respond. The chances of success are very, very > low (but not zero) because each spamdyke process uses a different UDP > port for its DNS traffic, which only remains open while the process is > running. Also, the starting IDs for the queries are chosen randomly by > each process. It's not like a BIND server that uses the same port for > thousands of queries and increments its IDs in a predictable pattern. > > If someone did manage to spoof responses to a spamdyke process, the most > they could achieve would be an incorrect result for an RBL or rDNS > query. As a result, if a message were accepted improperly, the only > consequence is one piece of spam being delivered. Alternatively, if a > legitimate message were rejected improperly, the sender would receive a > bounce or the remote server would retry later (depending on the filter > and the attacker's data). There's no way to corrupt or intercept email > with this attack. > > So, I plan to look at randomizing the query ports. It's not a complex > change, so it'll probably be in the next feature-release or two. > Because the risk is so low, I may not implement it if the overhead is > too high. Either way, I plan to remain calmer than CERT/CC did. :) > > -- Sam Clippinger > > slamp slamp wrote: >> On Fri, Oct 3, 2008 at 5:52 PM, Eric Shubert <[EMAIL PROTECTED]> wrote: >> >>> Felix Buenemann wrote: >>> Hi, I agree with Arthur and Bgs in that SPF is a smarter thing to check, because it can be done without checking headers and currently has a much wider disribution base. IMHO the only way to properly reject DKIM failed mail is at the end of the DATA command, which is exactly how eg. simscan rejects virii or spam mail. So IMHO DKIM verification is something to do for a queue-handler not a frot end smtp handler, that is geared for high performance. (This is based on the assumtion, that spamdyke deals with 99% of the scam with very little cpu time, thus reducing server load and leaving more in depth checks to those mails that slip through spamdyke's already tight web.) -- Felix >>> Good thinking, Felix. Some things just don't belong in spamdyke as is. >>> >>> -- >>> -Eric 'shubes' >>> >>> >> >> >> I am not sure if this has been implemented, but this should be at the >> top, right? >> >> Fix the DNS spoofing "bug" by randomizing the outbound port with every >> query. >> Try not to panic about it like CERT/CC did. >> ___ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > Thanks for the explanation Sam! ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Well, not necessarily. At the moment, spamdyke is only vulnerable to a very small part of the DNS spoofing attack. Most of the danger Dan Kaminsky discovered comes from caching -- a vulnerable host could cache incorrect DNS data sent by the attacker. spamdyke doesn't cache DNS information, so that's a moot point. To be completely honest, there is a small danger that spamdyke could receive spoofed responses from an attacker, if the attacker sends packets with the correct ID numbers to the correct port before the "real" nameserver could respond. The chances of success are very, very low (but not zero) because each spamdyke process uses a different UDP port for its DNS traffic, which only remains open while the process is running. Also, the starting IDs for the queries are chosen randomly by each process. It's not like a BIND server that uses the same port for thousands of queries and increments its IDs in a predictable pattern. If someone did manage to spoof responses to a spamdyke process, the most they could achieve would be an incorrect result for an RBL or rDNS query. As a result, if a message were accepted improperly, the only consequence is one piece of spam being delivered. Alternatively, if a legitimate message were rejected improperly, the sender would receive a bounce or the remote server would retry later (depending on the filter and the attacker's data). There's no way to corrupt or intercept email with this attack. So, I plan to look at randomizing the query ports. It's not a complex change, so it'll probably be in the next feature-release or two. Because the risk is so low, I may not implement it if the overhead is too high. Either way, I plan to remain calmer than CERT/CC did. :) -- Sam Clippinger slamp slamp wrote: > On Fri, Oct 3, 2008 at 5:52 PM, Eric Shubert <[EMAIL PROTECTED]> wrote: > >> Felix Buenemann wrote: >> >>> Hi, >>> >>> I agree with Arthur and Bgs in that SPF is a smarter thing to check, >>> because it can be done without checking headers and currently has a much >>> wider disribution base. >>> >>> IMHO the only way to properly reject DKIM failed mail is at the end of >>> the DATA command, which is exactly how eg. simscan rejects virii or spam >>> mail. So IMHO DKIM verification is something to do for a queue-handler >>> not a frot end smtp handler, that is geared for high performance. (This >>> is based on the assumtion, that spamdyke deals with 99% of the scam with >>> very little cpu time, thus reducing server load and leaving more in >>> depth checks to those mails that slip through spamdyke's already tight web.) >>> >>> -- Felix >>> >> Good thinking, Felix. Some things just don't belong in spamdyke as is. >> >> -- >> -Eric 'shubes' >> >> > > > I am not sure if this has been implemented, but this should be at the > top, right? > > Fix the DNS spoofing "bug" by randomizing the outbound port with every > query. > Try not to panic about it like CERT/CC did. > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
On Fri, Oct 3, 2008 at 5:52 PM, Eric Shubert <[EMAIL PROTECTED]> wrote: > Felix Buenemann wrote: >> Hi, >> >> I agree with Arthur and Bgs in that SPF is a smarter thing to check, >> because it can be done without checking headers and currently has a much >> wider disribution base. >> >> IMHO the only way to properly reject DKIM failed mail is at the end of >> the DATA command, which is exactly how eg. simscan rejects virii or spam >> mail. So IMHO DKIM verification is something to do for a queue-handler >> not a frot end smtp handler, that is geared for high performance. (This >> is based on the assumtion, that spamdyke deals with 99% of the scam with >> very little cpu time, thus reducing server load and leaving more in >> depth checks to those mails that slip through spamdyke's already tight web.) >> >> -- Felix > > Good thinking, Felix. Some things just don't belong in spamdyke as is. > > -- > -Eric 'shubes' > I am not sure if this has been implemented, but this should be at the top, right? Fix the DNS spoofing "bug" by randomizing the outbound port with every query. Try not to panic about it like CERT/CC did. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Felix Buenemann wrote: > Hi, > > I agree with Arthur and Bgs in that SPF is a smarter thing to check, > because it can be done without checking headers and currently has a much > wider disribution base. > > IMHO the only way to properly reject DKIM failed mail is at the end of > the DATA command, which is exactly how eg. simscan rejects virii or spam > mail. So IMHO DKIM verification is something to do for a queue-handler > not a frot end smtp handler, that is geared for high performance. (This > is based on the assumtion, that spamdyke deals with 99% of the scam with > very little cpu time, thus reducing server load and leaving more in > depth checks to those mails that slip through spamdyke's already tight web.) > > -- Felix Good thinking, Felix. Some things just don't belong in spamdyke as is. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Hi, I agree with Arthur and Bgs in that SPF is a smarter thing to check, because it can be done without checking headers and currently has a much wider disribution base. IMHO the only way to properly reject DKIM failed mail is at the end of the DATA command, which is exactly how eg. simscan rejects virii or spam mail. So IMHO DKIM verification is something to do for a queue-handler not a frot end smtp handler, that is geared for high performance. (This is based on the assumtion, that spamdyke deals with 99% of the scam with very little cpu time, thus reducing server load and leaving more in depth checks to those mails that slip through spamdyke's already tight web.) -- Felix ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Sam, Just a note: paypal.com has spf v1 records too and spf is much easier to implement. So if I were you and the main point is @paypal.com, I'd go spf v1. Just my 2c :) Regards Bgs PS: Just for the records: v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.paypal.com include:c._spf.ebay.com include:spf-1.paypal.com ~all PS2: Wonder why TEMPFAIL... Sam Clippinger wrote: > I did some Googling today and found this: > http://www.phishtank.com/stats/2008/07/ > Apparently, in July of this year, phishtank.com verified more phishing > scams targeting PayPal than the rest of the top 10 targets combined. > That pretty impressive, although I must take it with a grain of salt > because I don't know anything about phishtank.com or how they collect > their stats. > > Anecdotally, I personally see a lot of PayPal scam emails and > SpamAssassin seems to catch all of them. However, most of my users are > not technically literate, nor are they sufficiently skeptical when it > comes to official-looking messages. Given the seriousness of falling > victim to a phishing scam, I would love to block those messages > entirely. If DKIM could stop them once and for all, it would be worth > the effort. > > Here's another way to think about it: spamdyke already does pretty much > everything _I_ need it to do. At this point, I continue working on it > because it's a hobby and I enjoy it. So even though I have a > prioritized TODO list, I'm willing to reshuffle it if even one person > expresses a need/desire for something. That's why I'm working on > recipient validation now -- it's not something I really need for myself > but everyone was asking for it so... > > If there's a feature you'd rather see in spamdyke before DKIM, now's the > time to speak up. :) > > -- Sam Clippinger > > Arthur Girardi wrote: >> Hi. >> >> >>> I disagree about waiting for a certain (or uncertain) percentage of servers >>> in a survey before implementing it though. This isn't a feature about >>> convenience or annoyance, it's a feature that will probably have a big >>> positive impact on some peoples lives. I think the fact that PayPal and eBay >>> have already implemented it (months ago) is a strong indicator of its >>> importance. I'd like to know which other major banking institutions have >>> implemented it, but I don't. I expect that Chase and BofA will be doing so >>> as soon as they can though (based on the phishing emails I've seen). >>> >>> Perhaps we can agree to disagree on this one. And like I said, I could be >>> wrong (again). ;) >>> >> Maybe I expressed myself incorrectly. Sure 15-20% is a wild guess of >> mine, who serves a not so critical slice of the market, and I try to >> keep things stable, avoiding adding too many tools that I don't >> consider essential. >> >> Surely big companies which work with any kind of eletronic commerce or >> online payment systems, like the ones you quoted, or any company that >> deals with money in a eletronic way, will always attemp to or >> implement these edge security enhancements, and well justified. But >> aside these cases, I hardly see a real purpose for the majority of >> small business people to enter this bloody jungle, other than for >> testing. >> >> In reality, I'm just ranting because I didn't see the major brazilian >> banks which also suffer from lots of of pishing, implementing these >> tools. Once they do (if the do), and depending on the speed they do, >> and also on the result of their work, that will surely have an impact >> on my business and consequentially on my decision of implementing it >> for myself. >> >> But one thing is for sure, either way, I (with the viewpoint of small >> business hosting provider) will refrain for now from implement >> anything like that unless someone puts up a nice tool with lots of >> log-spitting like what spamdyke does. :) >> >> Arthur >> >> >> ___ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Thanks, Sam. I like your way of thinking. :) Sam Clippinger wrote: > I did some Googling today and found this: > http://www.phishtank.com/stats/2008/07/ > Apparently, in July of this year, phishtank.com verified more phishing > scams targeting PayPal than the rest of the top 10 targets combined. > That pretty impressive, although I must take it with a grain of salt > because I don't know anything about phishtank.com or how they collect > their stats. > > Anecdotally, I personally see a lot of PayPal scam emails and > SpamAssassin seems to catch all of them. However, most of my users are > not technically literate, nor are they sufficiently skeptical when it > comes to official-looking messages. Given the seriousness of falling > victim to a phishing scam, I would love to block those messages > entirely. If DKIM could stop them once and for all, it would be worth > the effort. > > Here's another way to think about it: spamdyke already does pretty much > everything _I_ need it to do. At this point, I continue working on it > because it's a hobby and I enjoy it. So even though I have a > prioritized TODO list, I'm willing to reshuffle it if even one person > expresses a need/desire for something. That's why I'm working on > recipient validation now -- it's not something I really need for myself > but everyone was asking for it so... > > If there's a feature you'd rather see in spamdyke before DKIM, now's the > time to speak up. :) > > -- Sam Clippinger > > Arthur Girardi wrote: >> Hi. >> >> >>> I disagree about waiting for a certain (or uncertain) percentage of servers >>> in a survey before implementing it though. This isn't a feature about >>> convenience or annoyance, it's a feature that will probably have a big >>> positive impact on some peoples lives. I think the fact that PayPal and eBay >>> have already implemented it (months ago) is a strong indicator of its >>> importance. I'd like to know which other major banking institutions have >>> implemented it, but I don't. I expect that Chase and BofA will be doing so >>> as soon as they can though (based on the phishing emails I've seen). >>> >>> Perhaps we can agree to disagree on this one. And like I said, I could be >>> wrong (again). ;) >>> >> Maybe I expressed myself incorrectly. Sure 15-20% is a wild guess of >> mine, who serves a not so critical slice of the market, and I try to >> keep things stable, avoiding adding too many tools that I don't >> consider essential. >> >> Surely big companies which work with any kind of eletronic commerce or >> online payment systems, like the ones you quoted, or any company that >> deals with money in a eletronic way, will always attemp to or >> implement these edge security enhancements, and well justified. But >> aside these cases, I hardly see a real purpose for the majority of >> small business people to enter this bloody jungle, other than for >> testing. >> >> In reality, I'm just ranting because I didn't see the major brazilian >> banks which also suffer from lots of of pishing, implementing these >> tools. Once they do (if the do), and depending on the speed they do, >> and also on the result of their work, that will surely have an impact >> on my business and consequentially on my decision of implementing it >> for myself. >> >> But one thing is for sure, either way, I (with the viewpoint of small >> business hosting provider) will refrain for now from implement >> anything like that unless someone puts up a nice tool with lots of >> log-spitting like what spamdyke does. :) >> >> Arthur >> >> >> ___ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
I did some Googling today and found this: http://www.phishtank.com/stats/2008/07/ Apparently, in July of this year, phishtank.com verified more phishing scams targeting PayPal than the rest of the top 10 targets combined. That pretty impressive, although I must take it with a grain of salt because I don't know anything about phishtank.com or how they collect their stats. Anecdotally, I personally see a lot of PayPal scam emails and SpamAssassin seems to catch all of them. However, most of my users are not technically literate, nor are they sufficiently skeptical when it comes to official-looking messages. Given the seriousness of falling victim to a phishing scam, I would love to block those messages entirely. If DKIM could stop them once and for all, it would be worth the effort. Here's another way to think about it: spamdyke already does pretty much everything _I_ need it to do. At this point, I continue working on it because it's a hobby and I enjoy it. So even though I have a prioritized TODO list, I'm willing to reshuffle it if even one person expresses a need/desire for something. That's why I'm working on recipient validation now -- it's not something I really need for myself but everyone was asking for it so... If there's a feature you'd rather see in spamdyke before DKIM, now's the time to speak up. :) -- Sam Clippinger Arthur Girardi wrote: > Hi. > > >> I disagree about waiting for a certain (or uncertain) percentage of servers >> in a survey before implementing it though. This isn't a feature about >> convenience or annoyance, it's a feature that will probably have a big >> positive impact on some peoples lives. I think the fact that PayPal and eBay >> have already implemented it (months ago) is a strong indicator of its >> importance. I'd like to know which other major banking institutions have >> implemented it, but I don't. I expect that Chase and BofA will be doing so >> as soon as they can though (based on the phishing emails I've seen). >> >> Perhaps we can agree to disagree on this one. And like I said, I could be >> wrong (again). ;) >> > > Maybe I expressed myself incorrectly. Sure 15-20% is a wild guess of > mine, who serves a not so critical slice of the market, and I try to > keep things stable, avoiding adding too many tools that I don't > consider essential. > > Surely big companies which work with any kind of eletronic commerce or > online payment systems, like the ones you quoted, or any company that > deals with money in a eletronic way, will always attemp to or > implement these edge security enhancements, and well justified. But > aside these cases, I hardly see a real purpose for the majority of > small business people to enter this bloody jungle, other than for > testing. > > In reality, I'm just ranting because I didn't see the major brazilian > banks which also suffer from lots of of pishing, implementing these > tools. Once they do (if the do), and depending on the speed they do, > and also on the result of their work, that will surely have an impact > on my business and consequentially on my decision of implementing it > for myself. > > But one thing is for sure, either way, I (with the viewpoint of small > business hosting provider) will refrain for now from implement > anything like that unless someone puts up a nice tool with lots of > log-spitting like what spamdyke does. :) > > Arthur > > > ___ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
I understand what you're saying about outbound email versus SMTP mail (and I've read this kind of thing before) but I must admit I don't see the point. The only difference, in my reading, is that connections to port 587 must be authenticated while connections to port 25 _may_ be authenticated. In all other respects, the two ports are identical. Neither is hidden behind a firewall. If my users always authenticate anyway, changing ports only causes confusion (and firewall issues). Maybe there's some other benefit I haven't discovered yet. As far as spamdyke is concerned, I don't know how to focus on one type of email versus another. My vision for the auto-whitelist is what Roman V. Isaev suggested three months ago (http://www.mail-archive.com/spamdyke-users@spamdyke.org/msg01331.html). When spamdyke processes an authenticated message, it could automatically add the sender/recipient pair to a temporary whitelist in reverse order (sender becomes recipient, recipient becomes sender). This way, when a local user sends a message to a remote user, spamdyke takes note. When the remote user responds, the reply automatically bypasses some or all filters. Like graylist entries, the whitelist entries would expire after a short (configurable) amount of time. This feature wouldn't completely remove the need to whitelist remote servers by IP address but it would be very handy for sending one-time messages to someone new and knowing that the response (if any) won't be blocked. If your users send their email through port 587 and spamdyke doesn't run there, you won't be able to use the auto-whitelist but spamdyke will be just as useful as it is now. I'm also eager to implement a daemon mode for spamdyke -- there are a lot features that become possible if spamdyke runs as a daemon instead of a single-instance filter. I'm even more eager to wrap spamdyke in a Windows Service. I've lost count of the number of conversations I've had with Exchange administrators where I've described spamdyke's features and ended with "but it only works with qmail". Some of them have almost cried. -- Sam Clippinger Eric Shubert wrote: > Sam Clippinger wrote: > >> Am I reading these two links incorrectly, or do they basically say that >> no one is using DKIM? :) >> > > Yet. The standard is just being finalized. :) > > >> Generally speaking, I'm not opposed to implementing DKIM, SPF or any >> other domain authentication method. My only concern has been whether >> the investment of effort would be worth it. For quite a while now, I've >> felt my time would be better spent adding features that would have a >> bigger impact than DKIM/SPF/whatever, especially considering the limited >> time I'm able to devote to spamdyke development. However, given the >> number of phishing scams based on eBay and PayPal, using DKIM to reject >> those scams looks pretty attractive. >> > > That was my thinking as well. I certainly don't want to see you working on > something with little value. > > >> How do you envision DKIM support working in spamdyke? If the connection >> were not blocked by another filter before the message data was sent, >> spamdyke would need to buffer the message headers and check the DKIM >> signature. If the signature failed the check, what happens? Should >> spamdyke just send a rejection code and close the connection? (There >> are a lot of poorly-written mail clients that don't handle this >> situation gracefully.) Should it add a new header or change one of the >> other headers (e.g. Subject) to report the DKIM failure? Should it try >> to buffer the entire message and deliver it to someone else? Should it >> accept and silently discard the message? Should all of those things be >> possible (but configurable)? >> >> Perhaps a better question is this: How do other MTAs handle DKIM failures? >> > > I don't know. To be honest, I haven't read the spec. I'm more familiar with > DomainKeys actually. Would you like me to do some analysis and report back? > > >> I've also got some pretty big features (growing stale) on the TODO list >> (among many minor changes). I'm currently working on recipient >> validation (which has turned out to be nearly as convoluted and >> confusing as I had feared), so I'll definitely finish that up. After >> that, loosely in order of priority: >> Limited support for examining message headers so some headers could >> be logged (e.g. Subject). >> Rewriting/adding headers when filters failed instead of rejecting >> the message entirely. >> Replacing/adding recipients unconditionally (e.g. monitoring >> employee email or redirecting addresses) or when filters failed (e.g. >> sending all spam to a specific mailbox). >> Full database support, especially for the graylist filter, to make >> life simpler for administrators of large sites. >> Automatic whitelisting to allow replies from recipients
Re: [spamdyke-users] DKIM etc.
Hi. > I disagree about waiting for a certain (or uncertain) percentage of servers > in a survey before implementing it though. This isn't a feature about > convenience or annoyance, it's a feature that will probably have a big > positive impact on some peoples lives. I think the fact that PayPal and eBay > have already implemented it (months ago) is a strong indicator of its > importance. I'd like to know which other major banking institutions have > implemented it, but I don't. I expect that Chase and BofA will be doing so > as soon as they can though (based on the phishing emails I've seen). > > Perhaps we can agree to disagree on this one. And like I said, I could be > wrong (again). ;) Maybe I expressed myself incorrectly. Sure 15-20% is a wild guess of mine, who serves a not so critical slice of the market, and I try to keep things stable, avoiding adding too many tools that I don't consider essential. Surely big companies which work with any kind of eletronic commerce or online payment systems, like the ones you quoted, or any company that deals with money in a eletronic way, will always attemp to or implement these edge security enhancements, and well justified. But aside these cases, I hardly see a real purpose for the majority of small business people to enter this bloody jungle, other than for testing. In reality, I'm just ranting because I didn't see the major brazilian banks which also suffer from lots of of pishing, implementing these tools. Once they do (if the do), and depending on the speed they do, and also on the result of their work, that will surely have an impact on my business and consequentially on my decision of implementing it for myself. But one thing is for sure, either way, I (with the viewpoint of small business hosting provider) will refrain for now from implement anything like that unless someone puts up a nice tool with lots of log-spitting like what spamdyke does. :) Arthur ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Arthur Girardi wrote: > Hello, > > Sorry for butting in, but I'd like to give some of my thoughs too. > > I don't think Sam should invest time in an implementation of DKIM now, > its just not the right time. As Eric said, its not yet a standard, so > many mail administrators won't implement it for lack of support. Also, > those links clearly demonstrate too few servers are using it to > justify the need for it today and the ammount of work which I believe > would take to implement it on spamdyke. > > Instead, if I had to choose, I'd choose SPF which is very popular > nowadays compared to DomainKeys/DKIM. BUT! Qmail, specifically Plesk's > qmail, already handles SPF checking, and does it well (aside the > obvious non-existant logging feature). I believe Postfix/Sendmail also > may have a good implementation of SPF already. > > And please don't misunderstand me, I'd really like to have DKIM > support in spamdyke yes (the more features the merrier, and Sam's > logging implementation are nothing short of shockingly amazing), just > I'd put it in the later-than-sooner TODO list, like, for when about > 15-20% of mailservers out there would be using DKIM. > > Arthur I appreciate your thoughts Arthur. I also think that SPF shouldn't be a high priority because the functionality is largely there already. I also agree that Sam shouldn't do DKIM until the standard is finalized. I honestly don't know whether that's happened yet or not. I'll look into it. I disagree about waiting for a certain (or uncertain) percentage of servers in a survey before implementing it though. This isn't a feature about convenience or annoyance, it's a feature that will probably have a big positive impact on some peoples lives. I think the fact that PayPal and eBay have already implemented it (months ago) is a strong indicator of its importance. I'd like to know which other major banking institutions have implemented it, but I don't. I expect that Chase and BofA will be doing so as soon as they can though (based on the phishing emails I've seen). Perhaps we can agree to disagree on this one. And like I said, I could be wrong (again). ;) -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Hello, Sorry for butting in, but I'd like to give some of my thoughs too. I don't think Sam should invest time in an implementation of DKIM now, its just not the right time. As Eric said, its not yet a standard, so many mail administrators won't implement it for lack of support. Also, those links clearly demonstrate too few servers are using it to justify the need for it today and the ammount of work which I believe would take to implement it on spamdyke. Instead, if I had to choose, I'd choose SPF which is very popular nowadays compared to DomainKeys/DKIM. BUT! Qmail, specifically Plesk's qmail, already handles SPF checking, and does it well (aside the obvious non-existant logging feature). I believe Postfix/Sendmail also may have a good implementation of SPF already. And please don't misunderstand me, I'd really like to have DKIM support in spamdyke yes (the more features the merrier, and Sam's logging implementation are nothing short of shockingly amazing), just I'd put it in the later-than-sooner TODO list, like, for when about 15-20% of mailservers out there would be using DKIM. Arthur ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Sam Clippinger wrote: > Am I reading these two links incorrectly, or do they basically say that > no one is using DKIM? :) Yet. The standard is just being finalized. :) > Generally speaking, I'm not opposed to implementing DKIM, SPF or any > other domain authentication method. My only concern has been whether > the investment of effort would be worth it. For quite a while now, I've > felt my time would be better spent adding features that would have a > bigger impact than DKIM/SPF/whatever, especially considering the limited > time I'm able to devote to spamdyke development. However, given the > number of phishing scams based on eBay and PayPal, using DKIM to reject > those scams looks pretty attractive. That was my thinking as well. I certainly don't want to see you working on something with little value. > How do you envision DKIM support working in spamdyke? If the connection > were not blocked by another filter before the message data was sent, > spamdyke would need to buffer the message headers and check the DKIM > signature. If the signature failed the check, what happens? Should > spamdyke just send a rejection code and close the connection? (There > are a lot of poorly-written mail clients that don't handle this > situation gracefully.) Should it add a new header or change one of the > other headers (e.g. Subject) to report the DKIM failure? Should it try > to buffer the entire message and deliver it to someone else? Should it > accept and silently discard the message? Should all of those things be > possible (but configurable)? > > Perhaps a better question is this: How do other MTAs handle DKIM failures? I don't know. To be honest, I haven't read the spec. I'm more familiar with DomainKeys actually. Would you like me to do some analysis and report back? > I've also got some pretty big features (growing stale) on the TODO list > (among many minor changes). I'm currently working on recipient > validation (which has turned out to be nearly as convoluted and > confusing as I had feared), so I'll definitely finish that up. After > that, loosely in order of priority: > Limited support for examining message headers so some headers could > be logged (e.g. Subject). > Rewriting/adding headers when filters failed instead of rejecting > the message entirely. > Replacing/adding recipients unconditionally (e.g. monitoring > employee email or redirecting addresses) or when filters failed (e.g. > sending all spam to a specific mailbox). > Full database support, especially for the graylist filter, to make > life simpler for administrators of large sites. > Automatic whitelisting to allow replies from recipients of outbound > email. > Daemon proxy mode to replace tcpserver and make spamdyke usable by > non-qmail sites. > Windows Service mode to make spamdyke usable by Exchange administrators. > Tarpit mode to trap botnet spammers the way LaBrea used to trap Code > Red attackers. > As you noted, DKIM doesn't (currently) make my list; where should it be > ranked? Short answer, near the top. I'm a little confused by something here. You mentioned earlier that some mail clients don't handle rejections gracefully. There are also some enhancement items (e.g. Automatic whitelisting) that refer to processing outbound email. In my implementation of spamdyke, these would not come into play as spamdyke is only configured for the smtp port, not the submission port. I realize that it's still most common for both to use port 25. Conceptually speaking, I see anything related to submitting email as being outside of the scope of spamdyke. After all, submitters must authenticate, and once authenticated all rules pass, so spamdyke is no longer effective (as it should be). The only reason spamdyke even has to deal with authentication is because port 25 is being used for 2 purposes, reception and submission. If there are features and functions regarding outbound mail, they should be written and implemented apart from spamdyke. Spamdyke should be geared to processing mail reception (from mail servers), not submission (from mail clients). I understand though that spamdyke needs to be able to handle some submission functionality (authentication) simply because port 25 is used for both types of connections. This is a necessary evil because servers have been (mal)configured with both types of connections on the same port (imho). Things become much simpler though when they're separated and submissions use port 587, while receptions use port 25. Am I missing something here (again)? On another note, I'd really like to see Daemon proxy mode moved up to the top as well. I think that being able to use spamdyke with postfix or exim as well as qmail would grow the user base greatly. I'd like to see what postfix/exim already have available before committing to this though. FWIW, I'm more interesting in postfix than exim, but I expect it'd be wise to look at b
Re: [spamdyke-users] DKIM etc.
Am I reading these two links incorrectly, or do they basically say that no one is using DKIM? :) Generally speaking, I'm not opposed to implementing DKIM, SPF or any other domain authentication method. My only concern has been whether the investment of effort would be worth it. For quite a while now, I've felt my time would be better spent adding features that would have a bigger impact than DKIM/SPF/whatever, especially considering the limited time I'm able to devote to spamdyke development. However, given the number of phishing scams based on eBay and PayPal, using DKIM to reject those scams looks pretty attractive. How do you envision DKIM support working in spamdyke? If the connection were not blocked by another filter before the message data was sent, spamdyke would need to buffer the message headers and check the DKIM signature. If the signature failed the check, what happens? Should spamdyke just send a rejection code and close the connection? (There are a lot of poorly-written mail clients that don't handle this situation gracefully.) Should it add a new header or change one of the other headers (e.g. Subject) to report the DKIM failure? Should it try to buffer the entire message and deliver it to someone else? Should it accept and silently discard the message? Should all of those things be possible (but configurable)? Perhaps a better question is this: How do other MTAs handle DKIM failures? I've also got some pretty big features (growing stale) on the TODO list (among many minor changes). I'm currently working on recipient validation (which has turned out to be nearly as convoluted and confusing as I had feared), so I'll definitely finish that up. After that, loosely in order of priority: Limited support for examining message headers so some headers could be logged (e.g. Subject). Rewriting/adding headers when filters failed instead of rejecting the message entirely. Replacing/adding recipients unconditionally (e.g. monitoring employee email or redirecting addresses) or when filters failed (e.g. sending all spam to a specific mailbox). Full database support, especially for the graylist filter, to make life simpler for administrators of large sites. Automatic whitelisting to allow replies from recipients of outbound email. Daemon proxy mode to replace tcpserver and make spamdyke usable by non-qmail sites. Windows Service mode to make spamdyke usable by Exchange administrators. Tarpit mode to trap botnet spammers the way LaBrea used to trap Code Red attackers. As you noted, DKIM doesn't (currently) make my list; where should it be ranked? -- Sam Clippinger Eric Shubert wrote: > Eric Shubert wrote: > >> Sam, >> >> I see in the TODO file for 4.0 that adding SPF/CSV/Sender ID/DomainKeys/DKIM >> checking is ranked as a todo-later item. I don't care so much about >> CSV/SenderID/DomainKeys, but I'd like to see the others implemented sooner >> than later. >> >> In particular, DKIM signatures are reportedly (2/08) being implemented at >> PayPal and eBay, and I'd expect other (large) financial institutions to be >> implementing it soon as well. I think it'd be great to have spamdyke >> rejecting invalid DKIM signatures. This isn't so much simply an anti-spam >> measure, but a solution to a very real security threat (identity theft). >> >> SPF checking is presently available in qmail-toaster, so that's not a high >> priority for me. However, I think it's more appropriately done by spamdyke >> than (a patched) qmail, so I'd like to see you do this as well. >> >> As far as DomainKeys goes, the qmail-toaster implementation of this, at >> least on the checking side, is somewhat broken, so it'd be nice to have, but >> I don't honestly think it's being used, as it's being pretty much replaced >> with DKIM. My guess is that CSV and SenderID are also not worth the trouble >> to implement. >> >> I hope that others will share their opinions on this as well. I could be >> wrong (again). ;) >> >> Thanks for the great work with spamdyke. >> >> > > FWIW, some surveys regarding mail authentication: > http://www.sendmail.org/dkim/surveyFortune1000 > http://www.sendmail.org/dkim/surveyUsBanking > > ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] DKIM etc.
Eric Shubert wrote: > Sam, > > I see in the TODO file for 4.0 that adding SPF/CSV/Sender ID/DomainKeys/DKIM > checking is ranked as a todo-later item. I don't care so much about > CSV/SenderID/DomainKeys, but I'd like to see the others implemented sooner > than later. > > In particular, DKIM signatures are reportedly (2/08) being implemented at > PayPal and eBay, and I'd expect other (large) financial institutions to be > implementing it soon as well. I think it'd be great to have spamdyke > rejecting invalid DKIM signatures. This isn't so much simply an anti-spam > measure, but a solution to a very real security threat (identity theft). > > SPF checking is presently available in qmail-toaster, so that's not a high > priority for me. However, I think it's more appropriately done by spamdyke > than (a patched) qmail, so I'd like to see you do this as well. > > As far as DomainKeys goes, the qmail-toaster implementation of this, at > least on the checking side, is somewhat broken, so it'd be nice to have, but > I don't honestly think it's being used, as it's being pretty much replaced > with DKIM. My guess is that CSV and SenderID are also not worth the trouble > to implement. > > I hope that others will share their opinions on this as well. I could be > wrong (again). ;) > > Thanks for the great work with spamdyke. > FWIW, some surveys regarding mail authentication: http://www.sendmail.org/dkim/surveyFortune1000 http://www.sendmail.org/dkim/surveyUsBanking -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
[spamdyke-users] DKIM etc.
Sam, I see in the TODO file for 4.0 that adding SPF/CSV/Sender ID/DomainKeys/DKIM checking is ranked as a todo-later item. I don't care so much about CSV/SenderID/DomainKeys, but I'd like to see the others implemented sooner than later. In particular, DKIM signatures are reportedly (2/08) being implemented at PayPal and eBay, and I'd expect other (large) financial institutions to be implementing it soon as well. I think it'd be great to have spamdyke rejecting invalid DKIM signatures. This isn't so much simply an anti-spam measure, but a solution to a very real security threat (identity theft). SPF checking is presently available in qmail-toaster, so that's not a high priority for me. However, I think it's more appropriately done by spamdyke than (a patched) qmail, so I'd like to see you do this as well. As far as DomainKeys goes, the qmail-toaster implementation of this, at least on the checking side, is somewhat broken, so it'd be nice to have, but I don't honestly think it's being used, as it's being pretty much replaced with DKIM. My guess is that CSV and SenderID are also not worth the trouble to implement. I hope that others will share their opinions on this as well. I could be wrong (again). ;) Thanks for the great work with spamdyke. -- -Eric 'shubes' ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
