Re: [Mailman-Developers] before next release: disable backscatter in default installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 14, 2008, at 5:38 PM, Kenneth Porter wrote: On Saturday, April 12, 2008 12:44 PM -0400 Barry Warsaw <[EMAIL PROTECTED] > wrote: Thanks! Capture here in the "best practices" section: http://wiki.list.org/display/DEV/Home Note that there

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Saturday, April 12, 2008 12:44 PM -0400 Barry Warsaw <[EMAIL PROTECTED]> wrote: > Thanks! Capture here in the "best practices" section: > > http://wiki.list.org/display/DEV/Home Note that there's already backscatter prevention info here:

Re: [Mailman-Developers] before next release: disable backscatter in default installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 26, 2008, at 7:27 AM, Ian Eiloart wrote: > >> >> I think you will be happier with what is possible in Mailman 3. In >> mm3 we have a working LMTP server, those it's based on asyncore and >> its scalability is questionable. Although I have not

Re: [Mailman-Developers] before next release: disable backscatter in default installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 25, 2008, at 5:33 AM, Julian Mehnle wrote: > Jo Rhett wrote: >> On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote: >>> I still don't get what you mean by "properly deal with DSNs". Are >>> you >>> saying that an MTA should never return a DSN? It

Re: [Mailman-Developers] before next release: disable backscatter in default installation

--On 1 April 2008 13:15:42 -0400 Dale Newfield <[EMAIL PROTECTED]> wrote: > Ian Eiloart wrote: >> Actually, I'm veering towards the notion that we should be creating a >> climate where the only sensible way to avoid collateral spam is to >> publish SPF records. > > That's not always trivial. I

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Ian Eiloart wrote: > Actually, I'm veering towards the notion that we should be creating a > climate where the only sensible way to avoid collateral spam is to publish > SPF records. That's not always trivial. I get plenty of back scatter, and I've tried to do this to reduce that, but I've bee

Re: [Mailman-Developers] before next release: disable backscatter in default installation

--On 1 April 2008 03:11:17 +0200 Mads Kiilerich <[EMAIL PROTECTED]> wrote: > Mark Sapiro wrote, On 03/31/2008 06:26 PM: >> So what do I do practically in this case. Calling out to verify the >> recipient won't help because the recipient is valid. > > I think that we - admins and developers - hav

Re: [Mailman-Developers] before next release: disable backscatter in default installation

--On 31 March 2008 09:26:08 -0700 Mark Sapiro <[EMAIL PROTECTED]> wrote: > Ian Eiloart wrote: >> [snip] > > Here's the problem. I receive a message for [EMAIL PROTECTED] which is > aliased to a few other addresses including [EMAIL PROTECTED] The MTA > (Postfix in my case) accepts the message to

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Mark Sapiro wrote, On 03/31/2008 06:26 PM: So what do I do practically in this case. Calling out to verify the recipient won't help because the recipient is valid. I think that we - admins and developers - have to realize that times are changing. Once upon a time when the RFCs were written t

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Ian Eiloart wrote: > >Their advice is plain: "Reject, Don't Bounce >The standards provide for a mail server to 'reject' a message by refusing >its transfer, rather than accepting it and risking future problems." Although this thread long ago went somewhat off topic for Mailman, I think it's valu

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett wrote: > But for various reasons many organizations publish wide-open SPF > records, and right or wrong those people will still report > backscatter to the blacklists. This is the first time I hear of this being a widespread problem. Can you please contact me off-list and give me some d

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 26, 2008, at 3:30 PM, Julian Mehnle wrote: > There are two parts to SPF: publishing SPF records for one's > domains, and > checking SPF on incoming messages. Everyone can do the SPF checking > part, even if they cannot publish SPF records themselves for whatever > reason. SPF's alias-sty

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett wrote: > On Tue, March 25, 2008 2:33 am, Julian Mehnle wrote: > > You can however safely send a DSN if an SPF[1] check for the incoming > > message passes. > > That's not "safe" but perhaps "safer". But a lot of sites can't use > SPF so they either don't use it, or use soft-fail. I would

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Tue, March 25, 2008 2:33 am, Julian Mehnle wrote: > You can however safely send a DSN if an SPF[1] check for the incoming > message passes. That's not "safe" but perhaps "safer". But a lot of sites can't use SPF so they either don't use it, or use soft-fail. I would only trust SPF results fro

