Re: Newest spammer trick - non-blank subject lines?
On Thu, 11 Feb 2010 16:40:04 -0800 Ted Mittelstaedt wrote: > case - but I sure as hell would never be foolish enough to try and > defend it. These hacks simply scream "I got mine and I don't give > a damn if you got yours", Isn't that really your position - that 5xx responses make the botnet move on to someone else. You also seem to arguing that his idea is bad because it make a botnet less efficient at delivering spam. Your argument that it doesn't scale can be applied equally well to rejecting spam per se. Even if spammers do lay-off addresses where spam filters reject at the smtp level, they can't afford to do that if it's ubiquitous.
Re: Pipe characters in From and To's
Am 11.02.2010 22:37, schrieb Spiro Harvey: > We're getting a boatload of To and From addresses starting with pipe > characters on one of our clients' mailservers. The messages themselves > don't appear particularly malicious -- the ones we've seen are just > pill spam -- but there are craploads of them. > > I was thinking about configuring an SA rule to just bump the scores up > a few points (most of those that are getting thru seem to be scoring > about 8 or 9), so adding a few points will push them into reject > territory. > > Oh, and the client has historically allowed catch-all mail domains > hence why so many of these are being delivered. We've managed to get > them to not allow catch-alls now, but they still have 20-odd-thousand > historical domains that haven't had the catch-alls removed yet.. > > So I'm just wondering if others encounter this with enough regularity, > and if so what your thoughts and advice are. I don't particularly want > to add rules into sendmail, so SA is my avenue of choice. > > Cheers > I also had a lot of load for this kind of mail until I added a header_checks rule Ralph
Re: Newest spammer trick - non-blank subject lines?
Mike Cardwell wrote: On 11/02/2010 19:29, Ted Mittelstaedt wrote: All I can see above is a long list of dubious predictions of what spammers would do if everybody used the same system as me. I can't be bothered with this thread anymore. You can't be bothered - yet you continued responding to someone else on this thread.. Uh huh. Sounds like you know I'm right and you can't think of a logical defense (since there isn't one) so your going to turn and run off with your tail between your legs. If anyone had any doubts that you weren't an inexperienced mail admin who knows just enough to be dangerous you just dispelled them. If you can't defend your hack in an open forum, then it's exactly as I said, nothing new, nothing revolutionary, just a cheap hack that only works if -one- site is doing it. I'll slip it in my file of other cheap hacks that only work if one site is doing them. Who knows maybe I might even have to use it one day for some border case - but I sure as hell would never be foolish enough to try and defend it. These hacks simply scream "I got mine and I don't give a damn if you got yours", hardly the attitude for an Internet admin to have. What exactly do you think the SA ruleset is, Mike? It is nothing more than a "dubious predictions of what spammers would do" Good Lord, and on top of that, a hijacked thread, too! Ted
Re: Newest spammer trick - non-blank subject lines?
David Morton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted Mittelstaedt wrote: The claim that amavisd* variants accept then process mail is nonsense, nobody who runs a large mailserver with amavisd could possibly have their server configured in this manner without it melting down, so please no more of this ridiculous talk. ?? Of course you 5xx reject unknown users and other low hanging fruit that identifes bad stuff - but then the rest is accepted to process later. This is exactly how most amavisd variants work. Yes, and this is exactly how everything else works, too. So what? That is not what the poster stated when he claimed that amavisd* queued everything. As I said, please no more of this rediculous talk. Ted
Re: Newest spammer trick - non-blank subject lines?
On Friday February 12 2010 00:28:24 David Morton wrote: > Of course you 5xx reject unknown users and other low hanging fruit > that identifes bad stuff - but then the rest is accepted to process > later. This is exactly how most amavisd variants work. Btw, with the most recent advances in SpamAssassin 3.3.0 (master_deadline time limiting), in Postfix (smtpd_proxy_options=speed_adjust), and in the coming amavisd-new release (warm restart, reworked time limiting), amavisd will behave much better in a pre-queue (proxy) setup when combined with Postfix and SA 3.3.0. This gives admin more choice to choose between a pre-queue and post-queue setups. Mark
Re: Newest spammer trick - non-blank subject lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ted Mittelstaedt wrote: > The claim that amavisd* variants accept then process mail > is nonsense, nobody who runs a large mailserver with amavisd could > possibly have their server configured in this manner without it melting > down, so please no more of this ridiculous talk. ?? Of course you 5xx reject unknown users and other low hanging fruit that identifes bad stuff - but then the rest is accepted to process later. This is exactly how most amavisd variants work. - -- David Morton Morton Software & Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLdJKYUy30ODPkzl0RArlNAJ9ccE6wA/XcAlmUkSr4X0AXgVaT1ACfbZpr GyD+ExM0KUAEq8jPhAfCEE4= =jbCy -END PGP SIGNATURE-
sa-learn error.
I was trying to teach spamassassin 3.3.0 today with a rather large spam message and I got this error message when I did sa-learn: Feb 11 14:47:51.262 [5414] info: archive-iterator: skipping large message The message is 279959 bytes and about 20% is Russian text and other 80% is two gif image attachment. Is there a way to increase this or some other method to allow me to learn large messages. Thank you, Frank
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 19:52, Bernd Petrovitsch wrote: >> I want you to describe a scenario where the sender or recipient are >> actually worse off because of the particular two features I've > The point is: The sender is worse off because he needs to invest time > for the workaround which is caused by the receiver. The receiver is > worse off because some senders plain simply give up when they are > expected to pass a Turing test. > No, I don't have numbers. But I'm pretty sure I'm not the only one. > >> described. You've failed to even attempt that so far. > You see only two alternatives: > - keep these two features (and tell the senders that they should > actually be happy that they can invest time and effort to work around > FPs caused by the receiver spam). > - or deactivate it. > I proposed the 3rd solution: > - repair your spam-detection (change weight/limits, use Bayes, > greylistung, etc.) to not generate so many FPs that you actually need > an additional workaround. > That would actually remove the cause and not fiddle with the symptoms. > >> I know this system works well because I've been using it for a long time. > To use your own words: Ridiculous. Just because someone uses something > for a long time doesn't make it good (or is even an indication for it). > Apart from that: You very probably don't know how many FPs didn't come > through because of people disliking Turing tests. Your assuming that my false positive rate is bad. I would be surprised if it was worse than the average on this list. It's very good. But if my additions knock 0.1% more off the rate, then I'm happy. Out. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
Bernd Petrovitsch wrote: On Don, 2010-02-11 at 18:26 +, Mike Cardwell wrote: [...] I want you to describe a scenario where the sender or recipient are actually worse off because of the particular two features I've The point is: The sender is worse off because he needs to invest time for the workaround which is caused by the receiver. The receiver is worse off because some senders plain simply give up when they are expected to pass a Turing test. No, I don't have numbers. But I'm pretty sure I'm not the only one. Hmm. I'd say the balance is slightly in favour of Mike's system - you CAN NOT *prevent* all false-positives, so providing some way to let senders know relatively quickly that their mail got caught seems to me to be a positive. Some FPs are due to the sender's attempt to avoid some other differently-broken mail system elsewhere - I got an interesting call back from someone I notified about a webform generating mail missing a Message-Id header. (I've found it to be a pretty good spamsign here to see a Message-Id generated by one of our MXes.) Apparently, they used to generate one... and somewhere along the line their colo/hosting host's outbound relays started rejecting these messages based on that Message-Id. I proposed the 3rd solution: - repair your spam-detection (change weight/limits, use Bayes, greylistung, etc.) to not generate so many FPs that you actually need an additional workaround. That would actually remove the cause and not fiddle with the symptoms. :/ Until you have a business customer whose one FP for the year was moderately time-sensitive, and which missing out on in time cost them a juicy contract and guess who they're upset at for spam-tagging that one message, never mind how much junk the filter has kept out of their inbox? -kgd
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 19:29, Ted Mittelstaedt wrote: > Secondly with regards to this reject-but-save system that Mike is > expounding on - it is an instance of a system that only works because > a few people (or one person) is doing it. It is totally worthless as > anything that can be scaled to multiple sites for a very simple reason. > > Right now one of the constants in the e-mail universe is that an error > 5xx means you failed to deliver your mail. > > If many people deploy "reject-but-save-a-copy" then this breaks that > assumption and the spammers response is extremely predictable - they > will simply assume that EVERY error 5xx carries with it a chance for > a successful delivery - so they will then program their spambots to > continually retry no matter what the error. > > Right now if their spambot gets an error 5xx it schedules the victim > address for removal - because the spambot only has a limited amount of > time it can do things on whatever host system it has hijacked, and it > can't spend time sending to addresses that are rejected when there are > so many more out there that will accept the spam. > > If you remove that assumption by having a lot of sites deploy this > hack of Mike's, then the spambots will simply continually send to > millions of nonexistent e-mail addresses on your server - because > of the chance that your running the Mike Hack and those nonexistent > addresses your telling the spambot that are nonexistent are really > existing. > > The spammers don't care that their spam is delivered to a junk mail > folder. If the user isn't automatically deleting their junkmail unread > (in which case there's no point in the Mike Hack in the first place) > then they ARE having to periodically read at least the subject lines > of messages in the Junk Mail folder. In short, the Mike Hack only has > value if the users are periodically opening up and reading the subject > lines of messages in the Junk Mail folder. > > And the spammers thought is that their spam is so attractive that > all the user has to do is read the subject line and they will open > it. They aren't thinking "my spam got delivered to someone's junk > mail folder, boo hoo" They are thinking "Zowie, my mail got delivered > to someone's folder - it's just going to be a few more weeks and I'll > be rich, yipee yipee!!" Spammers are the most optimistic people you > will ever meet. Only an optimist would think that the sewage they send > out is something that people want to read. > > Mike I'm not sure why you think this hack of yours is so clever. It's > just a cheap hack. I can think of a dozen more for filtering spam, > some I've read other people expounding on over the years as the > greatest thing since sliced bread, all of which work - and all of > which are totally unscalable. > > If you want to write a clever spam filter than write one that everyone > can use. Otherwise the more you defend this, the more you look like > an inexperienced mail admin who knows just enough to be dangerous. All I can see above is a long list of dubious predictions of what spammers would do if everybody used the same system as me. I can't be bothered with this thread anymore. Feel free to make dubious assumptions of why that may be. Out. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Bowie Bailey wrote: LuKreme wrote: On 11-Feb-2010, at 11:11, Charles Gregory wrote: It's a rant page telling the visitor that you cannot read the site using Internet Explorer, Good. Get a real browser. with major (large font) attitude that this is the fault of the browser. It is, and this is explained clearly. IE does not support (I believe has never supported and still does not support) Content-Type: application/xhtml+xml, and does not, has not, and will probably never suport SVG images (though there were no images on the original page). Who would you like to blame for this if not Microsoft IE? I would blame whoever set up the website. The page in question does not even attempt to use the features that the "fail" page refers to. IE may not be able to handle "xhtml+xml" or SVG images, but as long as it can render the page in question, who cares? That redirect should be limited to pages that actually use the features in question. The redirect states "...9 year old standard required by the web page..." so you obviously are blind, because the website developer couldn't possibly be lying. ;-) I would refer the redirect author to the section "The Myth of "HTML-compatible XHTML 1.0 documents" in the following document http://hixie.ch/advocacy/xhtml for an adult's understanding of why IE does not support it. The solution is HTML5 support in IE, and once the HTML5 people are finished wrangling amongst themselves, IE will support it. That is why Microsoft joined the SVG working group of w3c last month - because now with Adobe pulling their support of their SVG IE plugin last year, it looks like we finally might have some movement in that B.M. called HTML5. The fact is the 4.01 standard is over a decade old. If the HTML5 people had agreed on a set of standards 5 years ago then we would have support for SVG and XHTML it in IE today. The second fact is that if MS HAD supported SVG and XHTML then the W3C would have come under tremendous pressure to force out that HTML5 standard. I don't think they would have liked that any better. Ted
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, Bowie Bailey wrote: I would blame whoever set up the website. The page in question does not even attempt to use the features that the "fail" page refers to. (nod) I guess that really says it all Thanks for mentioning this. Now my 'vague feeling' is confirmed. - C
Pipe characters in From and To's
We're getting a boatload of To and From addresses starting with pipe characters on one of our clients' mailservers. The messages themselves don't appear particularly malicious -- the ones we've seen are just pill spam -- but there are craploads of them. I was thinking about configuring an SA rule to just bump the scores up a few points (most of those that are getting thru seem to be scoring about 8 or 9), so adding a few points will push them into reject territory. Oh, and the client has historically allowed catch-all mail domains hence why so many of these are being delivered. We've managed to get them to not allow catch-alls now, but they still have 20-odd-thousand historical domains that haven't had the catch-alls removed yet.. So I'm just wondering if others encounter this with enough regularity, and if so what your thoughts and advice are. I don't particularly want to add rules into sendmail, so SA is my avenue of choice. Cheers -- Spiro Harvey Knossos Networks Ltd 021-295-1923 www.knossos.net.nz signature.asc Description: PGP signature
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 02/11, Henrik K wrote: > method of whitelisting. You can't seriously expect to block on some > attribute that not everyone can or bothers to change (DNS). None of this Correct. I am not suggesting that anyone block anything based on MTX at this time. I suggest using it for whitelisting (small negative score, not absolute whitelisting) alone until it is more broadly in use. This is clearly stated in the Implementation Sequence: Conservative people use these new tests to reduce false positives: score MTX_BL 1 score MTX_PASS -1 # Only hit if MTX_BL wasn't. score MTX_FAIL 0.001 Except for those who are willing to cause a small number of false positives, like me. I can, and do, score more harshly those emails that do not have MTX records. And the senders get an error mentioning the option of MTX. All the emails that have been hit seemed likely to be spam. For example, this list gets through just fine with these settings: score MTX_PASS -100 score MTX_FAIL 2 As to the problem of freemail, sites that send both non-spam and spam, constantly, I think that necessitates a blacklist that allows you to define a score per domain (of the PTR record of the sending IP). So, for example, you could blacklist hotmail to only negate the benefit of them having an MTX record, so for hotmail, the net result would be 0. It's funny how, for just believing I may have come up with an idea that is new and useful for dealing with spam, I am consistently attacked. Because people often believe that, and they're almost always wrong. I can't blame you, purely statistically speaking, I'm probably wrong. And I assure you that fact has not slipped my mind. -- "Let's just say that if complete and utter chaos was lightning, then he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'." - The Color of Magic http://www.ChaosReigns.com
Re: [sa] Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, LuKreme wrote: It's a rant page telling the visitor that you cannot read the site using Internet Explorer, Good. Get a real browser. Like I said, he (and you) can rant all you want about the evils of Microsoft, and frankly I wouldn't be inclined to argue with you. (grin) But the moment someone posts a link that purports to lead to *content* and replaces that content with (essentially) a political *rant*, and does so only on the basis of that same policitcal BS, then they are no better than the spammer who uses his latest clever trick to get political spam into my mailbox. Quiet ironic for a discussion on an anti-spam list. :) - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, LuKreme wrote: Erm.. The string "microsoft" doesn't even exist on that page. "No Microsoft browser supports this 9 year old standard." Obviously you are't using IE and so you weren't subjected to the arrogant refusal of his server to deliver the requested page. (shrug) - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
LuKreme wrote: > On 11-Feb-2010, at 11:11, Charles Gregory wrote: > >> It's a rant page telling the visitor that you cannot read the site using >> Internet Explorer, >> > > Good. Get a real browser. > > >> with major (large font) attitude that this is the fault of the browser. >> > > It is, and this is explained clearly. IE does not support (I believe has > never supported and still does not support) Content-Type: > application/xhtml+xml, and does not, has not, and will probably never suport > SVG images (though there were no images on the original page). > > Who would you like to blame for this if not Microsoft IE? > I would blame whoever set up the website. The page in question does not even attempt to use the features that the "fail" page refers to. IE may not be able to handle "xhtml+xml" or SVG images, but as long as it can render the page in question, who cares? That redirect should be limited to pages that actually use the features in question. -- Bowie
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 11-Feb-2010, at 11:11, Charles Gregory wrote: > > It's a rant page telling the visitor that you cannot read the site using > Internet Explorer, Good. Get a real browser. > with major (large font) attitude that this is the fault of the browser. It is, and this is explained clearly. IE does not support (I believe has never supported and still does not support) Content-Type: application/xhtml+xml, and does not, has not, and will probably never suport SVG images (though there were no images on the original page). Who would you like to blame for this if not Microsoft IE? -- I WILL NOT FAKE MY WAY THROUGH LIFE Bart chalkboard Ep. 7F03
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 11-Feb-2010, at 09:55, Charles Gregory wrote: > > You are welcome to your opinions on browsers, and are free to whine about the > evils of microsoft all you want, but if you are going to post a link > with the intent for the 'average' person to read it, then you better make it > *accessible* to that average person. Erm.. The string "microsoft" doesn't even exist on that page. -- 'Have you lost your senses?' 'Yes, but I may have found some better ones.' --Interesting Times
Re: Spam filtering similar to SPF, less breakage
Matus UHLAR - fantomas wrote: >> Matus UHLAR - fantomas wrote: >> > Imho, SPF does NOT break forwarding. > > On 11.02.10 19:37, Per Jessen wrote: >> Hmm, the SRS people seem to disagree: >> >> http://www.openspf.org/SRS : SPF "breaks" email forwarding. > > I think those quotes say it all. SRS is a way to create correct and > trackable forwarding, SPF or not. Well, I'll just note that SRS was invented exclusively because of SPF, not because of any critical/actual problems in email forwarding. What is hindering SPF adoption is also a distinct lack of development on the SRS front, notably in getting a workable/performant setup for a major mailserver such as postfix. > The forwarding without changing sender is imho already broken, > however the breakage gets visible with SPF adoption. > Just my opinion, but I would tend to think that SPF broke it then. /Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 18:26 +, Mike Cardwell wrote: [...] > I want you to describe a scenario where the sender or recipient are > actually worse off because of the particular two features I've The point is: The sender is worse off because he needs to invest time for the workaround which is caused by the receiver. The receiver is worse off because some senders plain simply give up when they are expected to pass a Turing test. No, I don't have numbers. But I'm pretty sure I'm not the only one. > described. You've failed to even attempt that so far. You see only two alternatives: - keep these two features (and tell the senders that they should actually be happy that they can invest time and effort to work around FPs caused by the receiver spam). - or deactivate it. I proposed the 3rd solution: - repair your spam-detection (change weight/limits, use Bayes, greylistung, etc.) to not generate so many FPs that you actually need an additional workaround. That would actually remove the cause and not fiddle with the symptoms. > I know this system works well because I've been using it for a long time. To use your own words: Ridiculous. Just because someone uses something for a long time doesn't make it good (or is even an indication for it). Apart from that: You very probably don't know how many FPs didn't come through because of people disliking Turing tests. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
Mike Cardwell wrote: On 11/02/2010 17:08, Bernd Petrovitsch wrote: Let me explain this in simple terms. Normal behaviour: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. Spam filtering rejects valid non-spam because it mis-identified it as "spam". Yes. It's called a "false positive". Behaviour on my system: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. But ... the recipient can Spam filtering rejects valid non-spam because it mis-identified it as "spam". Now *I* have to do something to work around *Your* buggy/screwed spamcheck. No different to a normal situation where the features I've described aren't in place. You just have to hope that I´m really, really that interested to my mail through. If it's an answer per PM to e.g. typical ML mails (like this here), you would loose. No different to a normal situation where the features I've described aren't in place. still access the email if it's something they were expecting, *and* if the sender still wants to contact the recipient they now have an *extra* option to make their life easier - they can click a URL and fill in a captcha. So ... my system provides 2 extra little features which makes some senders and some recipients lives more easy. No, you are pushing effort from your side out to others. If you want to do something for the (valid) sender, fix the FP rate by changing whatever it needs so that my on-spam mail gets through. Ridiculous claim. In a normal situation the effort relies on the sender to get their mail through after a false positive occurs, or it wont get through at all. With the 2 features I described, the sender is provided with an extra simple option to get the mail through, and the recipient has also been provided with an option to get the mail through. Neither sender nor recipient would benefit from me removing those features from my system. Of course anyone can do as they think it´s best. But that doesn´t imply that other think the same. I want you to describe a scenario where the sender or recipient are actually worse off because of the particular two features I've described. You've failed to even attempt that so far. I know this system works well because I've been using it for a long time. I'm going to make 2 points here since you all hijacked my thread for this discussion, I feel I have the right to. ;-) First of all with regards to accepting then processing mail, that's bogus. It's imperative to issue an error 5xx to the sending server before the server closes TCP connection, if your going to reject the mail. Otherwise if you accept the message, your telling the spammer that they have a valid e-mail address, even if such a recipient address does not exist on your system, and your then encouraging them to spam. The claim that amavisd* variants accept then process mail is nonsense, nobody who runs a large mailserver with amavisd could possibly have their server configured in this manner without it melting down, so please no more of this ridiculous talk. Secondly with regards to this reject-but-save system that Mike is expounding on - it is an instance of a system that only works because a few people (or one person) is doing it. It is totally worthless as anything that can be scaled to multiple sites for a very simple reason. Right now one of the constants in the e-mail universe is that an error 5xx means you failed to deliver your mail. If many people deploy "reject-but-save-a-copy" then this breaks that assumption and the spammers response is extremely predictable - they will simply assume that EVERY error 5xx carries with it a chance for a successful delivery - so they will then program their spambots to continually retry no matter what the error. Right now if their spambot gets an error 5xx it schedules the victim address for removal - because the spambot only has a limited amount of time it can do things on whatever host system it has hijacked, and it can't spend time sending to addresses that are rejected when there are so many more out there that will accept the spam. If you remove that assumption by having a lot of sites deploy this hack of Mike's, then the spambots will simply continually send to millions of nonexistent e-mail addresses on your server - because of the chance that your running the Mike Hack and those nonexistent addresses your telling the spambot that are nonexistent are really existing. The spammers don't care that their spam is delivered to a junk mail folder. If the user isn't automatically deleting their junkmail unread (in which case there's no point in the Mike Hack in the first place) then they ARE having to periodically read at least the subject lines of messages in the Junk Mail folder. In short, the Mike Hack only has value if the users are periodically opening up and reading the subject lines of messages in the
Re: Spam filtering similar to SPF, less breakage
On 11/02/2010 18:52, Matus UHLAR - fantomas wrote: >>> Imho, SPF does NOT break forwarding. > > On 11.02.10 19:37, Per Jessen wrote: >> Hmm, the SRS people seem to disagree: >> >> http://www.openspf.org/SRS : SPF "breaks" email forwarding. > > I think those quotes say it all. SRS is a way to create correct and > trackable forwarding, SPF or not. > > The forwardind without changing sender is imho already broken, however the > breakage gets visible with SPF adoption. Yes. A more accurate statement than, "SPF breaks forwarding," would be, "Broken forwarding is incompatible with SPF." -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Spam filtering similar to SPF, less breakage
> Matus UHLAR - fantomas wrote: > > Imho, SPF does NOT break forwarding. On 11.02.10 19:37, Per Jessen wrote: > Hmm, the SRS people seem to disagree: > > http://www.openspf.org/SRS : SPF "breaks" email forwarding. I think those quotes say it all. SRS is a way to create correct and trackable forwarding, SPF or not. The forwardind without changing sender is imho already broken, however the breakage gets visible with SPF adoption. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam is for losers who can't get business any other way.
Re: Spam filtering similar to SPF, less breakage
Matus UHLAR - fantomas wrote: > On 09.02.10 11:42, dar...@chaosreigns.com wrote: >> I apparently need to clarify that I think this is a good idea because >> I am concerned about the number of people (who control DNS records) >> who are very strongly against creating SPF records specifically >> because of forwarding >> breakage. The email I got in response to my request for my employer >> to >> create an SPF record included the word "abomination". From a friend. >> I don't entirely agree, but it is a problem for adoption. >> >> This is entirely an attempt to replicate the functionality of SPF >> without breaking forwarding, and without causing other problems that >> might discourage adoption. > > Imho, SPF does NOT break forwarding. Hmm, the SRS people seem to disagree: http://www.openspf.org/SRS : SPF "breaks" email forwarding. /Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 17:08, Bernd Petrovitsch wrote: >> Let me explain this in simple terms. >> >> Normal behaviour: >> >> Spam filtering causes a 5xx rejection. You get an NDR. You either >> contact the user some other way or not at all. > Spam filtering rejects valid non-spam because it mis-identified it as > "spam". Yes. It's called a "false positive". >> Behaviour on my system: >> >> Spam filtering causes a 5xx rejection. You get an NDR. You either >> contact the user some other way or not at all. But ... the recipient can > Spam filtering rejects valid non-spam because it mis-identified it as > "spam". Now *I* have to do something to work around *Your* buggy/screwed > spamcheck. No different to a normal situation where the features I've described aren't in place. > You just have to hope that I´m really, really that interested to my mail > through. If it's an answer per PM to e.g. typical ML mails (like this > here), you would loose. No different to a normal situation where the features I've described aren't in place. >> still access the email if it's something they were expecting, *and* if >> the sender still wants to contact the recipient they now have an *extra* >> option to make their life easier - they can click a URL and fill in a >> captcha. >> >> So ... my system provides 2 extra little features which makes some >> senders and some recipients lives more easy. > No, you are pushing effort from your side out to others. If you want to > do something for the (valid) sender, fix the FP rate by changing > whatever it needs so that my on-spam mail gets through. Ridiculous claim. In a normal situation the effort relies on the sender to get their mail through after a false positive occurs, or it wont get through at all. With the 2 features I described, the sender is provided with an extra simple option to get the mail through, and the recipient has also been provided with an option to get the mail through. >> Neither sender nor recipient would benefit from me removing those >> features from my system. > Of course anyone can do as they think it´s best. But that doesn´t imply > that other think the same. I want you to describe a scenario where the sender or recipient are actually worse off because of the particular two features I've described. You've failed to even attempt that so far. I know this system works well because I've been using it for a long time. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: [sa] Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, Bowie Bailey wrote: What page were you looking at? All I see at that URL is a fairly straightforward description of how to implement his MTX system. The page 'redirects' to this one: http://www.chaosreigns.com/fail It's a rant page telling the visitor that you cannot read the site using Internet Explorer, with major (large font) attitude that this is the fault of the browser. - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 06:42:44PM +0100, Matus UHLAR - fantomas wrote: > > > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > > > > http://www.chaosreigns.com/mtx/ > > > > On 11.02.10 16:06, Henrik K wrote: > > > > What a complex scheme you invented for a simple problem. All you have > > > > to do > > > > is to require legimate relays to have a FCrDNS entry with an actually > > > > identifiable name, like starting with "smtp". Much simpler to take > > > > advantage > > > > of that and it actually is somewhat used today. > > > On Thu, Feb 11, 2010 at 06:25:07PM +0100, Matus UHLAR - fantomas wrote: > > > ok, I should do an s/^ip-/smtp-/ on all our clients' ips... > > On 11.02.10 19:34, Henrik K wrote: > > I don't know if there's some joke included or whatever. If they are sending > > mail, then yes having a good PTR will result in less greylisting etc. > > of course > ip-212-081-019-000.static.nextra.sk. > > well, dynamic addresses are listed differently: > > dial-195-168-160-000.dynamic.nextra.sk. > adsl-195-168-244-000.dynamic.nextra.sk. > > so probably > s/^(dial|adsl|ip)-/smtp-/ > > there are _many_ mailservers not having name indicating they are used for > mail and I don't think any form of requiring them to have such name is a > good idea... If the "owner" of such IP wants, he will order the change (if possible). No one is _requiring_ them to have any name, but what name do you think will pass the most mail? If you are the ISP, it's not your job to start changing anything without notice.
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 11:52 +, Mike Cardwell wrote: [...] > Let me explain this in simple terms. > > Normal behaviour: > > Spam filtering causes a 5xx rejection. You get an NDR. You either > contact the user some other way or not at all. Spam filtering rejects valid non-spam because it mis-identified it as "spam". > Behaviour on my system: > > Spam filtering causes a 5xx rejection. You get an NDR. You either > contact the user some other way or not at all. But ... the recipient can Spam filtering rejects valid non-spam because it mis-identified it as "spam". Now *I* have to do something to work around *Your* buggy/screwed spamcheck. You just have to hope that I´m really, really that interested to my mail through. If it's an answer per PM to e.g. typical ML mails (like this here), you would loose. > still access the email if it's something they were expecting, *and* if > the sender still wants to contact the recipient they now have an *extra* > option to make their life easier - they can click a URL and fill in a > captcha. > > So ... my system provides 2 extra little features which makes some > senders and some recipients lives more easy. No, you are pushing effort from your side out to others. If you want to do something for the (valid) sender, fix the FP rate by changing whatever it needs so that my on-spam mail gets through. > Neither sender nor recipient would benefit from me removing those > features from my system. Of course anyone can do as they think it´s best. But that doesn´t imply that other think the same. Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
> > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > > > http://www.chaosreigns.com/mtx/ > > On 11.02.10 16:06, Henrik K wrote: > > > What a complex scheme you invented for a simple problem. All you have to > > > do > > > is to require legimate relays to have a FCrDNS entry with an actually > > > identifiable name, like starting with "smtp". Much simpler to take > > > advantage > > > of that and it actually is somewhat used today. > On Thu, Feb 11, 2010 at 06:25:07PM +0100, Matus UHLAR - fantomas wrote: > > ok, I should do an s/^ip-/smtp-/ on all our clients' ips... On 11.02.10 19:34, Henrik K wrote: > I don't know if there's some joke included or whatever. If they are sending > mail, then yes having a good PTR will result in less greylisting etc. of course ip-212-081-019-000.static.nextra.sk. well, dynamic addresses are listed differently: dial-195-168-160-000.dynamic.nextra.sk. adsl-195-168-244-000.dynamic.nextra.sk. so probably s/^(dial|adsl|ip)-/smtp-/ there are _many_ mailservers not having name indicating they are used for mail and I don't think any form of requiring them to have such name is a good idea... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 06:25:07PM +0100, Matus UHLAR - fantomas wrote: > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > > http://www.chaosreigns.com/mtx/ > > On 11.02.10 16:06, Henrik K wrote: > > What a complex scheme you invented for a simple problem. All you have to do > > is to require legimate relays to have a FCrDNS entry with an actually > > identifiable name, like starting with "smtp". Much simpler to take advantage > > of that and it actually is somewhat used today. > > ok, I should do an s/^ip-/smtp-/ on all our clients' ips... I don't know if there's some joke included or whatever. If they are sending mail, then yes having a good PTR will result in less greylisting etc.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
> On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > http://www.chaosreigns.com/mtx/ On 11.02.10 16:06, Henrik K wrote: > What a complex scheme you invented for a simple problem. All you have to do > is to require legimate relays to have a FCrDNS entry with an actually > identifiable name, like starting with "smtp". Much simpler to take advantage > of that and it actually is somewhat used today. ok, I should do an s/^ip-/smtp-/ on all our clients' ips... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
From: Charles Gregory Date: Thu, 11 Feb 2010 11:55:10 -0500 (EST) On Wed, 10 Feb 2010, dar...@chaosreigns.com wrote: > http://www.chaosreigns.com/mtx/ You know, just for a moment I thought I would take a look, just for curiosity sake, and instead got this moronic jack-ass ATTITUDE page. Heh. Using IE 7.0 I get: Your browser cannot handle the 9 year old standard required by the web page you attempted to access. ... IE 7.0 displays the page fine, but you have to save the file out as a plain html file. -jeff
Re: Spam filtering similar to SPF, less breakage
On 09.02.10 11:42, dar...@chaosreigns.com wrote: > I apparently need to clarify that I think this is a good idea because I am > concerned about the number of people (who control DNS records) who are very > strongly against creating SPF records specifically because of forwarding > breakage. The email I got in response to my request for my employer to > create an SPF record included the word "abomination". From a friend. > I don't entirely agree, but it is a problem for adoption. > > This is entirely an attempt to replicate the functionality of SPF without > breaking forwarding, and without causing other problems that might > discourage adoption. Imho, SPF does NOT break forwarding. It only causes the broken forwarding to be rejected. If I forward your mail to other address from my aliases/virtuser/.forward/.procmailrc/whatever file, It is already not you who sent the mail (although the mail is from you and POSSIBLY not modified). Thus, I should rewrite the from address to indicate the mail is from me (nobody really needs to trust me the mail is from you, unless it's DKIM/PGP/SMIME signed). > I set this up for my mail server (using mtx instead of designatedsender): > > $ host -t PTR 64.71.152.40 > 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. > > $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com > 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 So you define the IP 64.71.152.40 as OK when sending mail from @panic.chaosreigns.com. address. so it's the exactly same as panic.chaosreigns.com. IN SPF "v=spf1 a:64.71.152.40 -all" > I'll define it slightly differently: > 127.0.0.1 is a pass (negative SA score). > not found is a fail (positive SA score). what means "not found"? "66.3.168.195.mtx.panic.chaosreigns.com not found" would mean I'm not allowed to mail from "panic.chaosreigns.com" address? Or will my server be allowed to mail from your domain? Because SPF above defines this mail to be rejected and nonexistance of the mtx record would do the same, even it it's your forwarded e-mail. > 127.0.0.0 is a fail (positive SA score). > Anything else is undefined (0 SA score) for future options. > I'd still appreciate feedback on the format of the A record. ... > >> Is there any way this wouldn't be very useful? > > > > Is there any place where SPF does not do the same job, other than mail > > forwarding? > > No. But as I said, I am concerned about the potential for wide spread > adoption of SPF due to forwarding breakage enough that I think this would > be much more useful. So, since you don't believe SPF to be widely adopted, you expect your way to be adopted? And all admins must adopt that? Even if they did not adopt SPF/DKIM for a few years they exist? > > On 08.02.10 22:08, dar...@chaosreigns.com wrote: > > > So it's not tied to the SMTP MAIL FROM or anything. > > > Forwarding doesn't break. > On 02/09, Matus UHLAR - fantomas wrote: > > What do you mean by this? > > Do you want to implement new way of defining which hosts are permitted to > > send e-mail? > > Yes. > > There already are attempts to do this, with false positives and > > negatives. > > How is this not better than the other attempts? the correct question is "hwo is this better?". Creating not better system is useless. > > Yours is a bit complicated > > How is it complicated? You need to create 1 record per sending mail > server, in the form: > > .mtx. > > (And the IP needs to be reversed as in all other A records that list IPs.) that's what I call complicated. SPF designs the same by using much easier way, using existing A/MX/PTR records, CIDR ranges, including other SPF records... > > and new which means everyone would > > need to implement this (otherwise he'd get false positives on his outgoing > > mail). > > Yes. http://www.rhyolite.com/anti-spam/you-might-be.html#programmer http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5 which one applies to you? :) > > Therefore I think it won't work this way. > > This is why I said SA scores for a fail should be small at first. > > > Do you see any reason this wouldn't be more quickly adopted than SPF? yes, I think this ain't any better than SPF. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 11:57:47AM -0500, Bowie Bailey wrote: > dar...@chaosreigns.com wrote: > > On 02/11, Henrik K wrote: > > > >> What a complex scheme you invented for a simple problem. All you have to do > >> is to require legimate relays to have a FCrDNS entry with an actually > >> identifiable name, like starting with "smtp". Much simpler to take > >> advantage > >> of that and it actually is somewhat used today. > >> > > > > I did consider this, but I didn't think it was reasonable to expect people > > to change the host names of their transmitting mail servers. MTX has > > the advantage of only listing mail servers that transmit legitimately, not > > including servers that only receive, although it might be a distinction > > worth losing in exchange for increased adoption. > > > > And you do think it is reasonable to expect people to create an entirely > new DNS subtree? > > Personally, I would rather change the server name. Yeah and lets not forget that what we are looking at is just "another" method of whitelisting. You can't seriously expect to block on some attribute that not everyone can or bothers to change (DNS). None of this allows skipping scanning completely anyway (freemails etc? hello?). So it's pointless given that there are already bunch of methods that are easier. Not to mention the proposed "blacklisting" that can and has been done without "MTX".
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Charles Gregory wrote: > On Wed, 10 Feb 2010, dar...@chaosreigns.com wrote: >> http://www.chaosreigns.com/mtx/ > > You know, just for a moment I thought I would take a look, just for > curiosity sake, and instead got this moronic jack-ass ATTITUDE page. What page were you looking at? All I see at that URL is a fairly straightforward description of how to implement his MTX system. > You are welcome to your opinions on browsers, and are free to whine > about the evils of microsoft all you want, but if you are going to > post a link > with the intent for the 'average' person to read it, then you better > make it *accessible* to that average person. The page renders fine for me on Linux/Firefox... -- Bowie
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Wed, 10 Feb 2010, dar...@chaosreigns.com wrote: http://www.chaosreigns.com/mtx/ You know, just for a moment I thought I would take a look, just for curiosity sake, and instead got this moronic jack-ass ATTITUDE page. You are welcome to your opinions on browsers, and are free to whine about the evils of microsoft all you want, but if you are going to post a link with the intent for the 'average' person to read it, then you better make it *accessible* to that average person. Otherwise, you are just being arrogant and rude, and deserve nothing more than a hearty F__K YOU and blacklisting for wasting everyone's time. Don't bother replying to this post, you are officialy dev/nulled (I would delight in bouncing your sorry opinions back to you, but they wouldn't go back to you, they would go back to the list). - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
dar...@chaosreigns.com wrote: > On 02/11, Henrik K wrote: > >> What a complex scheme you invented for a simple problem. All you have to do >> is to require legimate relays to have a FCrDNS entry with an actually >> identifiable name, like starting with "smtp". Much simpler to take advantage >> of that and it actually is somewhat used today. >> > > I did consider this, but I didn't think it was reasonable to expect people > to change the host names of their transmitting mail servers. MTX has > the advantage of only listing mail servers that transmit legitimately, not > including servers that only receive, although it might be a distinction > worth losing in exchange for increased adoption. > And you do think it is reasonable to expect people to create an entirely new DNS subtree? Personally, I would rather change the server name. > I encourage you to get your method standardized. It might work better. > In the mean time, I think mine has a better chance of adoption because > there is no reason not to create the records. > > Perhaps I should consider ".smtp." in a hostname a "pass" for MTX? > I'd prefer not to use that particular string since it's associated with > receiving servers more than transmitting. I'd be tempted to do ".mtx.", > except I'm concerned about administrators unaware of it allowing spammers > to have hostnames including it. Same for ".smtp.", actually. I like > the separate MTX record because it's very explicit identification of a > legitimate transmitting mail server. > "mail" and "mta" are also fairly common. And don't forget things like "smtp01", "smtp02", etc. -- Bowie
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 16:23, David Morton wrote: On this system, not much. On the scale of about 6,000 messages a day. Very light duty then. :) Even if SpamAssassin isn't used during SMTP, there's nothing stopping somebody who wants to DOS you from just setting their DOS tool to hold open connections and spend lots of time waiting between issuing SMTP commands... It could even go straight through to the DATA phase and send a 10MB email at a speed of 1 byte per second. True, though most MTA's have some defenses built for this, but waiting to scan for spam by nature takes time, and so these defenses must be lowered to allow it. I don't think moving SpamAssassin to after the SMTP transaction has finished would help prevent someone from performing a DOS. If you *can* do SMTP time spam scanning, then that's the best place for it. - From experience with larger ISP settings, and some large enterprise settings, it doesn't take a malicious attempt - normal traffic can be bursty and bring a system to its knees. From a practical standpoint, it's just a whole lot easier to have the front line smtpd servers swallow the email as fast as possible (some quick rbl or greylisting aside) and then you can process in batches behind the lines. It's scary when email starts piling up faster than all your scanners can chew... but most admins I've met would prefer that to other mail servers getting connection errors and possible bouncing or sending problem reports back to the sender. I must admit, I have seen this several times before. Looking at the logs on our servers at work we've rejected on average 151 emails per minute for the past week. We do SpamAssassin scanning during SMTP here as well and the vast majority of the time it's fine, but it does cause problems during spikes. To me this just says that we don't have enough servers to deal with the spikes, but it happens infrequently enough that it's not worth investing. I still think SMTP time scanning is both practical and desirable. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Cardwell wrote: > On this system, not much. On the scale of about 6,000 messages a day. Very light duty then. :) > Even if SpamAssassin isn't used during SMTP, there's nothing stopping > somebody who wants to DOS you from just setting their DOS tool to hold > open connections and spend lots of time waiting between issuing SMTP > commands... It could even go straight through to the DATA phase and send > a 10MB email at a speed of 1 byte per second. True, though most MTA's have some defenses built for this, but waiting to scan for spam by nature takes time, and so these defenses must be lowered to allow it. > I don't think moving SpamAssassin to after the SMTP transaction has > finished would help prevent someone from performing a DOS. > > If you *can* do SMTP time spam scanning, then that's the best place for it. - From experience with larger ISP settings, and some large enterprise settings, it doesn't take a malicious attempt - normal traffic can be bursty and bring a system to its knees. From a practical standpoint, it's just a whole lot easier to have the front line smtpd servers swallow the email as fast as possible (some quick rbl or greylisting aside) and then you can process in batches behind the lines. It's scary when email starts piling up faster than all your scanners can chew... but most admins I've met would prefer that to other mail servers getting connection errors and possible bouncing or sending problem reports back to the sender. - -- David Morton Morton Software & Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLdC8CUy30ODPkzl0RAlSnAJ4tjvtTkZnfTSt3xyDMsMx/A0565wCfb1GT qgz12JDzpApjgoLmcN208e8= =XivG -END PGP SIGNATURE-
Re: Newest spammer trick - non-blank subject lines?
On Thu, Feb 11, 2010 at 09:49:32AM -0600, David Morton wrote: > > This is why amavisd* variants always accept the mail and then process You are wrong: amavisd-milter works fine here. Pre-queue filtering is generally well understood with it's pros and cons, no point taking it up here.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 02/11, Henrik K wrote: > What a complex scheme you invented for a simple problem. All you have to do > is to require legimate relays to have a FCrDNS entry with an actually > identifiable name, like starting with "smtp". Much simpler to take advantage > of that and it actually is somewhat used today. I did consider this, but I didn't think it was reasonable to expect people to change the host names of their transmitting mail servers. MTX has the advantage of only listing mail servers that transmit legitimately, not including servers that only receive, although it might be a distinction worth losing in exchange for increased adoption. I encourage you to get your method standardized. It might work better. In the mean time, I think mine has a better chance of adoption because there is no reason not to create the records. Perhaps I should consider ".smtp." in a hostname a "pass" for MTX? I'd prefer not to use that particular string since it's associated with receiving servers more than transmitting. I'd be tempted to do ".mtx.", except I'm concerned about administrators unaware of it allowing spammers to have hostnames including it. Same for ".smtp.", actually. I like the separate MTX record because it's very explicit identification of a legitimate transmitting mail server. -- "When in doubt, gas it. It may not solve the problem, But it ends the suspense." - Steve Moonitz, DoD #2319, 1994 http://www.ChaosReigns.com
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 15:49, David Morton wrote: At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only What kind of mail load do you service? On this system, not much. On the scale of about 6,000 messages a day. It takes a significant amount of time for spamassassin to process a message, and holding the connection open during that time can easily allow for a DoS by flooding your mail server with connections. This is why amavisd* variants always accept the mail and then process - it helps keep the incoming smtpd process from jamming. SpamAssassin seems to average about 5 seconds per message here. I have other light weight checks which take place before spamassassin as well. Even if SpamAssassin isn't used during SMTP, there's nothing stopping somebody who wants to DOS you from just setting their DOS tool to hold open connections and spend lots of time waiting between issuing SMTP commands... It could even go straight through to the DATA phase and send a 10MB email at a speed of 1 byte per second. I don't think moving SpamAssassin to after the SMTP transaction has finished would help prevent someone from performing a DOS. If you *can* do SMTP time spam scanning, then that's the best place for it. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Cardwell wrote: > At SMTP time I return a 5xx code during the "DATA" phase for messages > classified as Spam. However, I also deliver the message into a read only What kind of mail load do you service? It takes a significant amount of time for spamassassin to process a message, and holding the connection open during that time can easily allow for a DoS by flooding your mail server with connections. This is why amavisd* variants always accept the mail and then process - it helps keep the incoming smtpd process from jamming. - -- David Morton Morton Software & Design http://www.dgrmm.net - Ruby on Rails PHP Applications Maia Mailguard http://www.maiamailguard.com- Spam management for mail servers -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLdCcMUy30ODPkzl0RAvn8AKDGCHegd5F+GxMT0+6yTWBV0qtDZQCeMMXg oLBV5aIBYMqx9wH5VACx57s= =/4HM -END PGP SIGNATURE-
Re: Newest spammer trick - non-blank subject lines?
On 2/11/2010 8:08 AM, Per Jessen wrote: > The only minor issue I see is that a lot > of people don't understand NDRs (or can't be bothered to try to). True. Also, a lot of mail relays mangle NDR's beyond usability.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 03:45:32PM +0100, Per Jessen wrote: > Henrik K wrote: > > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com > > wrote: > >> http://www.chaosreigns.com/mtx/ > > > > What a complex scheme you invented for a simple problem. All you have > > to do is to require legimate relays to have a FCrDNS entry with an > > actually identifiable name, like starting with "smtp". Much simpler to > > take advantage of that and it actually is somewhat used today. > > Hmm, yeah - > > Draxus' proposal: publish a DNS record identifying an IP-address as one > of your mail-servers. > > Henrik: name your mail-server such that is identifiable as a > mailserver. And yeah, I know: my method requires you to dedicate the possibly only PTR you have to some use (since multiple are discouraged and broken). But it's already a known good manner. The MTX proposal adds pretty much no value and has zero chance for widespread adoption.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Henrik K wrote: > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com > wrote: >> http://www.chaosreigns.com/mtx/ > > What a complex scheme you invented for a simple problem. All you have > to do is to require legimate relays to have a FCrDNS entry with an > actually identifiable name, like starting with "smtp". Much simpler to > take advantage of that and it actually is somewhat used today. Hmm, yeah - Draxus' proposal: publish a DNS record identifying an IP-address as one of your mail-servers. Henrik: name your mail-server such that is identifiable as a mailserver. /Per Jessen, Zürich
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > http://www.chaosreigns.com/mtx/ What a complex scheme you invented for a simple problem. All you have to do is to require legimate relays to have a FCrDNS entry with an actually identifiable name, like starting with "smtp". Much simpler to take advantage of that and it actually is somewhat used today.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 02/11, --[ UxBoD ]-- wrote: > Like the simplicity and it does appear to be a great idea. Why do you > believe SPF or DKIM generate breakage ? Thank you. SPF breakage occurs where a user has configured one of their email addresses to automatically forward their mail to another of their email addresses, and this is (commonly) handled without rewriting the "envelope from". So it fails SPF checking because the forwarding server's IP does not match the "envelope from" domain's SPF record. Also, enough people seem to be offended by the solution to this problem of rewriting the envelope from that it is a significant barrier to adoption. At the moment I do not believe DKIM style solutions cause breakage. Honestly I have not looked into them enough. But as you said: Simplicity. At a brief glance, MTX does not have the problems listed here: http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Weaknesses (message replay, arbitrary forwarding, breakage by (mailing list) modification of email, CPU overhead) -- "When we remember we are all mad, the mysteries of life disappear and life stands explained." - Mark Twain http://www.ChaosReigns.com
Re: Newest spammer trick - non-blank subject lines?
RW wrote: >> > >> > Bob could also have just clicked the link in the NDR. >> Some people - e.g. /me - do not try to pass Turing tests. Obviously >> you are not interested in my mails anyway > > But it's only applied to mail classified as spam, and unlike CR it > generates no additional backscatter. > >> Apart from that why should I decode captchas from some random site? >> After all, they could come from a third site so that people solve >> them to the the other can log automatically into the third one ... > > Because the NDR is generated by *your* mail server in response to > *your* email. > > I think it's rather a good idea. I agree, it's not bad at all. The only minor issue I see is that a lot of people don't understand NDRs (or can't be bothered to try to). /Per Jessen, Zürich
Re: Newest spammer trick - non-blank subject lines?
On Thu, 11 Feb 2010 12:26:03 +0100 Bernd Petrovitsch wrote: > On Don, 2010-02-11 at 10:38 +, Mike Cardwell wrote: > > On 11/02/2010 08:27, LuKreme wrote: > > >> At SMTP time I return a 5xx code during the "DATA" phase for > > >> messages classified as Spam. However, I also deliver the message > > >> into a read only "Junk E-Mail" folder for the user, > > > > > > This is just wrong. Either accept the message, or reject the > > message. Rejecting the message while secretly accepting it is just > > completely wrong. > [...] > > > Let's say your filter catches a legitimate message to > > u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying > > the message was spammy and didn't go through, so he goes to his > > gmail account and sends it again, hoping for better results. This > > time it goes through. > > > > Bob could also have just clicked the link in the NDR. > Some people - e.g. /me - do not try to pass Turing tests. Obviously > you are not interested in my mails anyway But it's only applied to mail classified as spam, and unlike CR it generates no additional backscatter. > Apart from that why should I decode captchas from some random site? > After all, they could come from a third site so that people solve them > to the the other can log automatically into the third one ... Because the NDR is generated by *your* mail server in response to *your* email. I think it's rather a good idea.
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 11:26, Bernd Petrovitsch wrote: At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user, This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong. [...] Let's say your filter catches a legitimate message to u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through. Bob could also have just clicked the link in the NDR. Some people - e.g. /me - do not try to pass Turing tests. Obviously you are not interested in my mails anyway If you email somebody and the spam filtering rejects the message, you assume they don't want your mail and don't bother trying to contact them again? Not even if it's obviously beneficial for you to do so? Apart from that why should I decode captchas from some random site? After all, they could come from a third site so that people solve them to the the other can log automatically into the third one ... It's not some random email from a "random site". It's an NDR to an email that you yourself sent. Let me explain this in simple terms. Normal behaviour: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. Behaviour on my system: Spam filtering causes a 5xx rejection. You get an NDR. You either contact the user some other way or not at all. But ... the recipient can still access the email if it's something they were expecting, *and* if the sender still wants to contact the recipient they now have an *extra* option to make their life easier - they can click a URL and fill in a captcha. So ... my system provides 2 extra little features which makes some senders and some recipients lives more easy. Neither sender nor recipient would benefit from me removing those features from my system. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Newest spammer trick - non-blank subject lines?
On Don, 2010-02-11 at 10:38 +, Mike Cardwell wrote: > On 11/02/2010 08:27, LuKreme wrote: > >> At SMTP time I return a 5xx code during the "DATA" phase for messages > >> classified as Spam. However, I also deliver the message into a read only > >> "Junk E-Mail" folder for the user, > > > > This is just wrong. Either accept the message, or reject the > message. Rejecting the message while secretly accepting it is just > completely wrong. [...] > > Let's say your filter catches a legitimate message to > u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying > the message was spammy and didn't go through, so he goes to his gmail > account and sends it again, hoping for better results. This time it > goes through. > > Bob could also have just clicked the link in the NDR. Some people - e.g. /me - do not try to pass Turing tests. Obviously you are not interested in my mails anyway Apart from that why should I decode captchas from some random site? After all, they could come from a third site so that people solve them to the the other can log automatically into the third one ... Bernd -- Bernd Petrovitsch Email : be...@petrovitsch.priv.at LUGA : http://www.luga.at
Re: Newest spammer trick - non-blank subject lines?
On 11/02/2010 08:27, LuKreme wrote: At SMTP time I return a 5xx code during the "DATA" phase for messages classified as Spam. However, I also deliver the message into a read only "Junk E-Mail" folder for the user, This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong. "This is just wrong" is not a very good argument for your case. Hopefully you'll do better below. Let's say your filter catches a legitimate message to u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through. Bob could also have just clicked the link in the NDR. Now your user has two emails, one tagged spam and one not. One is in quarantine, and one isn't. How have you helped your user? You've described one scenario out of many. One where my system wouldn't provide any additional benefit, but at the same time it doesn't make either the sender or the recipient worse off. You didn't even describe a scenario which is particularly common. Here's another scenario. One which is definitely more common: A user goes to some website and signs up. They're sent an automated confirmation email. The mail server classifies the incoming email as spam and rejects it. In my system, the user is expecting a confirmation email and doesn't receive it so checks their Junk E-Mail folder and finds it there. In a "normal" system which just 5xx's, the user has to wait longer just to make sure that the email wasn't delayed and then has to jump through loops to find an alternative means of confirming the signup. A couple of days ago I bought a lottery ticket online for the EuroMillions lottery this Friday. The order email got a score of 5.5. Mainly because the "HK_LOTTO" rule fired which applied a score of 3.6. I noticed that I never received a confirmation email, so I looked in my Junk E-Mail folder and there it was. Highly useful. As for your modified 'prove-you-love-me' scheme of quarantines and releases and web urls, that would look very spammish to me, and I wouldn't follow that link, even if I did see it which I probably wouldn't because my SA would almost certainly classify that sort of NDN as spam... Your SpamAssassin installation would, "almost certainly," classify an NDR, which your *own system* generated, as spam? I rarely use "LOL", but in this case I think it's appropriate... LOL. I've never clicked on a prove-you-love-me link, and I'm not about to start now. And when asked by my customers I recommend they don't click them either. As I point out, this falls under the class of 'unknown URL from unknown source' and that's always a risk. Providing the URL *might* provide benefit for *some* people. Again, the existance of the URL doesn't make either the sender or the recipient worse off in any way. You've failed to convince me. -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
- dar...@chaosreigns.com wrote: > http://www.chaosreigns.com/mtx/ > > -- > "Democracy is the theory that the common people know what they want, > and deserve to get it good and hard." - H. L. Mencken > http://www.ChaosReigns.com Like the simplicity and it does appear to be a great idea. Why do you believe SPF or DKIM generate breakage ? -- Thanks, Phil
Re: Newest spammer trick - non-blank subject lines?
On 10-Feb-2010, at 02:42, Mike Cardwell wrote: > > At SMTP time I return a 5xx code during the "DATA" phase for messages > classified as Spam. However, I also deliver the message into a read only > "Junk E-Mail" folder for the user, This is just wrong. Either accept the message, or reject the message. Rejecting the message while secretly accepting it is just completely wrong. Let's say your filter catches a legitimate message to u...@yourdomain.tld from b...@mydomain.tld. Bob gets an erro saying the message was spammy and didn't go through, so he goes to his gmail account and sends it again, hoping for better results. This time it goes through. Now your user has two emails, one tagged spam and one not. One is in quarantine, and one isn't. How have you helped your user? As for your modified 'prove-you-love-me' scheme of quarantines and releases and web urls, that would look very spammish to me, and I wouldn't follow that link, even if I did see it which I probably wouldn't because my SA would almost certainly classify that sort of NDN as spam... I've never clicked on a prove-you-love-me link, and I'm not about to start now. And when asked by my customers I recommend they don't click them either. As I point out, this falls under the class of 'unknown URL from unknown source' and that's always a risk. -- 'How do you know I'm mad?' said Alice 'You must be' said the Cat 'or you wouldn't have come here.'
