Re: Returned mail spam
Matus UHLAR - fantomas writes: > > Richard Smits wrote: > > >Hos safe is it to pump up the score for the ANY_BOUNCE_MESSAGE ? > > >Is it bug free, so I can give it 5 or 10 points ? > > On 18.04.08 09:19, Jason Haar wrote: > > So you are wanting to mark ANY bounce, out of office, or mailing-list > > related email into your organization as spam? If you want to do that, > > then sure! :-) > > > > My own investigations would show that would not be a good idea. I think > > you meant "BOUNCE_MESSAGE" instead - but even that is catching stuff > > that isn't backscatter. > > yes, since (according to previous discussion) VBounce was not designed to > mark backscatter as spam, but to mark (suspicious) bounces as bounces. > It probably needs many changed to be reliable in the way most users expect > - to catch baskscatter while not catch other this may be a matter of definition. In my opinion, "out of office" messages, C/R requests, etc. sent in response to spam forging your address as the sender -- I would define those as backscatter. As the packager of that ruleset -- yes, it is designed to catch backscatter. --j.
Re: Returned mail spam
> Richard Smits wrote: > >Hos safe is it to pump up the score for the ANY_BOUNCE_MESSAGE ? > >Is it bug free, so I can give it 5 or 10 points ? On 18.04.08 09:19, Jason Haar wrote: > So you are wanting to mark ANY bounce, out of office, or mailing-list > related email into your organization as spam? If you want to do that, > then sure! :-) > > My own investigations would show that would not be a good idea. I think > you meant "BOUNCE_MESSAGE" instead - but even that is catching stuff > that isn't backscatter. yes, since (according to previous discussion) VBounce was not designed to mark backscatter as spam, but to mark (suspicious) bounces as bounces. It probably needs many changed to be reliable in the way most users expect - to catch baskscatter while not catch other > ...and I don't think the Backscatter FAQ answers this question. IMHO > VBounce tags *bounces* - not backscatter. Backscatter is a *subset* of > bounces - so it tags stuff that isn't backscatter. whitelist_bounce_relays should whitelist non-backscatter bounces, but that might not be enough. For example, I wonder why does not VBounce look at Received: headers to see if it came from hosts in internal network, such bounces will surely not be backscatter imho. > I'm working on a backscatter.cf to exclusively catch backscatter - but > it's still tagging incorrect stuff. (all my Sourceforge moderator mail > for starters). If I get it working reliably, I'll flick it up the food > chain... good luck. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Emacs is a complicated operating system without good text editor.
Re: Returned mail spam
Richard Smits wrote: Hos safe is it to pump up the score for the ANY_BOUNCE_MESSAGE ? Is it bug free, so I can give it 5 or 10 points ? So you are wanting to mark ANY bounce, out of office, or mailing-list related email into your organization as spam? If you want to do that, then sure! :-) My own investigations would show that would not be a good idea. I think you meant "BOUNCE_MESSAGE" instead - but even that is catching stuff that isn't backscatter. ...and I don't think the Backscatter FAQ answers this question. IMHO VBounce tags *bounces* - not backscatter. Backscatter is a *subset* of bounces - so it tags stuff that isn't backscatter. I'm working on a backscatter.cf to exclusively catch backscatter - but it's still tagging incorrect stuff. (all my Sourceforge moderator mail for starters). If I get it working reliably, I'll flick it up the food chain... -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: Returned mail spam
Hos safe is it to pump up the score for the ANY_BOUNCE_MESSAGE ? Is it bug free, so I can give it 5 or 10 points ? Is anyone doing this ? (Maybe a step to far) Greetings Richard Matus UHLAR - fantomas wrote: >> Graham Murray wrote: >>> If you publish a suitable SPF record then you will not receive any >>> backscatter (which is the subject of this thread) from sites which >>> correctly implement SPF checking. > > On 16.04.08 18:06, mouss wrote: >> without spf, you will not receive any backscatter from sites which do >> not accept-then-bounce. > > even with SPF ... SPF changes nothing here. >
Re: Returned mail spam
> Graham Murray wrote: > >If you publish a suitable SPF record then you will not receive any > >backscatter (which is the subject of this thread) from sites which > >correctly implement SPF checking. On 16.04.08 18:06, mouss wrote: > without spf, you will not receive any backscatter from sites which do > not accept-then-bounce. even with SPF ... SPF changes nothing here. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Atheism is a non-prophet organization.
Re: Returned mail spam
Graham Murray wrote: mouss <[EMAIL PROTECTED]> writes: ahuh? how would spf fix the problem if spam gets out from an authorized client (yahoo, google, hotmail, aol, ...). however you respond, you'll find out that such (ougoing) spam problem isn't fixed _by_ SPF. In particular, don't tell me "they will fix their outgoing spam". If you publish a suitable SPF record then you will not receive any backscatter (which is the subject of this thread) from sites which correctly implement SPF checking. without spf, you will not receive any backscatter from sites which do not accept-then-bounce. Do not forget that SPF is not an anti-spam too per-se but an anti-forgery one. Backscatter is one of the problems which SPF fixes. I'm not from the same church. are you gonna "crusade" me?
Re: Returned mail spam
I'm sensing a disconnect here. Me too! I don't call something broken if it follows the standard. I'm sure this is getting pointless. I'm done. Joseph Brennan Columbia University Information Technology
Re: Returned mail spam
Joseph Brennan wrote: what "own rules"? I'm talking that forwarding without changing sender's address is broken already and I described how and why. SPS just highlights this problem and SRS is trying to solve it... I don't see this necessity to change the sender address anywhere in RFC 2821. In fact it differentiates between lists where you do change the sender and aliases where you do not. Let's see if I've got this right: "There are practical problems with forwarding, whether you do SPF or not." "No, there are no problems with forwarding, because the RFC says it's okay." I'm sensing a disconnect here. I assume everyone here has heard the joke about the difference between theory and practice? -- Kelson Vibber SpeedGate Communications
Re: Returned mail spam
what "own rules"? I'm talking that forwarding without changing sender's address is broken already and I described how and why. SPS just highlights this problem and SRS is trying to solve it... I don't see this necessity to change the sender address anywhere in RFC 2821. In fact it differentiates between lists where you do change the sender and aliases where you do not. Joseph Brennan Columbia University Information Technology
Re: Returned mail spam
> Matus UHLAR - fantomas <[EMAIL PROTECTED]> wrote: > > >no, SPF does not break forwarding. Automatic forwarding without changing > >envelope from address is broken already On 15.04.08 09:24, Joseph Brennan wrote: > SMTP is not Calvin Ball. If you make up your own rules about forwarding > please do not be surprised that other people ignore them. what "own rules"? I'm talking that forwarding without changing sender's address is broken already and I described how and why. SPS just highlights this problem and SRS is trying to solve it... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
Re: Returned mail spam
Matus UHLAR - fantomas <[EMAIL PROTECTED]> wrote: no, SPF does not break forwarding. Automatic forwarding without changing envelope from address is broken already SMTP is not Calvin Ball. If you make up your own rules about forwarding please do not be surprised that other people ignore them. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology
Re: Returned mail spam
> On Thu, April 10, 2008 18:29, Arvid Ephraim Picciani wrote: > > On Thursday 10 April 2008 17:16:40 mouss wrote: > >> I personally have found that SPF causes more problems than it helps, and > >> for that I do not recommend setting SPF record for "general use" domains. On 14.04.08 20:03, Benny Pedersen wrote: > spf supports +ALL, please tell me why its a problem ? setting +all on a domain may indicate a spammer. Some spammers use this to make stupid people think it's not spam (because it passes SPF test). > > mind explaining more detailed? I use SPF on all 300 domains. I don't think > > anyone actually checks them but so what? Maybe somone does. Whats the > > trouble > > you speak of? > > maybe bad asumtions that it breaks forwards :/ no, SPF does not break forwarding. Automatic forwarding without changing envelope from address is broken already - if the forwarded address has a problem, sender gets a bounce about undeliverable address, different from the one he sent the e-mail to. What to do with the bounce? Was his mail delivered to anyone? The situation is similar to mails sent from mailing lists and should be handled similarly. Forwarders that don't rewrite the sender's address behave as those "mailing lists" that do not... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Enter any 12-digit prime number to continue.
Re: Returned mail spam
On Thu, April 10, 2008 18:29, Arvid Ephraim Picciani wrote: > On Thursday 10 April 2008 17:16:40 mouss wrote: >> I personally have found that SPF causes more problems than it helps, and >> for that I do not recommend setting SPF record for "general use" domains. spf supports +ALL, please tell me why its a problem ? > mind explaining more detailed? I use SPF on all 300 domains. I don't think > anyone actually checks them but so what? Maybe somone does. Whats the trouble > you speak of? maybe bad asumtions that it breaks forwards :/ but spf is designed flexible enough to be flexible to anyone not just hotmail.com :) Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Returned mail spam
> From: Graham Murray <[EMAIL PROTECTED]> > Date: Sun, 13 Apr 2008 11:08:03 +0100 > To: > Subject: Re: Returned mail spam > > mouss <[EMAIL PROTECTED]> writes: > >> ahuh? how would spf fix the problem if spam gets out from an >> authorized client (yahoo, google, hotmail, aol, ...). however you >> respond, you'll find out that such (ougoing) spam problem isn't fixed >> _by_ SPF. In particular, don't tell me "they will fix their outgoing >> spam". > > If you publish a suitable SPF record then you will not receive any > backscatter (which is the subject of this thread) from sites which > correctly implement SPF checking. Do not forget that SPF is not an > anti-spam too per-se but an anti-forgery one. Backscatter is one of the > problems which SPF fixes. ONLY for those sites that implement SPF in a pre-queue type filter, and ONLY I you use -all record types. But then again, the sites that correctly implement SPF in a pre-queue type filter also probably implement recipient verification in a pre-queue filter and are not as likely to be the source of backscatter anyway. Yes, implement SPF records, it doesn't cost anything. Just make sure your users don't FWD their emails out, and that your marketing department has identified any any all companies that send email on your behalf. -- Michael Scheidell, CTO >|SECNAP Network Security Winner 2008 Network Products Guide Hot Companies FreeBSD SpamAssassin Ports maintainer _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _
Re: Returned mail spam
mouss <[EMAIL PROTECTED]> writes: > ahuh? how would spf fix the problem if spam gets out from an > authorized client (yahoo, google, hotmail, aol, ...). however you > respond, you'll find out that such (ougoing) spam problem isn't fixed > _by_ SPF. In particular, don't tell me "they will fix their outgoing > spam". If you publish a suitable SPF record then you will not receive any backscatter (which is the subject of this thread) from sites which correctly implement SPF checking. Do not forget that SPF is not an anti-spam too per-se but an anti-forgery one. Backscatter is one of the problems which SPF fixes.
Re: Returned mail spam
Matus UHLAR - fantomas wrote: On 10.04.08 20:03, mouss wrote: Some sites cache results obtained from DNS beyond DNS TTL. I don't think their DNS server caches the results (though I am willing to accept that there are borked DNS implementations). It's more likely that whatever $thing queries DNS is caching the result indefinitely or for too long. so you are mistaking broken caching as SPF problem... do you think I care of the specs if "important" implementations go west? If you exclude broken specs and implementations, I will say that I have no problems in this perfect collaborative internet world. to sum it up: I don't see what spf would bring to me. the only time I tried it, it went against me. that's enough for me. all other stuff is pure theory compared to what I've seen. that's it. nothing more, nothing less. and yes, I am biased. I was already convinced that spf was wrong and I decided to give it a chance. the result was that I now know that it is not even "neutral". if you like spf, that's good for you. I don't. and it doesn't help to believe that those who don't believe in are mistaken and have "false assumptions". This is not acceptable. I respect opinions of those who accept other people's opinions. this subject has been debated many many times in many many places. let's please not repeat the old debate. I respect your opinion but I disagree. I am not inventing anything. many respected and respectable people have spoken about this. google will tell you. let me just cite John Levine's http://www.circleid.com/posts/spf_loses_mindshare/ and while I am in, let's talk about more important things: http://www.sciencedaily.com/releases/2005/08/050829073103.htm :-) cheers, -- mouss
Re: Returned mail spam
On 10.04.08 20:03, mouss wrote: > Some sites cache results obtained from DNS beyond DNS TTL. I don't think > their DNS server caches the results (though I am willing to accept that > there are borked DNS implementations). It's more likely that whatever > $thing queries DNS is caching the result indefinitely or for too long. so you are mistaking broken caching as SPF problem... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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: Returned mail spam
> >>>mouss wrote: > he's not the only one... seems there's a lot of backscatter coming in > these days. > > Thanks for confirming that spf doesn't fix the problem. > Matus UHLAR - fantomas wrote: > >SPF is designed to fix the problem, On 10.04.08 17:16, mouss wrote: > ahuh? how would spf fix the problem if spam gets out from an authorized > client (yahoo, google, hotmail, aol, ...). Read below. If you authorize yahoo google hotmail and aol to send mail from your domain, don't talk about SPF problems ... and there is no other authorization in SPF than this one... > however you respond, you'll > find out that such (ougoing) spam problem isn't fixed _by_ SPF. In > particular, don't tell me "they will fix their outgoing spam". SPF is not designed to prevent spam, but forgery. If there are SPF records in your domain that "permit" only your hosts to send mail from yor domain, any mail from your domain coming from different hosts should be rejected. So, if you set up proper SPF records on your domain, any server that follows SPF should reject such mail, which would prevent from sending you backscatter. Yes, I know that servers sending backscatter usually don't check for SPF, and I also know that SPF-aware servers usually don't backscatter, however there surely are cases where the spam goes throufh SPF-aware mailserver to another sending backscatter, which helps the situation.. It was alread mentioned that (at least some) spammers try to avoid sending mail using domain with SPF properly set up. If SPF is not properly set up, it's the problem of the domain admin, of course. > while I don't say that SPF is useless, you'll have a hard time > convincing me that "it is always good to have SPF...". > > I personally have found that SPF causes more problems than it helps, and > for that I do not recommend setting SPF record for "general use" domains. SPF doesn't cause any problems, it only highlits some existing problems, mostly those related to mail forwarding. It only causes problems if SPF records are badly configured... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. My mind is like a steel trap - rusty and illegal in 37 states.
Re: Returned mail spam
Bob Proulx wrote: mouss wrote: Bob Proulx wrote: I don't think that any of those should match and therefore is safe by default. the trouble comes from the default (compatibility) value of relay_domains and relay_recipient_maps. For this reason, it is recommended to set parent_domain_matches_subdomains = This parameter is deprecated and setting it to an empty value is now recommended. But the default values for those are: relay_domains = $mydestination relay_recipient_maps = Again, both of those should be safe enough. Of course those come into play when configuring virtual host domains and mx relays. Certainly at the point that someone sets that up then they would need specific configuration along with it. But by default it looks okay to me. look at the value of parent_domain_matches_subdomains. It means every subdomain of a relay domain is a relay domain, and since you have relay_recipient_maps=, recipient validation is disabled for these subdomains (except those that are in mydestination). these defaults are historical and should be overriden if you don't need compatibility... but as you said, the postfix-users list is a better place... It is also recommended to set relay_domains explictely. and if you have the list of relay recipients, set relay_recipient_maps. otherwise, use reject_unverified_recipient in access checks (only for relay domains, not for every domain). Unfortunately this is probably about as much drift off-topic onto mta configuration that we should have on this list. But thanks for the hints anyway. It gives me a trail to follow. Bob
Re: Returned mail spam
mouss wrote: > Bob Proulx wrote: > >I don't think that any of those should match and therefore is safe by > >default. > > the trouble comes from the default (compatibility) value of > relay_domains and relay_recipient_maps. For this reason, it is > recommended to set > parent_domain_matches_subdomains = > This parameter is deprecated and setting it to an empty value is now > recommended. But the default values for those are: relay_domains = $mydestination relay_recipient_maps = Again, both of those should be safe enough. Of course those come into play when configuring virtual host domains and mx relays. Certainly at the point that someone sets that up then they would need specific configuration along with it. But by default it looks okay to me. > It is also recommended to set relay_domains explictely. and if you have > the list of relay recipients, set relay_recipient_maps. otherwise, use > reject_unverified_recipient in access checks (only for relay domains, > not for every domain). Unfortunately this is probably about as much drift off-topic onto mta configuration that we should have on this list. But thanks for the hints anyway. It gives me a trail to follow. Bob
Re: Returned mail spam
Kelson wrote: Who said anything about spam from an authorized source? I was misled by SPF... sorry. The problem *being discussed* is spam with a forged sender address, causing bounce notices to go to an innocent third party. which is caused by "accept then bounce" implementations, something that is considered "bad" by many people since some time now. fixing these implementations is far simpler than requiring every domain on earth to decide that its mail should go through few relays.
Re: Returned mail spam
mouss wrote: Matus UHLAR - fantomas wrote: But back on topic... the OP has been joe-jobbed. mouss wrote: he's not the only one... seems there's a lot of backscatter coming in these days. Thanks for confirming that spf doesn't fix the problem. SPF is designed to fix the problem, ahuh? how would spf fix the problem if spam gets out from an authorized client (yahoo, google, hotmail, aol, ...). however you respond, you'll find out that such (ougoing) spam problem isn't fixed _by_ SPF. In particular, don't tell me "they will fix their outgoing spam". Who said anything about spam from an authorized source? The problem *being discussed* is spam with a forged sender address, causing bounce notices to go to an innocent third party. -- Kelson Vibber SpeedGate Communications
Re: Returned mail spam
Arvid Ephraim Picciani wrote: On Thursday 10 April 2008 17:16:40 mouss wrote: I personally have found that SPF causes more problems than it helps, and for that I do not recommend setting SPF record for "general use" domains. mind explaining more detailed? I use SPF on all 300 domains. I don't think anyone actually checks them but so what? Maybe somone does. Whats the trouble you speak of? Some sites cache results obtained from DNS beyond DNS TTL. I don't think their DNS server caches the results (though I am willing to accept that there are borked DNS implementations). It's more likely that whatever $thing queries DNS is caching the result indefinitely or for too long. and I am not talking about sites that interpret ~all as a -all. and as a "client", I am not talking about recursive SPF records and other funny stuff.
Re: Returned mail spam
On Thursday 10 April 2008 17:16:40 mouss wrote: > I personally have found that SPF causes more problems than it helps, and > for that I do not recommend setting SPF record for "general use" domains. mind explaining more detailed? I use SPF on all 300 domains. I don't think anyone actually checks them but so what? Maybe somone does. Whats the trouble you speak of? -- best regards/Mit freundlichen Grüßen Arvid Ephraim Picciani
Re: Returned mail spam
Matus UHLAR - fantomas wrote: But back on topic... the OP has been joe-jobbed. mouss wrote: he's not the only one... seems there's a lot of backscatter coming in these days. Thanks for confirming that spf doesn't fix the problem. SPF is designed to fix the problem, ahuh? how would spf fix the problem if spam gets out from an authorized client (yahoo, google, hotmail, aol, ...). however you respond, you'll find out that such (ougoing) spam problem isn't fixed _by_ SPF. In particular, don't tell me "they will fix their outgoing spam". however as many other standards it works only if it's implemented. Steve Prior wrote: The main problem with SPF is that most other servers out there don't check it even if you set your own records correctly. On 10.04.08 09:29, mouss wrote: The question was whether spammers avoid joe jobbing addresses in domains that have SPF set (except with a +all). it seems some of them do and some don't. however some people can make false assumption that SPF is useless - it is not. It is always good to have SPF (and DKIM, of course) and the more servers will implement it, the more effe3ctive it will be. while I don't say that SPF is useless, you'll have a hard time convincing me that "it is always good to have SPF...". I personally have found that SPF causes more problems than it helps, and for that I do not recommend setting SPF record for "general use" domains.
Re: Returned mail spam
> >>>But back on topic... the OP has been joe-jobbed. > >mouss wrote: > >>he's not the only one... seems there's a lot of backscatter coming in > >>these days. > >> > >>Thanks for confirming that spf doesn't fix the problem. SPF is designed to fix the problem, however as many other standards it works only if it's implemented. > Steve Prior wrote: > >The main problem with SPF is that most other servers out there don't > >check it even if you set your own records correctly. On 10.04.08 09:29, mouss wrote: > The question was whether spammers avoid joe jobbing addresses in domains > that have SPF set (except with a +all). it seems some of them do and > some don't. however some people can make false assumption that SPF is useless - it is not. It is always good to have SPF (and DKIM, of course) and the more servers will implement it, the more effe3ctive it will be. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. 99 percent of lawyers give the rest a bad name.
Re: Returned mail spam
Steve Prior wrote: mouss wrote: But back on topic... the OP has been joe-jobbed. he's not the only one... seems there's a lot of backscatter coming in these days. Thanks for confirming that spf doesn't fix the problem. The main problem with SPF is that most other servers out there don't check it even if you set your own records correctly. The question was whether spammers avoid joe jobbing addresses in domains that have SPF set (except with a +all). it seems some of them do and some don't. I've been joe-jobbed since I implemented SPF and maybe it's possible I would have gotten more backscatter without it, but I still got plenty because the servers which got the email in the first place didn't check SPF to see that it wasn't coming from me. The sadly funny time was when I got backscatter from a server with an accompanying message of "this email failed SPF so it probably didn't come from you, but just to be safe I'm returning it to you anyway" - great, thanks. DKIM would have the same issue - doesn't mean anything if the other folks don't check it. Steve
Re: Returned mail spam
Bob Proulx wrote: decoder wrote: We recently discovered that even our own mailserver (Postfix) was a backscatter source (and 1-2 weeks ago spammers started to actively use it), there were several reasons and I'd like to share these points with the list so nobody does the same mistakes. Thanks for the discussion. 2) By default, Postfix happily seems to accept email addresses refering to subdomains of domains listed in $mydestination. The option responsible for this cruel behavior is "parent_domain_matches_subdomains" which is by default not empty. We've set it to an empty string and after that, Postfix finally rejected mails to bogus recipients on our subdomains. The default value is: parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps I don't think that any of those should match and therefore is safe by default. the trouble comes from the default (compatibility) value of relay_domains and relay_recipient_maps. For this reason, it is recommended to set parent_domain_matches_subdomains = This parameter is deprecated and setting it to an empty value is now recommended. It is also recommended to set relay_domains explictely. and if you have the list of relay recipients, set relay_recipient_maps. otherwise, use reject_unverified_recipient in access checks (only for relay domains, not for every domain). I poked at my server and couldn't trick it into accepting mail to subdomains. If yours is allowing messages through by matching one of them then I suspect that the configurations for it is the problem and should be fixed. In other words, you might not be done debugging yet and may still have another problem to figure out. :-}
Re: Returned mail spam
mouss wrote: But back on topic... the OP has been joe-jobbed. he's not the only one... seems there's a lot of backscatter coming in these days. Thanks for confirming that spf doesn't fix the problem. The main problem with SPF is that most other servers out there don't check it even if you set your own records correctly. I've been joe-jobbed since I implemented SPF and maybe it's possible I would have gotten more backscatter without it, but I still got plenty because the servers which got the email in the first place didn't check SPF to see that it wasn't coming from me. The sadly funny time was when I got backscatter from a server with an accompanying message of "this email failed SPF so it probably didn't come from you, but just to be safe I'm returning it to you anyway" - great, thanks. DKIM would have the same issue - doesn't mean anything if the other folks don't check it. Steve
Re: Returned mail spam
decoder wrote: > We recently discovered that even our own mailserver (Postfix) was a > backscatter source (and 1-2 weeks ago spammers started to actively use > it), there were several reasons and I'd like to share these points with > the list so nobody does the same mistakes. Thanks for the discussion. > 2) By default, Postfix happily seems to accept email addresses refering > to subdomains of domains listed in $mydestination. The option > responsible for this cruel behavior is > "parent_domain_matches_subdomains" which is by default not empty. We've > set it to an empty string and after that, Postfix finally rejected mails > to bogus recipients on our subdomains. The default value is: parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps I don't think that any of those should match and therefore is safe by default. I poked at my server and couldn't trick it into accepting mail to subdomains. If yours is allowing messages through by matching one of them then I suspect that the configurations for it is the problem and should be fixed. In other words, you might not be done debugging yet and may still have another problem to figure out. :-} Bob
Re: Returned mail spam
On Wed, 9 Apr 2008, Luis Hernán Otegui wrote: 2008/4/9, John Hardin <[EMAIL PROTECTED]>: On Wed, 9 Apr 2008, mouss wrote: Thanks for confirming that spf doesn't fix the problem. There's no silver bullet. SPF will tend to reduce the problem. Would't DKIM help also? I've implemented both methods, and encouraged my colleagues to do it too. The main advantage I see in DKIM is that it doesn't break the chain of trust if somebody forwards a message. Yup. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- ...every time I sit down in front of a Windows machine I feel as if the computer is just a place for the manufacturers to put their advertising.-- fwadling on Y! SCOX -- 4 days until Thomas Jefferson's 265th Birthday
Re: Returned mail spam
mouss wrote: he's not the only one... seems there's a lot of backscatter coming in these days. I guess the reason is that it is so easy to make a mistake in a mailserver configuration that enables backscatter... We recently discovered that even our own mailserver (Postfix) was a backscatter source (and 1-2 weeks ago spammers started to actively use it), there were several reasons and I'd like to share these points with the list so nobody does the same mistakes. 1) With Virtual Domains, the recipient validation is not properly done anymore once you map one virtual domain to another, so do not do that. Also never use wildcards with domain names except if there is a catch all defined for this virtual domain entry. 2) By default, Postfix happily seems to accept email addresses refering to subdomains of domains listed in $mydestination. The option responsible for this cruel behavior is "parent_domain_matches_subdomains" which is by default not empty. We've set it to an empty string and after that, Postfix finally rejected mails to bogus recipients on our subdomains. If any of that is wrong, feel free to correct me :) Best regards, Chris smime.p7s Description: S/MIME Cryptographic Signature
Re: Returned mail spam
2008/4/9, John Hardin <[EMAIL PROTECTED]>: > On Wed, 9 Apr 2008, mouss wrote: > > > > Thanks for confirming that spf doesn't fix the problem. > > > > There's no silver bullet. SPF will tend to reduce the problem. Would't DKIM help also? I've implemented both methods, and encouraged my colleagues to do it too. The main advantage I see in DKIM is that it doesn't break the chain of trust if somebody forwards a message. > > -- > John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ > [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] > key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 > --- > The ["assault weapons"] ban is the moral equivalent of banning red > cars because they look too fast. -- Steve Chapman, Chicago Tribune > --- > 4 days until Thomas Jefferson's 265th Birthday > Luis -- _ GNU/GPL: "May The Source Be With You... Linux Registered User #448382. _
Re: Returned mail spam
On Wed, 9 Apr 2008, mouss wrote: Thanks for confirming that spf doesn't fix the problem. There's no silver bullet. SPF will tend to reduce the problem. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The ["assault weapons"] ban is the moral equivalent of banning red cars because they look too fast. -- Steve Chapman, Chicago Tribune --- 4 days until Thomas Jefferson's 265th Birthday
Re: Returned mail spam
Jonathan Nichols wrote: Yup. Even used the wizard and that exact same verification tool, as well as dnsstuff.com and it reports that the SPF records I added are just fine. Yet, I still got plenty of junk thanks to some russian spammer using my hostmaster@ as the From. :( But back on topic... the OP has been joe-jobbed. he's not the only one... seems there's a lot of backscatter coming in these days. Thanks for confirming that spf doesn't fix the problem.
Re: Returned mail spam
On Apr 9, 2008, at 2:16 PM, mouss wrote: Martin Gregorie wrote: On Wed, 2008-04-09 at 19:04, Jonathan Nichols wrote: Guys? He's been joe-jobbed. From the original email: "somebody is using my email as the bounce- back return email. How do I avoid the problem?" If SPF is supposed to prevent this, I can say that it sure as heck doesn't seem to. Despite having SPF records, I still managed to have my hostmaster@ address become the recipient of a few thousand bounce notifications the other day. :| SPF is ineffective if you set the record up incorrectly. what do you mean by incorrectly? the domain in Jonathan's address has an spf txt that seems ok to me. > [snip] Yup. Even used the wizard and that exact same verification tool, as well as dnsstuff.com and it reports that the SPF records I added are just fine. Yet, I still got plenty of junk thanks to some russian spammer using my hostmaster@ as the From. :( But back on topic... the OP has been joe-jobbed.
Re: Returned mail spam
Martin Gregorie wrote: On Wed, 2008-04-09 at 19:04, Jonathan Nichols wrote: Guys? He's been joe-jobbed. From the original email: "somebody is using my email as the bounce- back return email. How do I avoid the problem?" If SPF is supposed to prevent this, I can say that it sure as heck doesn't seem to. Despite having SPF records, I still managed to have my hostmaster@ address become the recipient of a few thousand bounce notifications the other day. :| SPF is ineffective if you set the record up incorrectly. what do you mean by incorrectly? the domain in Jonathan's address has an spf txt that seems ok to me. > [snip]
Re: Returned mail spam
On Wed, 2008-04-09 at 19:04, Jonathan Nichols wrote: > On Apr 8, 2008, at 2:50 PM, McDonald, Dan wrote: > > > > > On Tue, 2008-04-08 at 12:36 -0700, ahgu wrote: > >> They forged the header with my email addr as the return address. > >> When it get bounced back by a server, everything is valid. Since > >> the server > >> strip off most of the content, it can pass the spamassassin very > >> easily. I > >> wonder if anyone got this problem? > > > > Of course, it is very common. > > > > SPF does a reasonable job of stopping it, since it is not worth the > > spammer's time to forge when a good portion will be ditched as > > violating > > spf. > > > > Guys? He's been joe-jobbed. > > From the original email: "somebody is using my email as the bounce- > back return email. > How do I avoid the problem?" > > If SPF is supposed to prevent this, I can say that it sure as heck > doesn't seem to. Despite having SPF records, I still managed to have > my hostmaster@ address become the recipient of a few thousand bounce > notifications the other day. :| > SPF is ineffective if you set the record up incorrectly. As the rules for doing so are somewhat opaque I'd *strongly* suggest that you use wizard at http://www.openspf.org to create your SPF record and the tools there and at http://www.kitterman.com/spf/validate.html to check and correct your SPF record after its been deployed. HTH, Martin
Re: Returned mail spam
On Apr 8, 2008, at 2:50 PM, McDonald, Dan wrote: On Tue, 2008-04-08 at 12:36 -0700, ahgu wrote: They forged the header with my email addr as the return address. When it get bounced back by a server, everything is valid. Since the server strip off most of the content, it can pass the spamassassin very easily. I wonder if anyone got this problem? Of course, it is very common. SPF does a reasonable job of stopping it, since it is not worth the spammer's time to forge when a good portion will be ditched as violating spf. Guys? He's been joe-jobbed. From the original email: "somebody is using my email as the bounce- back return email. How do I avoid the problem?" If SPF is supposed to prevent this, I can say that it sure as heck doesn't seem to. Despite having SPF records, I still managed to have my hostmaster@ address become the recipient of a few thousand bounce notifications the other day. :|
Re: Returned mail spam
> On Tue, April 8, 2008 21:10, ahgu wrote: > > > Delivery to the following recipient has been delayed: > > > > [EMAIL PROTECTED] > > > > Message will be retried for 2 more day(s) On 08.04.08 21:20, Benny Pedersen wrote: > what mta have 2 days of notifying as default ? the bounce was from google... however it only means that it will try 2 days to deliver the message, the warning time seems to be 1 day which is 3 days total time for delivery. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; 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. Christian Science Programming: "Let God Debug It!".
Re: Returned mail spam
On Tue, 2008-04-08 at 12:36 -0700, ahgu wrote: > They forged the header with my email addr as the return address. > When it get bounced back by a server, everything is valid. Since the server > strip off most of the content, it can pass the spamassassin very easily. I > wonder if anyone got this problem? Of course, it is very common. SPF does a reasonable job of stopping it, since it is not worth the spammer's time to forge when a good portion will be ditched as violating spf. the vbounce plugin is also useful for identifying the bad bounces and discarding them. Amavisd-new 2.6 has a new pen-pals feature that checks all DSN's received to see if there is a corresponding outbound e-mail. That would virtually eliminate your receipt of spoofed bounces. The other solution is to convince every computer owner in the world to replace their infected BOTs with a clean machine and stable OS, and to maintain it properly. That one has considerably higher time investments needed. -- Daniel J McDonald, CCIE #2495, CISSP #78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: Returned mail spam
They forged the header with my email addr as the return address. When it get bounced back by a server, everything is valid. Since the server strip off most of the content, it can pass the spamassassin very easily. I wonder if anyone got this problem? Benny Pedersen wrote: > > > On Tue, April 8, 2008 21:10, ahgu wrote: > >> Delivery to the following recipient has been delayed: >> >> [EMAIL PROTECTED] >> >> Message will be retried for 2 more day(s) > > what mta have 2 days of notifying as default ? > > solutiion is more to stop notifying :-) > > its imho not a spam problem, just a notifying > > > Benny Pedersen > Need more webspace ? http://www.servage.net/?coupon=cust37098 > > > -- View this message in context: http://www.nabble.com/Returned-mail-spam-tp16570515p16571331.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Returned mail spam
On Tue, April 8, 2008 21:10, ahgu wrote: > Delivery to the following recipient has been delayed: > > [EMAIL PROTECTED] > > Message will be retried for 2 more day(s) what mta have 2 days of notifying as default ? solutiion is more to stop notifying :-) its imho not a spam problem, just a notifying Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Returned mail spam
On Tue, April 8, 2008 21:04, Evan Platt wrote: > SPF is a good start... > http://spf.pobox.com/ moved to http://openspf.org/ Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: Returned mail spam
Another email: X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on xphotonics.com X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=URI_HEX autolearn=no version=3.2.4 X-Spam-Pyzor: Reported 0 times. X-Spam-Report: * 1.3 URI_HEX URI: URI hostname has long hexadecimal sequence Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by xphotonics.com (8.14.1/8.14.1) with ESMTP id m38J7lLH034356 for <[EMAIL PROTECTED]>; Tue, 8 Apr 2008 15:07:47 -0400 (EDT) Received: by gv-out-0910.google.com with SMTP id n29so441885gve.40 for <[EMAIL PROTECTED]>; Tue, 08 Apr 2008 12:07:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject:date; bh=NY6lhrPVA5FG0iKYqXfg+EuDzaymNjt7EVEKS7tTG0o=; b=FxfK7+lxXIeO4BN0aWU+V+GhumK181T5gVxlEZpffDhNBR0piBItBzfa6u82ZIw9sfIrpvFm3smhBhfeApO15Fb4OSvWZzy4pOBjLgW4wXX1ELkAPxq1auMWmF/M81SXAQxGkv1EyNTjp2Z8wrFPP5rVFIRH9M39M5zibDQg0iE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:from:to:subject:date; b=V1b/BbeXdacGKojrQFM5jYtGpJFG9MsBiSde8lt5A1YJccuWPf5PFj49EGkHMw3e54ZOJG9zHWQfnCgjr1iPDUKu9rZpPYcmTqu5dnAthX5GgP8ZhmX4OnPBJ57+/EcG7W0y7dCn+DVNYon/fm9V+6/KV7fS3Y56hKgmpg71yBc= Received: by 10.142.158.17 with SMTP id g17mr3223126wfe.106.1207681655587; Tue, 08 Apr 2008 12:07:35 -0700 (PDT) Received: by 10.142.158.17 with SMTP id g17mr4800214wfe.106; Tue, 08 Apr 2008 12:07:35 -0700 (PDT) Message-ID: <[EMAIL PROTECTED]> From: Mail Delivery Subsystem <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Delivery Status Notification (Delay) Date: Tue, 08 Apr 2008 12:07:35 -0700 (PDT) X-Virus-Scanned: ClamAV 0.91.1/6671/Tue Apr 8 13:52:06 2008 on xphotonics.com X-Virus-Status: Clean This is an automatically generated Delivery Status Notification THIS IS A WARNING MESSAGE ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. Delivery to the following recipient has been delayed: [EMAIL PROTECTED] Message will be retried for 2 more day(s) - Message header follows - Received: by 10.142.158.17 with SMTP id g17mr2671000wfe.106.1207589565795; Mon, 07 Apr 2008 10:32:45 -0700 (PDT) Return-Path: <[EMAIL PROTECTED]> Received: from toroon12-1177845134.sdsl.bell.ca (toroon12-1177845134.sdsl.bell.ca [70.52.125.142]) by mx.google.com with ESMTP id 30si18291073wfa.2.2008.04.07.10.32.44; Mon, 07 Apr 2008 10:32:45 -0700 (PDT) Received-SPF: neutral (google.com: 70.52.125.142 is neither permitted nor denied by best guess record for domain of [EMAIL PROTECTED]) client-ip=70.52.125.142; Authentication-Results: mx.google.com; spf=neutral (google.com: 70.52.125.142 is neither permitted nor denied by best guess record for domain of [EMAIL PROTECTED]) [EMAIL PROTECTED] Message-ID: <[EMAIL PROTECTED]> From: "benedicto hiram" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: We ship worldwide. Don't wanna overpay in your local drugstore? Shy to buy ED drugs? Buy from us we'll deliver it to your house. Date: Mon, 07 Apr 2008 15:45:22 + MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 - Message body suppressed - -- View this message in context: http://www.nabble.com/Returned-mail-spam-tp16570515p16570714.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Re: Returned mail spam
SPF is a good start... http://spf.pobox.com/ Do you actually have a [EMAIL PROTECTED] account? If not, don't accept mail for invalid e-mail addresses. ahgu wrote: somebody is using my email as the bounce-back return email. How do I avoid the problem? thanks Andrew X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on xphotonics.com X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS autolearn=failed version=3.2.4 X-Spam-Pyzor: Reported 0 times. X-Spam-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record Received: from da1.hostingplus.nl (da1.hostingplus.nl [213.247.55.91]) by xphotonics.com (8.14.1/8.14.1) with ESMTP id m38IYDjj098834 for <[EMAIL PROTECTED]>; Tue, 8 Apr 2008 14:34:13 -0400 (EDT) Received: from mail by da1.hostingplus.nl with local (Exim 4.67) id 1JjIda-0004I1-RX for [EMAIL PROTECTED]; Tue, 08 Apr 2008 20:33:42 +0200 Auto-Submitted: auto-replied From: Mail Delivery System <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Warning: message 1JiuzE-0004HI-Pi delayed 24 hours Message-Id: <[EMAIL PROTECTED]> Date: Tue, 08 Apr 2008 20:33:42 +0200 X-Virus-Scanned: ClamAV 0.91.1/6671/Tue Apr 8 13:52:06 2008 on xphotonics.com X-Virus-Status: Clean This message was created automatically by mail delivery software. A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on da1.hostingplus.nl. The message identifier is: 1JiuzE-0004HI-Pi The subject of the message is: *SPAM* Only Prestige The date of the message is:Mon, 07 Apr 2008 15:31:15 + The address to which the message has not yet been delivered is: [EMAIL PROTECTED] Delay reason: mailbox is full No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you.
Returned mail spam
somebody is using my email as the bounce-back return email. How do I avoid the problem? thanks Andrew X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on xphotonics.com X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS autolearn=failed version=3.2.4 X-Spam-Pyzor: Reported 0 times. X-Spam-Report: * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record Received: from da1.hostingplus.nl (da1.hostingplus.nl [213.247.55.91]) by xphotonics.com (8.14.1/8.14.1) with ESMTP id m38IYDjj098834 for <[EMAIL PROTECTED]>; Tue, 8 Apr 2008 14:34:13 -0400 (EDT) Received: from mail by da1.hostingplus.nl with local (Exim 4.67) id 1JjIda-0004I1-RX for [EMAIL PROTECTED]; Tue, 08 Apr 2008 20:33:42 +0200 Auto-Submitted: auto-replied From: Mail Delivery System <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Warning: message 1JiuzE-0004HI-Pi delayed 24 hours Message-Id: <[EMAIL PROTECTED]> Date: Tue, 08 Apr 2008 20:33:42 +0200 X-Virus-Scanned: ClamAV 0.91.1/6671/Tue Apr 8 13:52:06 2008 on xphotonics.com X-Virus-Status: Clean This message was created automatically by mail delivery software. A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on da1.hostingplus.nl. The message identifier is: 1JiuzE-0004HI-Pi The subject of the message is: *SPAM* Only Prestige The date of the message is:Mon, 07 Apr 2008 15:31:15 + The address to which the message has not yet been delivered is: [EMAIL PROTECTED] Delay reason: mailbox is full No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you. -- View this message in context: http://www.nabble.com/Returned-mail-spam-tp16570515p16570515.html Sent from the SpamAssassin - Users mailing list archive at Nabble.com.