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/[email protected]/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 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 both together. > > >> -- 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 [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
