Hi Sam, >Very interesting. So if spamdyke had an option to filter the "MAIL FROM" command after authentication, it would need a few values: allow anything (current behavior), allow only locally hosted domains (provided by local-domains-entry and local-domains-file) or allow only the authenticated domain (if a >domain name was used in the authenticating username). Would that cover everything? Most people would use the first option (or not even turn it on), I would use the second option (all of my other domains and aliases are hosted on the same server) and restrictive ISPs might use the third. If the option >could be overridden in a configuration directory, admins could turn it on or off for specific domains or specific users or add non-local domains to the list for specific users. Right now, spamdyke already controls relaying for non-authenticated users by comparing the sending and receiving domains against the >list of locally hosted domains. This would basically extend that functionality to also work even after authentication has succeeded. I'll give that some serious thought.
That would be perfect! >I'm not sure I understand your second suggestion. Isn't that basically the same as the reject-missing-sender-mx filter? Invalid domains shouldn't have MX records, so they shouldn't pass the filter. Or are you talking about the "From" line in the message header itself? I think SpamAssassin can catch that >kind of abuse -- you may just need to increase the weight for that SA filter so it will automatically discard matching messages. Well spamdyke checks the sender envelope for valid MX, not the from header afiak and it seems a lot of spammers use a different from headers to the sender envelope. While I hear you on the spamassassin part catching this, that still means the message has to be delivered which uses unnecessary resources (to be scanned by SA) and bandwidth usage - my point is, if it's a non-existing domain in the from address, why carry on receiving the message? After all isn't the point of spamdyke to stop spam "before" delivery? Given the spamdyke now has the ability to check headers perhaps at least ensure that the from header's domain complies with FQDN? > As for sender verification, I've read about it and I'm not wild on the idea. Yup, which is why I said it's not that important (we wouldn't use it ourselves for the same reasons you mentioned). Kind Regards, Mark Frater -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Sam Clippinger Sent: 06 July 2012 11:25 PM To: spamdyke users Subject: Re: [spamdyke-users] Spamdyke and Postfix Very interesting. So if spamdyke had an option to filter the "MAIL FROM" command after authentication, it would need a few values: allow anything (current behavior), allow only locally hosted domains (provided by local-domains-entry and local-domains-file) or allow only the authenticated domain (if a domain name was used in the authenticating username). Would that cover everything? Most people would use the first option (or not even turn it on), I would use the second option (all of my other domains and aliases are hosted on the same server) and restrictive ISPs might use the third. If the option could be overridden in a configuration directory, admins could turn it on or off for specific domains or specific users or add non-local domains to the list for specific users. Right now, spamdyke already controls relaying for non-authenticated users by comparing the sending and receiving domains against the list of locally hosted domains. This would basically extend that functionality to also work even after authentication has succeeded. I'll give that some serious thought. This would only be a little complicated because so much of spamdyke's code assumes that authentication is like a whitelist -- once authenticated, anything is allowed. I'd have to rework that assumption in a few places, but this isn't the only kind of post-authentication filter that might be handy (several others have been suggested over the years). I'm not sure I understand your second suggestion. Isn't that basically the same as the reject-missing-sender-mx filter? Invalid domains shouldn't have MX records, so they shouldn't pass the filter. Or are you talking about the "From" line in the message header itself? I think SpamAssassin can catch that kind of abuse -- you may just need to increase the weight for that SA filter so it will automatically discard matching messages. As for sender verification, I've read about it and I'm not wild on the idea. The intent is good, but in reality I don't think it would do much or anything to stop spam. First, it's trivial to fake the sender address to use a valid address (spammers already have millions of valid addresses in their files). Second, many mail servers don't reject invalid addresses during the SMTP conversation (qmail doesn't) -- many admins consider it a security risk, since it exposes a way to check for usernames. Third, this might slow down botnet spam from random addresses, but it won't stop anything from professional spammers with their own mail servers that will accept anything (and throw it away). Most of the spam I deal with these days comes from pros, not botnets (spamdyke's rDNS filters stop botnets in their tracks, for me anyway). Fourth, this kind of callout would make a spamdyke server look like a spammer or an attacker to anyone with IDS on their network. I would be nervous about getting blacklisted by Gmail or Yahoo! (or anyone using a "spam appliance") after activating a feature like this. Fifth, despite the best attempts at caching the results, this could be easily abused as a DoS tool. Just send a mailbomb to a spamdyke server with thousands of messages from different users @foo.com -- the spamdyke server will open thousands of connections to the foo.com server to try to validate all the usernames. Or create MX records in your own domain (or in subdomains) to point to a victim server, then send the mailbomb. This seems like something better configured in a script that could do it more smartly(/slowly/carefully). I already run a script that looks for websites on servers that send me mail, then compares them against a list of known spammer website designs and blacklists servers that match. That same idea could be used here -- if an address fails, blacklist the sending server (for X hours/days) and delete the message from the local mailbox(es). All the information needed to run the test would be found in the spamdyke logs. If the script were clever enough, it could even do some statistical analysis (e.g. require X% failed addresses in Y time period before blacklisting). -- Sam Clippinger On Jul 6, 2012, at 2:36 PM, Mark Frater wrote: > Hi Sam, > > Firstly thank you so much for creating and maintaining spamdyke, it is (and will always be) an integral part of our mail setup and it does an amazing job as it stands! > > As mentioned the ability to check smtp logins against the address used in the MAIL FROM header would be a VERY valuable addition. We are an ISP and find that when user's machines are infected, this behavior, where the bot uses the client's smtp login to spam out, generally using an address that we certainly do not host, creates major issues for us, as with Qmail we have no means of preventing it. This is a big reason we were looking at Postfix given that it has this ability standard. > > If I am honest we mostly want to limit users to only be allowed to send emails from 'domains' that we do indeed host. So for example the client can login with xyz@domain and send mail from anything@domain but should not be allowed to send mail from xyz@domain-not-in-our-relay-list. It is common (as you mentioned you do so yourself) where the owner of the domain will use one valid smtp login to send mails from several 'aliases', and that is perfectly acceptable and important but they should still be limited to only the 'domain' for which they are logged in. > > This should be easy to implement since the domains can be read directly from qmail's files. > > Another feature to consider is to check the domain's fqdn and existence of said domain. We often find mails getting past spamdyke that are using domains in the from header that are not fdqn compliant (eg. [email protected] instead of [email protected]) or that simply the domains do not exist. This is again a standard feature available with postfix but missing from qmail. > > Lastly and perhaps less as important would be the sender verification process which is listed in the smtp RFC but which qmail has no standard ability to perform. Once again this is a standard feature available in postfix. > > Regards, > Mark > > On 06 Jul 2012, at 8:11 PM, Sam Clippinger <[email protected]> wrote: > >> That is an interesting idea that wouldn't be hard to implement at all. It would certainly limit spam sent from compromised email accounts where the envelope sender is different from the login. Or it would at least force the spammer to use the same sender address as the login name. Of course, there would have to be a way to provide a list of valid sender addresses for each login -- I myself use 7 different addresses in my mail client for different reasons but only one of them is "real", so that's the only one that will authenticate. But I'll make a note of it! Any other interesting features that might be handy? >> >> As for the status of turning spamdyke into a daemon, it's honestly a long way off. I want to do it -- I've wanted to do that since I first started writing spamdyke, but there are a few features ahead of it in line. >> >> Over the last several months I've had about six hours (seriously) to work on spamdyke. I've spent that time trying to debug the recipient validation code, which has so many possible configurations that it takes somewhere around 50000 test scripts to fully exercise. (Needless to say, I'm not writing those by hand -- I've written a program to generate them.) So I've spent my time trying to figure out how qmail *really* behaves (as opposed to what the documentation says) so I can test my scripts so I can test spamdyke. It's quite a slog. I really enjoy working on spamdyke and I don't want to abandon it; someday soon I'm hoping my work situation will change (for the better) and give me a little more free time. >> >> -- Sam Clippinger >> >> >> >> >> On Jul 6, 2012, at 10:34 AM, Mark Frater wrote: >> >>> Hi Mike, >>> >>> That is too much overhead just to be able to use Postfix. >>> >>> To be honest one of the biggest factors for me wanting to move to >>> Postfix over Qmail is the fact that Postfix allows >>> sender-restrictions... such as rejecting MAIL FROM to auth login mismatch as well as sender-verification. >>> >>> Would be pretty cool if spamdyke could do this! >>> >>> Kind Regards, >>> Mark >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of Michael J. >>> Colvin >>> Sent: 06 July 2012 05:14 PM >>> To: 'spamdyke users' >>> Subject: Re: [spamdyke-users] Spamdyke and Postfix >>> >>> Use Spamdyke/Qmail as a frontend and pass the filtered mail on to a >>> Postfix server if you want to use it for your customer facing stuff... Then you get >>> both. You can also use virtual servers as the Spamdyke/Qmail "frontend". >>> Remove SpamAssassin from the mix, and any old server should suffice >>> as a "Filtering" server. >>> >>> Mike >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:spamdyke-users- >>>> [email protected]] On Behalf Of Gary Gendel >>>> Sent: Friday, July 06, 2012 7:30 AM >>>> To: [email protected] >>>> Subject: Re: [spamdyke-users] Spamdyke and Postfix >>>> >>>> On 7/6/12 10:20 AM, Mark Frater wrote: >>>>> Hi guys, >>>>> >>>>> Has there been any further developments / discussions in getting >>>>> Spamdyke to run as a daemon or similar method in order to get it >>>>> to work with other MTA's such as Postfix? >>>>> >>>>> Qmail is seriously long in the tooth and no longer maintained and >>>>> for this reason more and more admins (including myself) are moving >>>>> away from it - or want to. >>>>> >>>>> I would like to move to Postfix but I'm a loyal Spamdyke fan and >>>>> as such the only thing holding me back is the fact that Spamdyke >>>>> won't >>>> work! >>>>> >>>>> Kind Regards, >>>>> Mark >>>>> >>>>> >>>> I'm not sure why you say that Qmail is "long in the tooth" since an >>>> unpatched Qmail with spamdyke front end is pretty much >>>> state-of-the- art. The fact that Qmail it is so lightweight and >>>> does exactly what is needed in an efficient and data-safe manner makes a lot of sense. >>>> >>>> That said, I wouldn't mind a Postfix/spamdyke solution but that >>>> would take a significant effort as spamdyke does things the Qmail >>>> way (uses environment variables to pass information, etc.) >>>> >>>> Gary >>>> >>>> _______________________________________________ >>>> spamdyke-users mailing list >>>> [email protected] >>>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> [email protected] >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >>> >>> _______________________________________________ >>> spamdyke-users mailing list >>> [email protected] >>> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> >> _______________________________________________ >> spamdyke-users mailing list >> [email protected] >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