Re: [Mailman-Developers] before next release: disable backscatter in default installation

> > I think you will be happier with what is possible in Mailman 3. In > mm3 we have a working LMTP server, those it's based on asyncore and > its scalability is questionable. Although I have not yet done this, I > plan to tie the rule chain checker into LMTP so that if your MTA > supports LMTP

Re: [Mailman-Developers] before next release: disable backscatter in default installation

--On 25 March 2008 08:13:49 +0100 Lars Magne Ingebrigtsen <[EMAIL PROTECTED]> wrote: > > These days, secondary MXs usually do SMTP callouts to verify whether > email addresses are valid on the primary mail server. It does, however, > make the concept of a "secondary MX" less useful than it use

Re: [Mailman-Developers] before next release: disable backscatter in default installation

--On 24 March 2008 18:45:22 -0700 Mark Sapiro <[EMAIL PROTECTED]> wrote: > Jo Rhett wrote: >> >> If you have an MX that queues mail for someone else and isn't >> configured to properly deal with DSNs, then yes, you are stuck in the >> 20th century. > > > I still don't get what you mean by "prope

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett wrote: > On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote: > > I still don't get what you mean by "properly deal with DSNs". Are you > > saying that an MTA should never return a DSN? It should either reject > > the mail during the incoming SMTP transaction or forever hold its > > piece? > >

Re: [Mailman-Developers] before next release: disable backscatter in default installation

