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 t

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

Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)

I'd have to think of this one. I'm not sure what CanIt would do in such a case. A NDR may be the only way in that scenario. I'll sleep on it. Justin Skywing wrote: I think the problem that was being raised here was that past the DATA phase, if one recipient is going to receive the message

RE: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)

: 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

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

Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)

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

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 c

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: > 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 > blacklist

Re: REJECT-ON-SMTP-DATA (Re: Mail Server best practices - was: Pandora's Box of new TLDs)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 1, 2008, at 4:54 AM, Jeroen Massar wrote: Chris Owen <[EMAIL PROTECTED]> wrote I did not write this FYI. 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 IMPORTA

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 rece

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

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 ma

Re: Mail Server best practices - was: Pandora's Box of new TLDs

Rich Kulawiec wrote: Quoting : 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

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".

RE: Mail Server best practices - was: Pandora's Box of new TLDs

08 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 di

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

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 : > > 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 a

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. Rej

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). >

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.

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

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

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 di

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 recept

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

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) w

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 tha

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 n