[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
> From: James Fidell <james@xxxxxxxxxxxx> > Organization: CloudNine Consultants Ltd., Pitsford Hill Farm, Pitsford Hill, > Wiveliscombe, Somerset TA4 2RR. Reg. No. 3317659 > Reply-To: <list@xxxxxxxxxxxxx> > Date: Thu, 25 Jun 2009 18:11:12 +0100 > To: <list@xxxxxxxxxxxxx> > Subject: Re: [LUG] email > > Mick Vaites wrote: >> I'm gobsmacked that you would advocate an ISP dropping a customers email >> bounces but at the same time wouldn't advise a customer to do it themselves >> - or am I not reading you right ? > > I'm not advocating dropping email at all. A 4xx is not a drop, it's a > "please retry later" and as such is a perfectly valid response to a > deliverable message. > Covered off. >> Issuing a 4xx puts the responsibility back on the originator of the message >> to resend the message which may not happen for some time. Whereas the backup >> MX could have more friendly rules for it's customers on resending - and thus >> reducing the delay in getting the email to the person. > > It could, but it's a small could, and, unless the backup MX can be > authoritative about its mail delivery, the downside far exceeds the > benefits. > Yup but an ISP can never be authoritive of a customers mailboxes if the mailboxes are located on the customers mail server. >> I take your point about Spammers assuming they are the ones actually sending >> them mail directly to the MX's. My understanding however is that more and >> more spam gets sent via Bot's. Which uses a customers ISP's outbound smtp >> server. We're seeing more and more customers being hit this way. > > I'm less than convinced that as a provider of outbound relaying services > it's sensible to trust your users not to originate spam or messages from > random sender addresses either. Plenty of people spam-filter outbound > messages and rate-limit users (amongst other things) for precisely that > reason. > Unfortunately customers need to run their business we can only try to educate them. As for limiting etc if the messages don't get through first time - they send the batch again - and then complain that it didn't get through. It's as irritating as customers using a their webspace to run a bulk mailer but what can you do? > However, if the intended recipients of such spam messages reject them > outright at the receiving MX rather than silently dropping them on the > floor (or, to a certain extent, just generate a 4xx if they can't > guarantee delivery), then the mail provider is the one whose mail queues > fill up (and potentially who generates backscatter) and it becomes their > problem. That's the right place for the problem to be, because they're > the ones transmitting the spam for their spam-generating customer, and > they should bear the cost that entails. In an ideal world yes. > >> Reference your comments on secondary MX's -- since the advent of ADSL more >> and more customers are using us as backup MX's or Smart hosts. Principally >> because the RBL's are picking on the ADSL IP space more and more. > > I'm sure there are those who would argue that it's those netblocks > assigned to ADSL customers where the originator can't be definitively > identified that generally end up in the RBLs and that there isn't > usually a problem with well-maintained static assignments (where that > includes a responsive abuse-management function). I can't see that > there's a particularly compelling reason to allow users with dynamic > address assignments to deliver email directly, I have to admit. Agreed. > > James > > -- > The Mailing List for the Devon & Cornwall LUG > http://mailman.dclug.org.uk/listinfo/list > FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html