Re: Tool for validating sender address as spam-fighting technique?
On Mar 13, 2007, at 8:37 PM, Chad Leigh -- Shire.Net LLC wrote: Address verification callbacks take various forms, but the way exim does it by default is to attempt to start a DSN delivery to the address and if the RCPT TO is accepted it is affirmative. It is not usually use VRFY. Most address verification is done by attempting to start some sort of delivery to the address. I'm assuming that DSN is Delivery Service Notification yes or return receipt. mp Most callback systems either try to do a DSN or they try to do a delivery (SMTP RCPT TO) and then quit before sending a message body via DATA; they do not depend on the SMTP VRFY command as that is commonly blocked or configured to return a generic I don't know whether the address is valid. If it is or if it somehow relies on the ability to deliver a message via smtp to [EMAIL PROTECTED] then I don't see how it prevents spam. If the mail says it is from [EMAIL PROTECTED] but I cannot send a DSN to [EMAIL PROTECTED] then the account is most likely bogus sender and is refused. It works wonders for spam. DSN has a specific definition -- look in the RFCs as I don't remember which RFC it is offhand. But you are supposed to always accept a DSN from as part of the RFCs Supporting bounce messages from was part of the original RFC-821/822 specs. The fancier three-digit codes and canonical DSN format was specified somewhat later, but I believe that the updated SMTP RFCs, 2821/2822 include it. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
Chuck Swiger wrote: On Mar 13, 2007, at 8:37 PM, Chad Leigh -- Shire.Net LLC wrote: Address verification callbacks take various forms, but the way exim does it by default is to attempt to start a DSN delivery to the address and if the RCPT TO is accepted it is affirmative. It is not usually use VRFY. Most address verification is done by attempting to start some sort of delivery to the address. I'm assuming that DSN is Delivery Service Notification yes or return receipt. mp Most callback systems either try to do a DSN or they try to do a delivery (SMTP RCPT TO) and then quit before sending a message body via DATA; they do not depend on the SMTP VRFY command as that is commonly blocked or configured to return a generic I don't know whether the address is valid. If it is or if it somehow relies on the ability to deliver a message via smtp to [EMAIL PROTECTED] then I don't see how it prevents spam. If the mail says it is from [EMAIL PROTECTED] but I cannot send a DSN to [EMAIL PROTECTED] then the account is most likely bogus sender and is refused. It works wonders for spam. DSN has a specific definition -- look in the RFCs as I don't remember which RFC it is offhand. But you are supposed to always accept a DSN from as part of the RFCs Supporting bounce messages from was part of the original RFC-821/822 specs. The fancier three-digit codes and canonical DSN format was specified somewhat later, but I believe that the updated SMTP RFCs, 2821/2822 include it. I just skimmed one of the RFC's to see how this works and it looks like there's some provision for relaying the answer to the right server. I think I misunderstood how it worked and made an incorrect assumption. I assumed that it would not be able to figure out that [EMAIL PROTECTED] is not a valid address given that the worlds primary MX did not know the details of my internal addressing structure until I implemented greylisting last October. It looks like an interesting technique for validating email. I'll have to figure out if I can add it to the stack of things that I do for spam prevention. -- Chris -- __o All I was doing was trying to get home from work. _`\,_ -Rosa Parks ___(*)/_(*)___ Christopher Sean Hiltonchris | at | vindaloo.com pgp key: D0957A2D/f5 30 0a e1 55 76 9b 1f 47 0b 07 e9 75 0e 14 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote: I agree. callbacks are not enough, you can reach a false conclusion, that´s why I use SPF along with callbacks... on the same message, my MX concludes: you are sending email from [EMAIL PROTECTED], but shire.net says YOUR IP address is not allowed to send email on behalf of that domain, therefore YOU ARE FAKE/FORGED ..--- reject regards, I'm not sure what you mean by callbacks but if that involves talking to mx.example.com and trying to figure out if [EMAIL PROTECTED] is a valid address go ahead. I would consider a mailserver that answers that question a security risk as it is freely giving away information about your domain without notifying you. For a long time my mx servers would answer any such question in the affirmative regardless of whether or not the mail account existed. As the above poster says SPF is the way to go. SPF gives the receiving MTA a mechanism to vet inbound mail. For any combination of mail server and from address/from domain there are three possible results from an SPF check: The server is allowed to send mail for the domain; The server is not allowed to send mail for the domain; And I cannot tell because the owner of the domain hasn't published an SPF record. The only problem with SPF is that it's not more widely implemented so the third response is sadly more common than the first two. -- Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 13, 2007, at 6:00 PM, Christopher Sean Hilton wrote: On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote: I agree. callbacks are not enough, you can reach a false conclusion, that´s why I use SPF along with callbacks... on the same message, my MX concludes: you are sending email from [EMAIL PROTECTED], but shire.net says YOUR IP address is not allowed to send email on behalf of that domain, therefore YOU ARE FAKE/FORGED ..--- reject regards, I'm not sure what you mean by callbacks but if that involves talking to mx.example.com and trying to figure out if [EMAIL PROTECTED] is a valid address go ahead. I would consider a mailserver that answers that question a security risk as it is freely giving away information about your domain without notifying you. For a long time my mx servers would answer any such question in the affirmative regardless of whether or not the mail account existed. Address verification callbacks take various forms, but the way exim does it by default is to attempt to start a DSN delivery to the address and if the RCPT TO is accepted it is affirmative. It is not usually use VRFY. Most address verification is done by attempting to start some sort of delivery to the address. As the above poster says SPF is the way to go. SPF gives the receiving MTA a mechanism to vet inbound mail. For any combination of mail server and from address/from domain there are three possible results from an SPF check: The server is allowed to send mail for the domain; The server is not allowed to send mail for the domain; And I cannot tell because the owner of the domain hasn't published an SPF record. The only problem with SPF is that it's not more widely implemented so the third response is sadly more common than the first two. I believe it also breaks when you have forwards. Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
Chad Leigh -- Shire.Net LLC wrote: On Mar 13, 2007, at 6:00 PM, Christopher Sean Hilton wrote: On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote: I agree. callbacks are not enough, you can reach a false conclusion, that´s why I use SPF along with callbacks... on the same message, my MX concludes: you are sending email from [EMAIL PROTECTED], but shire.net says YOUR IP address is not allowed to send email on behalf of that domain, therefore YOU ARE FAKE/FORGED ..--- reject regards, I'm not sure what you mean by callbacks but if that involves talking to mx.example.com and trying to figure out if [EMAIL PROTECTED] is a valid address go ahead. I would consider a mailserver that answers that question a security risk as it is freely giving away information about your domain without notifying you. For a long time my mx servers would answer any such question in the affirmative regardless of whether or not the mail account existed. Address verification callbacks take various forms, but the way exim does it by default is to attempt to start a DSN delivery to the address and if the RCPT TO is accepted it is affirmative. It is not usually use VRFY. Most address verification is done by attempting to start some sort of delivery to the address. I'm assuming that DSN is Delivery Service Notification or return receipt. If it is or if it somehow relies on the ability to deliver a message via smtp to [EMAIL PROTECTED] then I don't see how it prevents spam. As the above poster says SPF is the way to go. SPF gives the receiving MTA a mechanism to vet inbound mail. For any combination of mail server and from address/from domain there are three possible results from an SPF check: The server is allowed to send mail for the domain; The server is not allowed to send mail for the domain; And I cannot tell because the owner of the domain hasn't published an SPF record. The only problem with SPF is that it's not more widely implemented so the third response is sadly more common than the first two. I believe it also breaks when you have forwards. I'm not sure that I would classify it as breakage. I always confuse these but there is a problem with SPF vis-a-vis remails or old style bounces of messages. The delivery from address specified as mail-from in the smtp dialog and the envelope from specified in the mail's headers will differ. And the one that SPF checks is the smtp dialog mail-from address. So a spammer can setup SPF for his domain and mail will false positive in the SPF check but the MTA can add a header which lists the original sender. E.g. [EMAIL PROTECTED] lists himself as the sender of a mail and lists smtp.spamsource.com as a valid source of mail for his domain. He crafts an email with a from address of [EMAIL PROTECTED] and fires is off to you. I'm fairly certain that my MTA, postfix, will add an Original-Sender: [EMAIL PROTECTED] header to any message that comes in under these circumstances. I wouldn't be surprised if my Bayes filter is keying on this header. In the end internet email is built on a flawed protocol. It'd be great if you could verify that the letter that you got passed was really sent by the person who name was really sent in the mail-from part of the smtp handshake but you can't. For my part I neither want to burden people who want to send me email with the chore of having to vet themselves nor wade through excessive amounts of spam. I greylist with spamd and then filter with spamassassin and it's Bayes filter. I find that this combination works very well at negligible cost to people who want to send me mail. YMMV -- Chris __o All I was doing was trying to get home from work. _`\,_ -Rosa Parks ___(*)/_(*)___ Christopher Sean Hilton chris | at | vindaloo.com pgp: f5:30:0a:54:e1:55:76:9b:1f:47:0b:07:e9:75:0e:14 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 13, 2007, at 9:30 PM, Christopher Sean Hilton wrote: Chad Leigh -- Shire.Net LLC wrote: On Mar 13, 2007, at 6:00 PM, Christopher Sean Hilton wrote: On Mon, 2007-03-12 at 12:00 -0400, Marcelo Maraboli wrote: I agree. callbacks are not enough, you can reach a false conclusion, that´s why I use SPF along with callbacks... on the same message, my MX concludes: you are sending email from [EMAIL PROTECTED], but shire.net says YOUR IP address is not allowed to send email on behalf of that domain, therefore YOU ARE FAKE/FORGED ..--- reject regards, I'm not sure what you mean by callbacks but if that involves talking to mx.example.com and trying to figure out if [EMAIL PROTECTED] is a valid address go ahead. I would consider a mailserver that answers that question a security risk as it is freely giving away information about your domain without notifying you. For a long time my mx servers would answer any such question in the affirmative regardless of whether or not the mail account existed. Address verification callbacks take various forms, but the way exim does it by default is to attempt to start a DSN delivery to the address and if the RCPT TO is accepted it is affirmative. It is not usually use VRFY. Most address verification is done by attempting to start some sort of delivery to the address. I'm assuming that DSN is Delivery Service Notification yes or return receipt. mp If it is or if it somehow relies on the ability to deliver a message via smtp to [EMAIL PROTECTED] then I don't see how it prevents spam. If the mail says it is from [EMAIL PROTECTED] but I cannot send a DSN to [EMAIL PROTECTED] then the account is most likely bogus sender and is refused. It works wonders for spam. DSN has a specific definition -- look in the RFCs as I don't remember which RFC it is offhand. But you are supposed to always accept a DSN from as part of the RFCs Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
John L wrote: I phrased it wrong. You are not responsible for the content, but you are responsible for the mail domain and that includes verifying that mail is validly from your domain you are responsible for. Oh, OK. So if someone sends pump and dump with a [EMAIL PROTECTED] return address, and I do a callback and your MTA says yup! that's a 100% valid address! then I turn you in to the SEC, rignt? You have now confirmed that the mail is from you, after all. Or if you haven't, what purpose did the callback serve? There is some reasonable validation technology coming along, most notably DKIM which which I presume you are familiar. But callbacks are not it. I agree. callbacks are not enough, you can reach a false conclusion, that´s why I use SPF along with callbacks... on the same message, my MX concludes: you are sending email from [EMAIL PROTECTED], but shire.net says YOUR IP address is not allowed to send email on behalf of that domain, therefore YOU ARE FAKE/FORGED ..--- reject regards, -- MSc. Marcelo Maraboli Rosselott Jefe Area de Redes y Comunicaciones (Network UNIX Systems Engineer) Ingeniero Civil Electronico, CISSP (Electronic Engineer, CISSP, MSc.) Direccion Central de Servicios Computacionales (DCSC) Universidad Tecnica Federico Santa Maria phone: +56 32 2654071 Chile.http://www.usm.cl http://elqui.dcsc.utfsm.cl ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Tool for validating sender address as spam-fighting technique?
smf-sav is one sendmail milter which does this: http://smfs.sourceforge.net/smf-sav.html SAV v1.3.0 - console utility for e-Mail Sender Address Verification (also at http://smfs.sf.net/ ) Cheers, Phil -Original Message- From: Kelly Jones [mailto:[EMAIL PROTECTED] Sent: 10 March 2007 19:28 To: freebsd-questions@freebsd.org; users@spamassassin.apache.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Tool for validating sender address as spam-fighting technique? To fight spam, I want to validate the address (not necessarily in real-time) of the a given email sender. Is there a Unix tool that does this? The basics are simple: to validate [EMAIL PROTECTED], I connect to the MX record of wnonline.net and go as far as RCPT TO as follows: host -t mx wnonline.net wnonline.net mail is handled by 5 wnspf.bayou.com. telnet wnspf.bayou.com. 25 Trying 209.209.192.75... Connected to wnspf.bayou.com.. Escape character is '^]'. 220 Welcome to Bayou mxfilter HELO domaintester.com 250 mxfilter.bayou.com MAIL FROM: [EMAIL PROTECTED] 250 Ok RCPT TO: [EMAIL PROTECTED] 550 [EMAIL PROTECTED]: Recipient address rejected: 5.1.1 [EMAIL PROTECTED]... User unknown QUIT 221 Bye Connection closed by foreign host. This tells me [EMAIL PROTECTED] is an invalid address and that mail from that address is probably bogus. A more sophisticated tool would cache results, handle temporary failures (eg, inability to connect to the MX server), handle multiple MX records, perhaps even publish results [carefully, to avoid giving spammers a source of legit email addresses!], etc. Plus, I'd prefer to use a tested tool vs hacking something up myself. I realize this technique is far from perfect: Spammers spoof legit addresses Bounces/Mailing lists/etc legitimately use do not reply addresses It could be considered unfriendly to the target MX servers Some mail servers incorrectly say user unknown when they see spam, figuring it's more of a deterrent than saying you're a spammer Some mail servers inefficiently accept mail for [EMAIL PROTECTED] (where xxx.com is one of their domains), figure out if foo exists later, and send a bounce back to the envelope sender, instead of rejecting email at the SMTP level (a really good tool would create throwaway addresses to catch these cases too) ... but I still think it might help. -- We're just a Bunch Of Regular Guys, a collective group that's trying to understand and assimilate technology. We feel that resistance to new ideas and technology is unwise and ultimately futile. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
for what it's worth, I would suggest *not* adopting this as an anti-spam technique. Sender-address verification is _bad_ as an anti-spam technique, in my opinion. Basically, there's one obvious response for spammers looking to evade it -- use real sender addresses. Where's an easy place to find real addresses? On the list of target addresses they're spamming! Hence, the spam recipients now get twice as much mail from each spam run -- spam aimed at them, *and* bounce blowback from hundreds of spams aimed at others, forged to appear to be from them. It's the obvious response to SAV, which is one reason why we never implemented something like that in SpamAssassin. --j. Kelly Jones writes: To fight spam, I want to validate the address (not necessarily in real-time) of the a given email sender. Is there a Unix tool that does this? The basics are simple: to validate [EMAIL PROTECTED], I connect to the MX record of wnonline.net and go as far as RCPT TO as follows: host -t mx wnonline.net wnonline.net mail is handled by 5 wnspf.bayou.com. telnet wnspf.bayou.com. 25 Trying 209.209.192.75... Connected to wnspf.bayou.com.. Escape character is '^]'. 220 Welcome to Bayou mxfilter HELO domaintester.com 250 mxfilter.bayou.com MAIL FROM: [EMAIL PROTECTED] 250 Ok RCPT TO: [EMAIL PROTECTED] 550 [EMAIL PROTECTED]: Recipient address rejected: 5.1.1 [EMAIL PROTECTED]... User unknown QUIT 221 Bye Connection closed by foreign host. This tells me [EMAIL PROTECTED] is an invalid address and that mail from that address is probably bogus. A more sophisticated tool would cache results, handle temporary failures (eg, inability to connect to the MX server), handle multiple MX records, perhaps even publish results [carefully, to avoid giving spammers a source of legit email addresses!], etc. Plus, I'd prefer to use a tested tool vs hacking something up myself. I realize this technique is far from perfect: Spammers spoof legit addresses Bounces/Mailing lists/etc legitimately use do not reply addresses It could be considered unfriendly to the target MX servers Some mail servers incorrectly say user unknown when they see spam, figuring it's more of a deterrent than saying you're a spammer Some mail servers inefficiently accept mail for [EMAIL PROTECTED] (where xxx.com is one of their domains), figure out if foo exists later, and send a bounce back to the envelope sender, instead of rejecting email at the SMTP level (a really good tool would create throwaway addresses to catch these cases too) ... but I still think it might help. -- We're just a Bunch Of Regular Guys, a collective group that's trying to understand and assimilate technology. We feel that resistance to new ideas and technology is unwise and ultimately futile. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 6:31 AM, Justin Mason wrote: for what it's worth, I would suggest *not* adopting this as an anti-spam technique. Sender-address verification is _bad_ as an anti-spam technique, in my opinion. Basically, there's one obvious response for spammers looking to evade it -- use real sender addresses. Where's an easy place to find real addresses? On the list of target addresses they're spamming! This is a red-herring. They already do that. They have been doing that for a long time. And it has nothing to do with sender verification. Sender verification works and works well. Hence, the spam recipients now get twice as much mail from each spam run -- spam aimed at them, *and* bounce blowback from hundreds of spams aimed at others, forged to appear to be from them. It's the obvious response to SAV, which is one reason why we never implemented something like that in SpamAssassin. Sorry, but you conclusion does not follow. Sender verification has been around for a while and this has not happened in my experience. Ie, there is no greater use of real FROM addresses than there was before. Most MTAs have in-built routines to do this, with exim having a particularly good facility for this. Technically, with exim's, you are actually validating the sending server's adherence to the RFCs about accept DSN replies back. Chad --j. Kelly Jones writes: To fight spam, I want to validate the address (not necessarily in real-time) of the a given email sender. Is there a Unix tool that does this? The basics are simple: to validate [EMAIL PROTECTED], I connect to the MX record of wnonline.net and go as far as RCPT TO as follows: host -t mx wnonline.net wnonline.net mail is handled by 5 wnspf.bayou.com. telnet wnspf.bayou.com. 25 Trying 209.209.192.75... Connected to wnspf.bayou.com.. Escape character is '^]'. 220 Welcome to Bayou mxfilter HELO domaintester.com 250 mxfilter.bayou.com MAIL FROM: [EMAIL PROTECTED] 250 Ok RCPT TO: [EMAIL PROTECTED] 550 [EMAIL PROTECTED]: Recipient address rejected: 5.1.1 [EMAIL PROTECTED]... User unknown QUIT 221 Bye Connection closed by foreign host. This tells me [EMAIL PROTECTED] is an invalid address and that mail from that address is probably bogus. A more sophisticated tool would cache results, handle temporary failures (eg, inability to connect to the MX server), handle multiple MX records, perhaps even publish results [carefully, to avoid giving spammers a source of legit email addresses!], etc. Plus, I'd prefer to use a tested tool vs hacking something up myself. I realize this technique is far from perfect: Spammers spoof legit addresses Bounces/Mailing lists/etc legitimately use do not reply addresses It could be considered unfriendly to the target MX servers Some mail servers incorrectly say user unknown when they see spam, figuring it's more of a deterrent than saying you're a spammer Some mail servers inefficiently accept mail for [EMAIL PROTECTED] (where xxx.com is one of their domains), figure out if foo exists later, and send a bounce back to the envelope sender, instead of rejecting email at the SMTP level (a really good tool would create throwaway addresses to catch these cases too) ... but I still think it might help. -- We're just a Bunch Of Regular Guys, a collective group that's trying to understand and assimilate technology. We feel that resistance to new ideas and technology is unwise and ultimately futile. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions- [EMAIL PROTECTED] --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Sun, Mar 11, 2007 at 12:41:48PM -0600, Chad Leigh -- Shire.Net LLC wrote: On Mar 11, 2007, at 6:31 AM, Justin Mason wrote: for what it's worth, I would suggest *not* adopting this as an anti-spam technique. Sender-address verification is _bad_ as an anti-spam technique, in my opinion. Basically, there's one obvious response for spammers looking to evade it -- use real sender addresses. Where's an easy place to find real addresses? On the list of target addresses they're spamming! This is a red-herring. They already do that. They have been doing that for a long time. And it has nothing to do with sender verification. Sender verification works and works well. I hate sender verification because it forces me (the sender) to jump through hoops just for the privilege of sending email to you. I send a lot of courtesy emails to e.g. port maintainers who have problems with their ports, and when I encounter someone with such a system I usually don't bother following up (their port just gets marked broken in the usual way, and they can follow up on it on their own if they want to). Kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 1:36 PM, Kris Kennaway wrote: On Sun, Mar 11, 2007 at 12:41:48PM -0600, Chad Leigh -- Shire.Net LLC wrote: On Mar 11, 2007, at 6:31 AM, Justin Mason wrote: for what it's worth, I would suggest *not* adopting this as an anti-spam technique. Sender-address verification is _bad_ as an anti-spam technique, in my opinion. Basically, there's one obvious response for spammers looking to evade it -- use real sender addresses. Where's an easy place to find real addresses? On the list of target addresses they're spamming! This is a red-herring. They already do that. They have been doing that for a long time. And it has nothing to do with sender verification. Sender verification works and works well. I hate sender verification because it forces me (the sender) to jump through hoops just for the privilege of sending email to you. No, it forces you to set up a correct RFC abiding system I send a lot of courtesy emails to e.g. port maintainers who have problems with their ports, and when I encounter someone with such a system I usually don't bother following up (their port just gets marked broken in the usual way, and they can follow up on it on their own if they want to). If your system is following the RFCs then you should have no problems. YOU should fix your broken system. Sending emails without a valid from address is disconsiderate. Why should I accept a mail from an account that violates the RFCs about accepting DSN back? Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Sun, Mar 11, 2007 at 01:43:22PM -0600, Chad Leigh -- Shire.Net LLC wrote: On Mar 11, 2007, at 1:36 PM, Kris Kennaway wrote: On Sun, Mar 11, 2007 at 12:41:48PM -0600, Chad Leigh -- Shire.Net LLC wrote: On Mar 11, 2007, at 6:31 AM, Justin Mason wrote: for what it's worth, I would suggest *not* adopting this as an anti-spam technique. Sender-address verification is _bad_ as an anti-spam technique, in my opinion. Basically, there's one obvious response for spammers looking to evade it -- use real sender addresses. Where's an easy place to find real addresses? On the list of target addresses they're spamming! This is a red-herring. They already do that. They have been doing that for a long time. And it has nothing to do with sender verification. Sender verification works and works well. I hate sender verification because it forces me (the sender) to jump through hoops just for the privilege of sending email to you. No, it forces you to set up a correct RFC abiding system I send a lot of courtesy emails to e.g. port maintainers who have problems with their ports, and when I encounter someone with such a system I usually don't bother following up (their port just gets marked broken in the usual way, and they can follow up on it on their own if they want to). If your system is following the RFCs then you should have no problems. YOU should fix your broken system. Sending emails without a valid from address is disconsiderate. Why should I accept a mail from an account that violates the RFCs about accepting DSN back? Perhaps we are talking about different things, I am talking about systems which send me an email back requiring me to do steps a, b or c in order to complete delivery of the email. kris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
Perhaps we are talking about different things, I am talking about systems which send me an email back requiring me to do steps a, b or c in order to complete delivery of the email. that's challenge/response, which has been widely discredited for years. SAV is a receiving MX probing the MX of [EMAIL PROTECTED] for verification of sender as known recipient. Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 1:44 PM, John Levine wrote: Sender verification works and works well. I suppose that if you define works to include mailbombing innocent third parties, then that might be true. I have some fairly heavily forged domains, and on a bad day I see upwards of 300,000 connections from bounces, validation, and the like attacking the little BSD box under my desk where the MTA is. Gee, thanks a lot. Verification has nothing to do with bounces and mail bombs. You may get some traffic from verification but you would need to separate that out from the rest which is unrelated before you have a meaningful statistic. Sorry, but you conclusion does not follow. Sender verification has been around for a while and this has not happened in my experience. Ie, there is no greater use of real FROM addresses than there was before. What planet have you been on? A few years back spam return addresses were typically complete fakes in nonexistent domains. Now they're picked out of the same victim lists as the targets. They have been doing that for ages. I run a hosting service and have had that problem way before sender verification became in vogue. I've had to locally blacklist a few places specifically because of all of their abusive verification. If that's what you want, well ... That is up to you. If you claim to handle mail services for a certain domain, that includes verifying that mail is from you or not. YOU are responsible for the mail sent with your domain on it. Oh, and the way my MTA is set up, a verification callback doesn't work. But that doesn't keep the clueless from trying. That is your business. But you are in violation of the RFCs Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 1:46 PM, Kris Kennaway wrote: On Sun, Mar 11, 2007 at 01:43:22PM -0600, Chad Leigh -- Shire.Net LLC wrote: On Mar 11, 2007, at 1:36 PM, Kris Kennaway wrote: On Sun, Mar 11, 2007 at 12:41:48PM -0600, Chad Leigh -- Shire.Net LLC wrote: On Mar 11, 2007, at 6:31 AM, Justin Mason wrote: for what it's worth, I would suggest *not* adopting this as an anti-spam technique. Sender-address verification is _bad_ as an anti-spam technique, in my opinion. Basically, there's one obvious response for spammers looking to evade it -- use real sender addresses. Where's an easy place to find real addresses? On the list of target addresses they're spamming! This is a red-herring. They already do that. They have been doing that for a long time. And it has nothing to do with sender verification. Sender verification works and works well. I hate sender verification because it forces me (the sender) to jump through hoops just for the privilege of sending email to you. No, it forces you to set up a correct RFC abiding system I send a lot of courtesy emails to e.g. port maintainers who have problems with their ports, and when I encounter someone with such a system I usually don't bother following up (their port just gets marked broken in the usual way, and they can follow up on it on their own if they want to). If your system is following the RFCs then you should have no problems. YOU should fix your broken system. Sending emails without a valid from address is disconsiderate. Why should I accept a mail from an account that violates the RFCs about accepting DSN back? Perhaps we are talking about different things, I am talking about systems which send me an email back requiring me to do steps a, b or c in order to complete delivery of the email. No, we are talking about the MTA verifying that the sender address is a real address that can accept either mail back or at least a properly formatted DSN back. The things you talk about ARE a PITA and I usually ignore them unless the person is wanting to give me money... (Ie a customer who placed an order with another business I run for example). Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
I have some fairly heavily forged domains, and on a bad day I see upwards of 300,000 connections from bounces, validation, and the like attacking the little BSD box under my desk where the MTA is. Gee, thanks a lot. Verification has nothing to do with bounces and mail bombs. You may get some traffic from verification but you would need to separate that out from the rest which is unrelated before you have a meaningful statistic. I have, it's meaningful. Verizon is the worst offender, but at least they put their attack hosts in a separate easy to block IP range. What planet have you been on? A few years back spam return addresses were typically complete fakes in nonexistent domains. Now they're picked out of the same victim lists as the targets. They have been doing that for ages. I run a hosting service and have had that problem way before sender verification became in vogue. Definitely different planets. Bye. R's, John PS: YOU are responsible for the mail sent with your domain on it. Oh, OK. So when someone sends out mail with your forged return address saying buy this worthless stock, then get your kiddy porn here, you will report directly to jail without complaining, right? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
Sender verification works and works well. I suppose that if you define works to include mailbombing innocent third parties, then that might be true. I have some fairly heavily forged domains, and on a bad day I see upwards of 300,000 connections from bounces, validation, and the like attacking the little BSD box under my desk where the MTA is. Gee, thanks a lot. Sorry, but you conclusion does not follow. Sender verification has been around for a while and this has not happened in my experience. Ie, there is no greater use of real FROM addresses than there was before. What planet have you been on? A few years back spam return addresses were typically complete fakes in nonexistent domains. Now they're picked out of the same victim lists as the targets. I've had to locally blacklist a few places specifically because of all of their abusive verification. If that's what you want, well ... Oh, and the way my MTA is set up, a verification callback doesn't work. But that doesn't keep the clueless from trying. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 2:08 PM, John Levine wrote: I have some fairly heavily forged domains, and on a bad day I see upwards of 300,000 connections from bounces, validation, and the like attacking the little BSD box under my desk where the MTA is. Gee, thanks a lot. Verification has nothing to do with bounces and mail bombs. You may get some traffic from verification but you would need to separate that out from the rest which is unrelated before you have a meaningful statistic. I have, it's meaningful. Verizon is the worst offender, but at least they put their attack hosts in a separate easy to block IP range. Amazing, as I run mail for lots of domains, and replying to sender verification is almost a nonexistent load compared to the mail bombs and bounces etc. Show me your numbers. What planet have you been on? A few years back spam return addresses were typically complete fakes in nonexistent domains. Now they're picked out of the same victim lists as the targets. They have been doing that for ages. I run a hosting service and have had that problem way before sender verification became in vogue. Definitely different planets. Bye. When you come back to earth, let us know :-) R's, John PS: YOU are responsible for the mail sent with your domain on it. Oh, OK. So when someone sends out mail with your forged return address saying buy this worthless stock, then get your kiddy porn here, you will report directly to jail without complaining, right? I phrased it wrong. You are not responsible for the content, but you are responsible for the mail domain and that includes verifying that mail is validly from your domain you are responsible for. email is a cooperative service where all people promise to expend resources to make it work, and to follow the RFCs. If you block valid verification, you are abrogating your responsibility to the rest of the net to cooperate in the exchange of email and you are breaking the RFCs. (valid verification includes checking that the sender can accept a proper DSN back, which is required of the sender to do). Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
I phrased it wrong. You are not responsible for the content, but you are responsible for the mail domain and that includes verifying that mail is validly from your domain you are responsible for. Oh, OK. So if someone sends pump and dump with a [EMAIL PROTECTED] return address, and I do a callback and your MTA says yup! that's a 100% valid address! then I turn you in to the SEC, rignt? You have now confirmed that the mail is from you, after all. Or if you haven't, what purpose did the callback serve? There is some reasonable validation technology coming along, most notably DKIM which which I presume you are familiar. But callbacks are not it. and you are breaking the RFCs. (valid verification includes checking that the sender can accept a proper DSN back, which is required of the sender to do). Uh huh. Which RFC is this that says I have to permit a fake partial DSN transaction? If you have a DSN, send it. If you don't, don't. Don't forget that the From: line address need not be the same as the bounce address; in my mail it never is. R's, John ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 2:55 PM, John L wrote: I phrased it wrong. You are not responsible for the content, but you are responsible for the mail domain and that includes verifying that mail is validly from your domain you are responsible for. Oh, OK. So if someone sends pump and dump with a [EMAIL PROTECTED] return address, and I do a callback and your MTA says yup! that's a 100% valid address! then I turn you in to the SEC, rignt? You do know what the SEC is, right? You have now confirmed that the mail is from you, after all. No, it only confirms that the sender address is an actual address. Or if you haven't, what purpose did the callback serve? It served to identify that it is possible a valid email. A failure is almost definitely a non valid email. It is a test which helps determine whether to accept it. We have a policy of not accepting mail from people who cannot accept DSNs back. That does not mean we give a blanket pass to those who pass address verification. There is some reasonable validation technology coming along, most notably DKIM which which I presume you are familiar. But callbacks are not it. Callbacks are one tool in the toolbox. Maybe someday there will be better tools and we can retire address verification. Callbacks, at this point in time, work very well for differentiating a large amount of non valid mail from a smaller pool of possibly valid mail. DKIM is interesting and I am watching it.I am in the process of adding some support for it btw, both for our authorized senders, as well as in our receive phase. For example, we are considering not doing address verification on incoming mail that has a valid DKIM signature. and you are breaking the RFCs. (valid verification includes checking that the sender can accept a proper DSN back, which is required of the sender to do). Uh huh. Which RFC is this that says I have to permit a fake partial DSN transaction? If you have a DSN, send it. If you don't, don't. The RFCs require you to accept back DSNs. Testing that you do is a valid test to see if I am talking with a valid sender -- one who implements the RFCs and is not a rogue internet user who does not cooperate in the exchange of emails according to the agreed standards. Show me some real verifiable numbers that show that verification traffic to your box is a significant portion of the otherwise bad traffic of mail bombs, bounces, etc. On my system, and we support a lot of mail domains, some of which (now or in recent past) we big name domains that had a lot of exposure. Address verification traffic has always been small compared to our overall load. You are complaining about a non issue. I can say that address verification helps us reject the lion's share of spam we receive without having to process it further. Chad Don't forget that the From: line address need not be the same as the bounce address; in my mail it never is. R's, John --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
onfirmed that the mail is from you, after all No. His MX has only verified his email address, which does not say he sent the msg. Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
onfirmed that the mail is from you, after all No. His MX has only verified his email address, which does not say he sent the msg. Then what was the point? His MX has only verified his email address Len ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
[mailed and posted] On Mar 10, 2007, at 1:27 PM, Kelly Jones wrote: To fight spam, I want to validate the address (not necessarily in real-time) of the a given email sender. Is there a Unix tool that does this? The basics are simple: to validate [EMAIL PROTECTED], I connect to the MX record of wnonline.net and go as far as RCPT TO as follows: [...] RCPT TO: [EMAIL PROTECTED] 550 [EMAIL PROTECTED]: Recipient address rejected: 5.1.1 [EMAIL PROTECTED]... User unknown This tells me [EMAIL PROTECTED] is an invalid address and that mail from that address is probably bogus. A more sophisticated tool would cache results, handle temporary failures [...] In some anti-spam discussions what you are proposing is referred to as call-backs. I realize this technique is far from perfect: Spammers spoof legit addresses Indeed they do. As someone who has at times received more than 100 bounces per minute over the span of a week because some spammer decided that my address would be a good one to forge, I am well aware of that. In general, we have a question of how well any spamming counter measure scales. If most SMTP servers did the kind of verification you wish to do, than most spam would be sent with forged genuine addresses. So when considering using such a system, consider the overall cost to legitimate users vs the counter counter measures spammers will take. In this case the counter counter measures available to spammers is so much easier and cheaper than the verification system itself, that it's not really a good idea to try such verification. Bounces/Mailing lists/etc legitimately use do not reply addresses It could be considered unfriendly to the target MX servers As you've already seen, some managers of MXes complain, others find the added load negligible. Some mail servers incorrectly say user unknown when they see spam, figuring it's more of a deterrent than saying you're a spammer Yes. An unknown user response is more likely to get the address removed from a list than a policy bounce. Some mail servers inefficiently accept mail for [EMAIL PROTECTED] (where xxx.com is one of their domains), figure out if foo exists later, and send a bounce back to the envelope sender, instead of rejecting email at the SMTP level Yes. While I'm a believer in reject early, reject often lots of sites don't or can't say that an address is bad at SMTP RCPT TO: time. Often these are situations where an MS-Exchange server is the real mailhub for an organization, but it is being protected from direct access from the Internet by having a Unix box stand between it and the network. Other MTAs just accept and then bounce (instead of rejected at SMTP time) as a matter of (mis)design. Some very deliberately don't provide verification at STMP time as a means to make it harder for spammers to collect email addresses. Indeed, this is why the VRFY command is almost never implemented by STMP servers these days. Anyway, others have pointed you to tools for doing what you want. The newsgroups or mailing lists (and FAQs) for the particular MTA you use will point you to how to plug in such tools into their MTA. As I've suggested, I'm not a particular fan of this particular counter measure, but you will have seen that opinions differ. Cheers, -j -- Jeffrey Goldberghttp://www.goldmark.org/jeff/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tool for validating sender address as spam-fighting technique?
On Mar 11, 2007, at 5:11 PM, Jeffrey Goldberg wrote: In this case the counter counter measures available to spammers is so much easier and cheaper than the verification system itself, that it's not really a good idea to try such verification. that is always true, at least with existing technology. The counter measures always cost more than the sending of the spam Chad --- Chad Leigh -- Shire.Net LLC Your Web App and Email hosting provider chad at shire.net ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