"Stephen J. Turnbull" <[EMAIL PROTECTED]> writes: > Unfortunately this attitude does seem to be catching hold. I was told > recently that a secondary MX would have to stop functioning as such > because his ISP insists that he have an up to the second list of all > valid mailboxes at my site; he's

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 25, 2008, at 3:20 PM, Barry Warsaw wrote: > I think you will be happier with what is possible in Mailman 3. In > mm3 we have a working LMTP server, those it's based on asyncore and > its scalability is questionable. Although I have not yet done > this, I plan to tie the rule chain ch

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 25, 2008, at 1:58 PM, Barry Warsaw wrote: > Now that there's documentation, I don't think you need to be that > severe. The documentation is insufficient as it stands. The mailing list headers would contain addresses which no longer exist. But yes, an "official documentation configura

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 24, 2008, at 11:35 PM, Stephen J. Turnbull wrote: > Unfortunately this attitude does seem to be catching hold. I was told > > So much for the whole concept of a store-and-forward mail system. :-( You are stuck in the last century, aren't you? No insult intended, honestly. Nobody

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 24, 2008, at 10:49 PM, Stephen J. Turnbull wrote: >> What? I'm sorry, but Mailman has been blamed for backscatter for >> like 3 years going now. > > If you say so. I first heard of the issue within the last year, and > that in the context of bouncing back whole messages. And it wasn't > f

Re: [Mailman-Developers] before next release: disable backscatter in default installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 24, 2008, at 10:03 PM, Jo Rhett wrote: > On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote: >> I still don't get what you mean by "properly deal with DSNs". Are you >> saying that an MTA should never return a DSN? It should either reject >> the mai

Re: [Mailman-Developers] before next release: disable backscatter in default installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 24, 2008, at 9:37 PM, Jo Rhett wrote: > On Mar 4, 2008, at 6:00 PM, Stephen J. Turnbull wrote: >> In any case, it's hard to sympathize with your claim of urgency. >> Mark's intention to release 2.1.10 has been known for many months. >> This prop

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett writes: > On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote: > > I still don't get what you mean by "properly deal with DSNs". Are you > > saying that an MTA should never return a DSN? It should either reject > > the mail during the incoming SMTP transaction or forever hold its > > piec

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett writes: > On Mar 4, 2008, at 6:00 PM, Stephen J. Turnbull wrote: > > In any case, it's hard to sympathize with your claim of urgency. > > Mark's intention to release 2.1.10 has been known for many months. > > This proposal comes on the eve of release. Code changes to implement > > i

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 24, 2008, at 6:45 PM, Mark Sapiro wrote: > I still don't get what you mean by "properly deal with DSNs". Are you > saying that an MTA should never return a DSN? It should either reject > the mail during the incoming SMTP transaction or forever hold its > piece? Yes. And not just me, but a

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett wrote: > >If you have an MX that queues mail for someone else and isn't >configured to properly deal with DSNs, then yes, you are stuck in the >20th century. I still don't get what you mean by "properly deal with DSNs". Are you saying that an MTA should never return a DSN? It should

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 4, 2008, at 6:00 PM, Stephen J. Turnbull wrote: > In any case, it's hard to sympathize with your claim of urgency. > Mark's intention to release 2.1.10 has been known for many months. > This proposal comes on the eve of release. Code changes to implement > it can, and should, wait for the n

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 17, 2008, at 7:28 PM, Mark Sapiro wrote: > A text change breaks 35 existing Mailman translations, and breaks them Sorry, yes you are right I forgot about translations. > I'm not talking about DSNs to non-accepted mail. I'm talking about a > message that is accepted by an MX, queued and lat

Re: [Mailman-Developers] before next release: disable backscatter in default installation

> --On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett > <[EMAIL PROTECTED]> wrote: > >> 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by >> default. Nearly everyone uses web based signup. On Mar 12, 2008, at 9:58 AM, Kenneth Porter wrote: > Here's the list of valid actions fr

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Mar 6, 2008, at 11:13 AM, Kenneth Porter wrote: > On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett > <[EMAIL PROTECTED]> wrote: > >> 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by >> default. Nearly everyone uses web based signup. >> >> 2. Discard or hold messages from n

[Mailman-Developers] before next release: disable backscatter in default installation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for not replying to this sooner, but I was busy and then it got buried. Jo Rhett wrote: | On Mar 4, 2008, at 3:28 PM, Mark Sapiro wrote: | |> Even if we wanted to do this, it is non-trivial. All confirmation |> messages and their templates and

Re: [Mailman-Developers] before next release: disable backscatter in default installation

--On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett <[EMAIL PROTECTED]> wrote: > 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by > default. Nearly everyone uses web based signup. Here's the list of valid actions from mm-handler: @ValidActions = qw(admin bounces confirm jo

Re: [Mailman-Developers] before next release: disable backscatter in default installation

> # Prevent backscatter for unapproved actions? > $BounceUnapproved = 0; > > # Prevent backscatter for undefined lists? > $BounceNonlist = 1; > > The comment seems to be logically backwards from the variable name. Should > it really read "allow", not "prevent"? Does 0 or 1 mean backscatter? Goo

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Thursday, March 06, 2008 4:02 PM -0600 David Champion <[EMAIL PROTECTED]> wrote: > Here is an update to mm-handler which might address this adequately. I > no longer use mm-handler myself (despite having written it), so I can't > test this short of installing a new Mailman instance. Can some

Re: [Mailman-Developers] before next release: disable backscatter in default installation

> > 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by > > default. Nearly everyone uses web based signup. > > How, exactly, does one do these? In particular, how do you remove the > aliases when using mm-handler to process mail from sendmail? (I'd be happy > to start the wiki

Re: [Mailman-Developers] before next release: disable backscatter in default installation

On Tuesday, March 04, 2008 12:30 PM -0800 Jo Rhett <[EMAIL PROTECTED]> wrote: > 1. Don't create backscatter aliases for subscribe/unsubscribe/etc by > default. Nearly everyone uses web based signup. > > 2. Discard or hold messages from non-subscribers by default. How, exactly, does one do these

Re: [Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett writes: > This is not substantive, it's trivial. *sigh* From the point of view of the release manager, there are no trivial code changes to a release candidate. You are handicapping your advocacy by failing to acknowledge the potential for trouble. Adding a README.backscatter would b

Re: [Mailman-Developers] before next release: disable backscatter in default installation

> Jo Rhett writes: >> Hi. There's a fairly simple problem here that needs to be >> addressed. And it's mostly a documentation/install problem. I'm >> hoping we can get this resolved before the next release. On Mar 4, 2008, at 2:44 PM, Stephen J. Turnbull wrote: > > Which "next release"? 2.1.10

[Mailman-Developers] before next release: disable backscatter in default installation

Jo Rhett writes: > Hi. There's a fairly simple problem here that needs to be > addressed. And it's mostly a documentation/install problem. I'm > hoping we can get this resolved before the next release. Which "next release"? 2.1.10, which is deep into beta at this point? I would strongl

[Mailman-Developers] before next release: disable backscatter in default installation

Hi. There's a fairly simple problem here that needs to be addressed. And it's mostly a documentation/install problem. I'm hoping we can get this resolved before the next release. PROBLEM: Mailman comes out of the box ready to backscatter spam people. Yes, it's easy enough to fix. But beca