Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
Phil Vandry wrote: On Tue, Jul 01, 2008 at 11:54:46AM +0200, Jeroen Massar wrote: The magic keyword: REJECT-ON-SMTP-DATA. [snip description on how to reject during DATA phase] Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can More than that: you also need to have all users in the domain (indeed all users who share an MX server) agree on the accept/reject policy. If users are free to use different spam filtering techniques and tune them to their liking (e.g. someone uses SpamAssassin with a low threshold, someone else uses it with a high threshold, someone else uses bogofilter instead) then what do you do with mails that are addresses to more than one user? You can have some users reject the message during the RCPT phase and others accept it, but if you've waited until the DATA phase, it's too late for that. Phil, This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed. http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html Justin
RE: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
I think the problem that was being raised here was that past the DATA phase, if one recipient is going to receive the message and another is going to reject it, you have lost the ability to communicate this back to the sender (at least without an NDR). Thus the problem of mails disappearing into spam folder black holes is back in the multirecipient case when one is dealing with DATA and recipients have differing spam policies. - S -Original Message- From: Justin Shore [mailto:[EMAIL PROTECTED] Sent: Saturday, July 05, 2008 2:05 AM To: Phil Vandry Cc: [EMAIL PROTECTED] Subject: Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs) Phil, This is a non-problem if you use the right spam filter. I mentioned CanIt earlier in the thread. It individually applies filtering rules to incoming mail and can apply different rules and take actions on a per-user basis. It handles messages with multiple recipients by feeding copies of the message into an individual user's stream where that user's settings dictate what actions are taken. A user may have an aggressive spam score or an extremely conservative score, message rejection with SpamHaus and SORBS or no DNSBLs at all, tons of custom rules and lots of bells and whistles or spam filtering disabled completely. They've already anticipated all the possible problems that have been brought up in this thread. Arrange for a demo and give it a try. I don't think you'd be disappointed. http://mailman.nanog.org/pipermail/nanog/2008-July/001884.html Justin
Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
one note about whether to filter at receiving SMTP server or later. The receiving SMTP server is the one that has the conversation with the sender. Rejecting mail from servers having an un-backtranslatable IP is best done right away by the receiving server right after the HELO command by issuing error message about the IP being unbacktranslatable. Reduces the load. later on (for instance at the client level), you need to parse the RFC822 text header and there are some bits that are missing, notably the RCPT TO: commands. This is especially true when the TO in the 822 header is faked. Blocking messages as early as possible also greatly reduces the load on your system, disk storage requirements etc.
Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
Jean-François Mezei wrote: Blocking messages as early as possible also greatly reduces the load on your system, disk storage requirements etc. Rejecting during the SMTP dialog but before you signal that you've accepted the DATA output also also pushes the responsibility for sending a DSN to the sending MTA. It's is a spammer then they'll drop the DSN. If it's a compromised PC running Storm Worm or the like it won't generate DSNs anyway. If it's a legit but poorly-configured MTA acting as an open relay it will generate the DSN and eventually get itself blacklisted. Sending a DSN to a spoofed envelope From is considered spam in and of itself and will get an MTA blacklisted. You could always not send DSNs in which case the sender of a legit message that had a few to many !!!s in it will not get a bounce and will not know that there message was blocked. It disappears into an email blackhole. Few things piss off users like disappearing email. It's best all around to force the sending MTA to send the bounce. Your MTA doesn't get blacklisted, spammers' relays are forced to do a little extra work, and senders of legit mail that's a false-positive get a DSN telling them that their message didn't go through (and hopefully why). Everyone wins. Block early and block often. Justin
REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
Chris Owen [EMAIL PROTECTED] wrote It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying No, we really did not receive it. The magic keyword: REJECT-ON-SMTP-DATA. Aka during the DATA phase of the email, also directly scan it, then when the spam/virus tool thinks it is spam/virus, you just reject it. This solves a couple of things in one go: - You don't have to handle bounces if you would send a bounce back to the sender hey you had a spam/virus because you already accepted the mail, thus less overhead at least there - The sending SMTP server will send a bounce back to the sender. The sender thus gets a SMTP rejection mail, with the rejection reason and knows that you didn't accept the message and why. They can then opt to change the content of the mail or contact you differently. - No more 'spam' folder, as the stuff that is spam is already rejected. You might get a few mails through that are actually spam, but this is mostly marginal. This thus solves completely that email gets lost. Also note that if a virus/bot or something else silly is trying to send these mails it either has to handle the bounces, which they generally (afaik ;) don't, thus the faked sender doesn't get a swamp of failed deliveries either. This is a Win-Win situation in my ears. Unfortunately there is also a side-effect, partially, one has to have all inbound servers use this trick, and it might be that they need to be a bit heavier to process and scan all that mail. Then again, you can better let sending SMTP servers queue a bit (or throttle them) then having to process them anyway later. Of course not all mail platforms can be fitted in this way, but people who have such systems probably already have other ways to handle things. For the excellent Spamassassin, read: http://wiki.apache.org/spamassassin/IntegratedInMta The 'milter' options (originally sendmail, but nowadays also available for other mailers) can do this for you. Other anti-spam tools might also be able to do similar things. YMMV. Oh and of course as a access-ISP, one should also employ this trick to the customers, that way they know that they are sending spam ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature
Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)
Chris Owen wrote: The lack of a spam folder is one of the problems with such a solution. Having a middle ground quarantine is actually quite nice. However, the biggest problem is these solutions are global in nature. We let individual customers considerable control over the process. They can each set their own block and quarantine levels, configure their own white and blacklists and even turn the spam controls completely off. For various reasons none of that would be possible with this solution and all the implementations you link to all run with a single global configuration. Chris, I can think of one spam filter that does give both you and your users individual control over all of these settings while still rejecting mail during the SMTP dialog including the DATA phase: CanIt-Pro. http://www.roaringpenguin.com/ CanIt-Pro is a mail filter or 'milter' in Sendmail-speak. It essentially connects into Sendmail from the side. Sendmail calls on it during the SMTP dialog with the remote MTA, giving CanIt-Pro the opportunity to work its magic before the message is accepted for delivery which allows from rejecting mail right up until the last second RFC 2821 permits it. I use CanIt-Pro for this very reason. Each user can have their own individual mail stream in CanIt terminology. Each user can define white/blacklists by senders, domains and hosts. Users can block or permit by MIME types or perform actions based on attachment suffixes. They can write their own rules with regexs against the headers or body as well as checking to see if a sending domain matches that of the relaying MTA (not always accurate but often is; ebay.com is a good example). Users can enable or disable individually configured DNSBLs or change the score. They can even define rules based on SPF values. Each user gets their own bayesian DB as well. You as an admin can disable any of the above features on a per-user basis so you can make it as simple or as complex as you want. You can also pre-define streams with specific settings that users can subscribe to if they don't want the more fine-grained control. I created a stream that only tags suspect spam. I also created 3 streams with varying levels of aggressiveness. Have you ever heard the phrase a pilot's plane? Well I would liken CanIt to being the equivalent for mail admins and their spam filters. I first started using the OSS predecessor to CanIt back in late 2000 or so called MIMEDefang. MD is still the underpinnings of CanIt. When you buy CanIt you also get the source code so you have the ability to code in custom things if you have the need and desire. It's perfect for SPs. BTW, I'm not a Roaring Penguin employee. I'm just an impressed user of their products so they've earned my loyalty. Justin
Re: Mail Server best practices - was: Pandora's Box of new TLDs
On Sun, Jun 29, 2008 at 03:30:15PM -0500, Frank Bulk - iNAME [EMAIL PROTECTED] wrote a message of 35 lines which said: Because if you do anything, even as basic as RBLs, you're not being consistent with your stance. The typical use of RBLs is to reject email at the SMTP level, when it matches an entry in the RBL. That way, the sender is warned that something went wrong, email does not disappear silently.
Re: Mail Server best practices - was: Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen [EMAIL PROTECTED] wrote a message of 53 lines which said: It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying No, we really did not receive it. In article !!AAAuAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAA [EMAIL PROTECTED], Frank Bulk - iNAME [EMAIL PROTECTED] writes You mean, you don't employ *any* spam mitigation techniques besides sorting? Because if you do anything, even as basic as RBLs, you're not being consistent with your stance. I agree completely with Chris Owen's approach, even though I use spam mitigation techniques. The reason for this is because those lost emails that I very occasionally rescue from the spam bucket are: NOT sent by someone on an RBL NOT sent to an unpublished and unused address (eg [EMAIL PROTECTED]) etc. -- Roland Perry
Re: Mail Server best practices - was: Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 05:56:23PM -0400, Jean-Fran?ois Mezei wrote: The original mantra of either discarding the email during SMTP conversation, or sending a non delivery notification should be strictly adhered to. When email becomes unreliable (thanks to microsoft), people stop using it. I agree with your sentiments -- that notification is essential in order to provide a heads-up about problems (and that once problems are noticed, cooperation is essential in order to fix them). But mail should never be discarded without notice, and NDN's should never be sent (MTA-to-MTA, which is a different matter than MSA-to-MTA): it should either be accepted (and delivered) or rejected (and not delivered). This provides accurate notification to the sending MTA of the disposition of the message, and it avoids outscatter spam. Of course, this doesn't do anything to elicit cooperation from either side, but at least it makes problems visible (provided nobody's MTA mangles or drops the reject notice) so that there's a decent chance of figuring *whose* cooperation is needed. ---Rsk
Re: Mail Server best practices - was: Pandora's Box of new TLDs
On Sat, 28 Jun 2008 17:25:16 -0500 Chris Owen [EMAIL PROTECTED] wrote: [snip] So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com). Of course you shouldn't accept and bounce them; you should not accept them at all. Reject them up front. -- John
Re: Mail Server best practices - was: Pandora's Box of new TLDs
Rich Kulawiec wrote: notification is essential in order to provide a heads-up about problems (and that once problems are noticed, cooperation is essential in order to fix them). But mail should never be discarded without notice In practice we've found that (notification) is the core issue. Reject v discard is a non-issue by comparison. The format of those notifications does not have to be a spam folder, as many seem to assume. A summary report serves the purpose far better than tagging and delivery with far less overhead. Quoting http://www.postconf.com/docs/spamrep/ : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. This is more or less identical to the issue ISP's like Comcast face when implementing QOS or other filtering, when they fail to notify end-users. Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted. Roger Marquis
Re: Mail Server best practices - was: Pandora's Box of new TLDs
On Sun, Jun 29, 2008 at 07:55:07AM -0700, Roger Marquis wrote: Quoting http://www.postconf.com/docs/spamrep/ : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. Two comments: First, it is impossible to avoid false positives (unless you turn all spam filtering off) or false negatives (unless you block everything). The discussion thus shouldn't focus on 0% FP, 0% FN, but on how to minimize both simultaneously such that the percentages are acceptable to the receiving organization. (Note as well that FP and FN are always defined on recipient side, never the sender side.) Second, while in principle this isn't a bad approach, in reality it tends not to work well. It requires that users weed through the daily reports (which they won't) and determine what's spam/not-spam (which they'll get wrong) and it requires accepting and storing considerable volumes of mail which are likely spam/phish/virus/etc. It also can make FP detection difficult, since senders do not get a reject (mail was accepted, after all; why should they?) and thus may be unaware that their message was dropped in a probable-spam folder. I find it's much better to reject outright with a very clear error message (that provides recourse for senders who believe it to be in error) and then address the resulting issues at the postmaster level (since in most environments such issues are likely to effect more than one user). ---Rsk
Re: Mail Server best practices - was: Pandora's Box of new TLDs
[Wow, operational content!] On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen [EMAIL PROTECTED] wrote a message of 53 lines which said: At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null? To me, there is a huge difference. I send no mail to Dave Null, everything goes into a spam folder. Do I read it? Do I review it from time to time? Never. It is too huge. So, what's the point besides bringing money to hard disk manufacturers? It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying No, we really did not receive it. In a professional environment, I would not accept the idea of email disappearing without being able to recover it.
RE: Mail Server best practices - was: Pandora's Box of new TLDs
You mean, you don't employ *any* spam mitigation techniques besides sorting? Because if you do anything, even as basic as RBLs, you're not being consistent with your stance. Frank -Original Message- From: Stephane Bortzmeyer [mailto:[EMAIL PROTECTED] Sent: Sunday, June 29, 2008 3:08 PM To: Chris Owen Cc: nanog Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs [Wow, operational content!] On Sat, Jun 28, 2008 at 05:25:16PM -0500, Chris Owen [EMAIL PROTECTED] wrote a message of 53 lines which said: At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null? To me, there is a huge difference. I send no mail to Dave Null, everything goes into a spam folder. Do I read it? Do I review it from time to time? Never. It is too huge. So, what's the point besides bringing money to hard disk manufacturers? It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying No, we really did not receive it. In a professional environment, I would not accept the idea of email disappearing without being able to recover it.
Re: Mail Server best practices - was: Pandora's Box of new TLDs
Stephane Bortzmeyer wrote: It is because, if someone reports (by telephone, IRC or IRL) that he sent an email and I did not receive it, I regard as VERY IMPORTANT to be able to check the spam folder (with a search tool, not by hand) and go back to him saying No, we really did not receive it. In a professional environment, I would not accept the idea of email disappearing without being able to recover it. In my view of a professional environment (what ever that turns out to mean) a log file would enable that, without any of the problems holding mail text might engender. Did you get the email from...to...? Yes Please tell the court what it said. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actioInfallibility, and the ability to learn from their mistakes. Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs
Re: Mail Server best practices - was: Pandora's Box of new TLDs
Rich Kulawiec wrote: Quoting http://www.postconf.com/docs/spamrep/ : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. First, it is impossible to avoid false positives (unless you turn all spam filtering off) or false negatives A bit of a Red Herring as nobody expects 100%. Second, while in principle this isn't a bad approach, in reality it tends not to work well. Judging by user acceptance, over a decade's use and several thousand users, it works better than any other method, certainly better than silently rejecting and discarding spam on the one hand, or tagging and delivering it on the other. Not that any ISP delivers everything (since ~1996). The ones that try learn a hard lesson in DOS or they lose customers (remember netcom.com). The issue isn't delivery, it's reporting, and only ISPs that inform users about _every_ rejected or discarded email are capable of effectively minimizing false positives. It requires that users weed through the daily reports Looks like you haven't looked at the reports. Nothing in them is more difficult to parse than a large spam folder. I'm guessing you also don't intend to imply that users look in their spam folder? and it requires accepting and storing considerable volumes of mail which are likely spam/phish/virus/etc. You must be talking about some other system. Volumes of mail stored in spam folders are what reports _avoid_. Simple text reports take almost no disk and, for most users, a year's worth of searchable daily reports takes just a few MBs. can make FP detection difficult, since senders do not get a reject (mail was accepted, after all; why should they?) and thus may be unaware that their message was dropped in a probable-spam folder. You really should read the URL cited above, and have a look at the sample reports. Whether spam is rejected outright or discarded after delivery is not relevant since good reports list both. Users don't make a distinction either, as long as they know what was filtered. Whether to A) reject or B) accept and discard is also a bit of a red herring. Most spam will get reject by RBLs but you still _must_ run everything else through Spamassassin and AV, and there's no way to do those checks pre-queue without SMTP timeouts and DOS. Roger Marquis
RE: Mail Server best practices - was: Pandora's Box of new TLDs
Requirement ? What requirement ? There's no requirement for reverse DNS for email in any RFC. Not that RFCs are ideal references for mail operation in general. You're right, documents published by an organization whose goal is to design internetworking protocols are not the best place to find operational advice. For that you would be better to go to an organization like MAAWG which publishes this BCP: http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pd f On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry. Perhaps the RFC series doesn't have as many gaps as we think. known-dynamic is extremely up to debate. Frankly, blacklisting entire /16s because individual customer PCs have been hijacked is absurd, but I guess colateral damage is acceptable. If collateral damage is acceptable, then how is this absurd? Once you accept that it is better to reject good email than let bad email through, the game has changed. It may end up by destroying the business usefulness of the existing email architecture, but not without a push from someone who has a better mousetrap. I'm not laying blame here, just pointing out that rejecting mail from IP addresses for which no PTR delegation exists is unwarranted, This is quite simply, wrong. It is warranted. Don't go preaching it as a best practice, though. Too late, the MAAWG has already published this as a best practice for quite some time. If you don't follow the MAAWG best practices then you are not a serious email operator. If email is mission critical to your business, then you really should be an MAAWG member as well. --Michael Dillon P.S. I personally have nothing to do with the MAAWG although my company is an active member.
Re: Mail Server best practices - was: Pandora's Box of new TLDs
[EMAIL PROTECTED] (michael.dillon) writes: http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction. On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry. Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR). Perhaps the RFC series doesn't have as many gaps as we think. For mail operations, we're half a galaxy away from be conservative in what you send, be liberal in what you accept. absurd, but I guess colateral damage is acceptable. If collateral damage is acceptable, then how is this absurd? Apologies, I was being sarcastic. Once you accept that it is better to reject good email than let bad email through, the game has changed. It may end up by destroying the business usefulness of the existing email architecture, but not without a push from someone who has a better mousetrap. Yep. This is quite simply, wrong. It is warranted. Not agreeing :) But fair enough, any site is allowed to operate mail the way it wants. Don't go preaching it as a best practice, though. Too late, the MAAWG has already published this as a best practice for quite some time. If you don't follow the MAAWG best practices then you are not a serious email operator. If email is mission critical to your business, then you really should be an MAAWG member as well. We work for several customers and operate large mail installations. We implement quite a few requirements that are fairly strict, but rejecting based on missing PTR is not one of them. Neither is blacklisting entire TLDs for that matter, but I digress. I still feel like a serious mail operator, just because I don't conclude that I as the receiver should reject mail from a host with a missing PTR, because the MAAWG *Senders* BCP says that hosts should have a reverse. Phil
RE: Mail Server best practices - was: Pandora's Box of new TLDs
Comments in-line. -Original Message- From: Phil Regnauld [mailto:[EMAIL PROTECTED] Sent: Saturday, June 28, 2008 1:02 PM To: [EMAIL PROTECTED] Cc: nanog@nanog.org Subject: Re: Mail Server best practices - was: Pandora's Box of new TLDs [EMAIL PROTECTED] (michael.dillon) writes: http://www.maawg.org/about/MAAWG_Sender_BCP/MAAWG_Senders_BCP_Combine.pdf Thanks for the pointer. I don't necessarily agree with all of it, but it's definitely a good reference. I just get irritated by actions that penalize end users who feel they don't have other options other than just using some horrible webmail service, because their operator/ISP is clueless. I do make a distinction. FB You do have an option -- ask the sender to clean up their act. Then the operator/ISP will happily receive the sender's e-mail. When one of our business customers complains to us (ISP) that they can't send e-mail to an external third-party and I find out it's due to poor configuration on their part (almost 100% of the time -- the sole exception that I can recall is a business customer's IP address being blocked by a GoDaddy RBL even though another properly SWIPed customer was sending the spam. Apparently GoDaddy's minimum block size is /24 and they can't bother to look up the ranges), I don't complain about the external third-party, I educate our business customer on best practices. On page 5 they do recommend matching reverse DNS and in Appendix A they go on to state that RFC 1912 states that all hosts on the Internet should have a valid rDNS entry. Indeed it does, but rejecting a mail based on a missing PTR is still arbitrarily useless (and I'm speaking in terms of volume of spam emanating from hosts with a missing PTR, vs spam origination from hosts that do have a PTR). FB The point is that those are able to create a valid rDNS entry likely have more control of their infrastructure than those who don't. You must admit, if you can't get a proper rDNS entry created for your domain, what does that say about your ability to control your infrastructure? Of course, the inverse it not true. snip
Re: Mail Server best practices - was: Pandora's Box of new TLDs
On Sat, Jun 28, 2008 at 2:21 PM, Frank Bulk - iNAME [EMAIL PROTECTED] wrote: FB The point is that those are able to create a valid rDNS entry likely have more control of their infrastructure than those who don't. You must admit, if you can't get a proper rDNS entry created for your domain, what does that say about your ability to control your infrastructure? And to that point, a valid rDNS entry can easily be removed by the netblock holder at smal co-lo facility. This is an easy, although not widely used enough, means for co-lo providers to retain control over leased (mail) servers without worrying about the legal issues with pre-maturely taking a customer offline. I've never seen a posted service delivery statement that guaranteed PTRs. In fact, IMHO, PTRs are a courtesy from the netblock owner, not a given. -Jim P.
Re: Mail Server best practices - was: Pandora's Box of new TLDs
re: reverse DNS and emails. There are well documented and fairly simple tasks to reduce spam. requiring rdns, using rbls and blocking certain IP blocks goes a long way. The biggest problem however are outfits like microsoft whose hotmail/msn properties have undocumented logic which confirm reception of the message at the SMTP/821 level but then proceed to discard the email instead of delivering it to the person's inbox (or spam folder). Because they are unfortunatly popular, this means that sending email to users of those systems has become untrustable since you need to phone them to ensure they got the email. And it is impossible to talk to a postmaster at hotmail to know why hotmail sometimes/often doesn't like your emails even though you abide by standard rules. (rdns, spf etc) Spam getrs you more than you bargained for, but you still get your legitimate emails. But hotmail/MSN discard legitimate emails without warning and that makes SMTP untrustable and this is a far more serious issue. The original mantra of either discarding the email during SMTP conversation, or sending a non delivery notification should be strictly adhered to. When email becomes unreliable (thanks to microsoft), people stop using it.
Re: Mail Server best practices - was: Pandora's Box of new TLDs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 28, 2008, at 4:56 PM, Jean-François Mezei wrote: The biggest problem however are outfits like microsoft whose hotmail/ msn properties have undocumented logic which confirm reception of the message at the SMTP/821 level but then proceed to discard the email instead of delivering it to the person's inbox (or spam folder). At some point what is the difference between putting the mail into a spam folder and sending them to /dev/null? Yesterday I received 4,932 emails. 294 of those went into my inbox. 36 of those went info my quarantine folder. The other 4,602 went straight to /dev/null (actually many of them went through various blacklist building scripts first). Had I put the full 4,638 into a spam folder that would have been completely worthless. It would be impossible for me to actually review all those emails. Ultimately, there wouldn't be any difference between that and /dev/null. The only difference is I would have deleted them later rather than when they came in. So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com). The size of the problem presented by spam is just enormous. Before we started selective greylisting, we used to accept a million messages a day. Of those we only delivered about 50,000. And that's for a system only handling about 5,000 email accounts. I can't even imagine having to do that on the scale hotmail is talking about. Chris Chris Owen ~ Garden City (620) 275-1900 ~ Lottery (noun): President ~ Wichita (316) 858-3000 ~A stupidity tax Hubris Communications Inc www.hubris.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Public Key: http://home.hubris.net/owenc/pgpkey.txt Comment: Public Key ID: 0xB513D9DD iEYEARECAAYFAkhmukwACgkQElUlCLUT2d0yNgCfRhVBqk3lo3X4p6pVJ8i32c4F MIEAn18tJAhIhgvWtIbuqLxFR7TKJB/q =Cump -END PGP SIGNATURE-
Re: Mail Server best practices - was: Pandora's Box of new TLDs
some folk on this list are network operators. i.e. what you do with your personal mailbox is not highly interesting. we have this silly problem called paying users. the issue is what an mta operator does for hundreds, thousands, or more of these pesky critters. at least in my world, they seem to have significantly higher tolerance for 100 spams than one dropped ham. they may whine about blow-back from a joe job, but they will go bleeping nuts if they lose one message from a legitimate contact. and i suspect that this aversion to beta errors is not irrational; think postal mail. the issue, at least to me, is keeping mail drop alpha error reasonably low while keeping beta error as close to zero as possible. so please excuse me if i do not take talk about blocking some form of dns silliness, or a continent of ip addresses, or ... very seriously. we now return you to our regular channel of telling icann what it should do at layer fourteen, a subject on which we have deep expertise. randy
Re: Mail Server best practices - was: Pandora's Box of new TLDs
So should I have bounced all 4,602? Since ninety some percent of them came from forged addresses that would not only be pointless but would be contributing to the problem (and get us into bl.spamcop.com). Of course not. You should have rejected them. Note that rejection doesn't keep you from using them to tune your filters. My MTA does much of its filtering at the end of data, and if it decides the message isn't going into the nominal recipient's mailbox, it returns a 553 status, then dumps the message into the spamtrap. R's, John
