Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Mon, Sep 14, 2015 at 01:05:28PM -0400, Rich Kulawiec wrote: > That's part of it, sure. But having working RFC 2152 role addresses, RFC 2142, sorry for the typo. ---rsk ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Mon, Sep 14, 2015 at 01:05:28PM -0400, Rich Kulawiec wrote: > On Thu, Sep 10, 2015 at 08:47:25AM -0700, Michael Peddemors wrote: > > While you are absolutely right that network operators and email > > server operators should be the place that the majority of the work > > is done (at the source), (egress filtering, blocking DUL traffic to > > Port 25 et al), and simple monitoring and rate limiting. > > That's part of it, sure. But having working RFC 2152 role addresses, Probably meant RFC 2142? > paying attention to what shows up there, and *answering every single > one of those messages* is also part of the job. [..] Johann ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Thu, Sep 10, 2015 at 08:47:25AM -0700, Michael Peddemors wrote: > While you are absolutely right that network operators and email > server operators should be the place that the majority of the work > is done (at the source), (egress filtering, blocking DUL traffic to > Port 25 et al), and simple monitoring and rate limiting. That's part of it, sure. But having working RFC 2152 role addresses, paying attention to what shows up there, and *answering every single one of those messages* is also part of the job. Yes, I really do expect postmas...@gmail.com to work and I expect a personal, individual reply to every message sent there. This is NOT a difficult task and if Gmail can't handle it, they should shut down immediately. Same for ab...@aol.com, postmas...@yahoo.com, and so on. (I'm looking at you too, AWS. For all your boasting about how wonderful your cloud service is, you've done a horribly poor job of controlling abuse from it. Aren't you even a little embarrassed by your obvious and massive incompetence?) This is baseline operational practice 101. It's what you should learn in the first hour of the first day. It's also really smart: if the entire rest of the Internet is trying to tell you where you screwed up -- by allowing abuse/attacks to escape your operation -- then you should be (a) listening (b) investigating (c) apologizing (d) fixing. (And I don't want to hear any whining about scale. If you built something bigger than you're capable of running properly and plugged it into the Internet, that's your problem. Stop being so damn cheap, spend some money, hire a few hundred people, make it happen.) As I have said before, spam (like other forms of abuse) does not magically fall out of the sky. It comes from somewhere, and the keepers of those "somewheres" are personally/professionally responsible for it. Reducing it to zero should be their top priority. But -- in practice -- it's clearly not. And that is where the biggest, most fundamental problem lies. And all of these various standards -- good, bad, indifferent -- will have zero effect on that. They're just wallpaper covering up the problem. None of them actually address the core issue, which isn't technical: it's human. > But in the end, the final decision of what is spam and what isn't > lies with the recipient. No. It most certainly does not. If traffic is UBE, then it is spam. If it's not UBE, then it's not spam. Recipients' opinions are irrevelant and not only may be discarded, they *must* be discarded. The determination of whether or not traffic is spam must be based solely on the facts because doing otherwise is unworkable and unfair to all concerned. ---rsk ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
> On 10 Sep 2015, at 08:23, Brandon Long wrote: > > On Wed, Sep 9, 2015 at 5:32 PM, Robert Mueller wrote: > >> We don't recommend doing that: >> >> https://support.google.com/mail/answer/175365 >> >> If you are forwarding mail, you'll inevitably forward spam, and you don't >> want your reputation to take a hit on that. >> >> Or, damned if you do, damned if you don't. > > Ok, just to confirm, does this mean you don't recommend or recognise SRS > rewritten MAIL FROM addresses as special in any way? > > Does anyone understand SRS? I thought it was pretty much a dead end. > Seems to me that the reason Google recommend not rewriting the envelope sender is that your domain may get punished for forwarding spam. The solution, apparently, would be to use a different domain. And probably a different IP address, too. Of course that makes it more likely that your own email is delivered, but less likely that the forwarded email is delivered: since it won’t benefit from any positive reputation that your own email has. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
> On 10 Sep 2015, at 12:45, Robert Mueller wrote: > >> >> Ok, just to confirm, does this mean you don't recommend or recognise SRS >> rewritten MAIL FROM addresses as special in any way? >> >> Does anyone understand SRS? I thought it was pretty much a dead end. > > IMHO everything about SPF and SRS borders on somewhere between pointless and > craziness. Is there any evidence it's been useful in any way to help stop or > identify spam? The main benefit it to permit whitelisting of trusted domains. For example, I’d be quite happy to whitelist any *.ac.uk domain for email that (a) gets an SPF pass, and (b) has no attachments, and (c) some other stuff. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On 2015-09-10 06:58, John Levine wrote: SRS was mostly useful as an exercise to confirm that the world is not going to completely change how it works just because the FUSSP du jour can't describe the way it's been sending mail for 30 years. Personally, I'd rather have the bounces hit me rather than some random sender who won't recognize the destination address that actually failed. When a bounce hits one of my rewritten addresses, my systems know to flag it and (eventually) disable the forwarding. I don't actually use SRS, but rather, the BATV-like implementation which rewrites the MAIL FROM field to something trackable. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On 2015-09-10 04:45, Robert Mueller wrote: Is there any evidence it's been useful in any way to help stop or identify spam? No. But it's moderately good at helping identify when a message is from the sender it claims, and this is useful information. I love that I can give users a one click "Allow everything from this address/domain" without giving a free pass to forged messages. And without having to guess at every outbound MX a sender uses today, and without having to maintain that list tomorrow. SPF:PASS, valid DKIM, mail coming from the MX or a rDNS match all help identify whether a message is likely coming from an authorized sender, and if so, that can be useful information. Similarly, if I get spam from @cotapmail.com (again), and it has SPF:PASS or valid DKIM, I known I can safely block the whole domain (whether future mail validates or not) and not have to care about losing legitimate mail, whereas it's not fair to block a sender because a spammer is forging their domain. SPF's neutral, none, softfail and fail responses are mostly just noise. So is it useful? Yes. But does it stop spam? No. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Thu, Sep 10, 2015 at 1:42 PM, Gil Bahat wrote: > > > On Thu, Sep 10, 2015 at 11:29 PM, Brandon Long wrote: > >> >> >> On Thu, Sep 10, 2015 at 6:50 AM, John Levine wrote: >> >>> >Does anyone understand SRS? I thought it was pretty much a dead end. >>> >>> It dates from the magic bullet phase of SPF, so yeah. >>> >>> >The reason we rewrite is so that bounces come back to us so we can >>> >automatically disable forwarding if the account we're forwarding to goes >>> >away. >>> >>> Well, actually, you're doing SRS with different syntax. Local bounce >>> management is one of the few things it does successfully. The >>> original plan was that you'd forward the bounces back which >>> unsurprisingly turned out not to be a great idea. >>> >> >> Sure, I guess I view all of these as descendents from VERPS, but I guess >> that comes from spending so much time in the mailing list space. >> >> >>> >Which reminds me, I need to ping the spam folks again, that page is >>> still >>> >recommending putting SPAM in the subject, which breaks dkim, which is >>> the >>> >last thing you should do. I think we're going to support an X-Spam >>> header >>> >instead... except of course that's a violation of RFC 6648. Anyone >>> want to >>> >recommend a generic header name? >>> >>> Please use X-Spam-Status: which is what Spamassassin adds, and I think >>> several other filter packages. If you parse RFC 6648 carefully, >>> you'll see that while it tells you not to invent any new X- headers, >>> it says it's OK to keep using the ones that already exist. >>> >> >> Sure, that may make the most sense. We do usually expose the phishing >> status of the message as well, but I guess that can just be a different >> header for forwarding. >> > > It would be most appreciated if you'd populate it on ingress to begin with > and not just when forwarding. it's easier to ask a user which reported an > incident when a mail landed in spam to forward it, rather than ask them to > try to locate the spam reasoning bar in their UI (if it's present at all, > assuming they don't use an MUA, etc...). > many providers and anti-spam packages do that (cloudmark, cyren to name > two off the top of my head), I haven't seen any ill effects to it and the > support benefit is extremely handy. It would also allow third party MUAs to > parse and display this data. > > Are there any good reasons not do so? I am trying to think of the cons and > I can't come up with anything really good. > hmm. It might confuse some folks who don't normally look at the headers and are surprised because they marked it as not-spam, but that's probably not enough reason not to. Brandon ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Thu, Sep 10, 2015 at 11:29 PM, Brandon Long wrote: > > > On Thu, Sep 10, 2015 at 6:50 AM, John Levine wrote: > >> >Does anyone understand SRS? I thought it was pretty much a dead end. >> >> It dates from the magic bullet phase of SPF, so yeah. >> >> >The reason we rewrite is so that bounces come back to us so we can >> >automatically disable forwarding if the account we're forwarding to goes >> >away. >> >> Well, actually, you're doing SRS with different syntax. Local bounce >> management is one of the few things it does successfully. The >> original plan was that you'd forward the bounces back which >> unsurprisingly turned out not to be a great idea. >> > > Sure, I guess I view all of these as descendents from VERPS, but I guess > that comes from spending so much time in the mailing list space. > > >> >Which reminds me, I need to ping the spam folks again, that page is still >> >recommending putting SPAM in the subject, which breaks dkim, which is the >> >last thing you should do. I think we're going to support an X-Spam >> header >> >instead... except of course that's a violation of RFC 6648. Anyone want >> to >> >recommend a generic header name? >> >> Please use X-Spam-Status: which is what Spamassassin adds, and I think >> several other filter packages. If you parse RFC 6648 carefully, >> you'll see that while it tells you not to invent any new X- headers, >> it says it's OK to keep using the ones that already exist. >> > > Sure, that may make the most sense. We do usually expose the phishing > status of the message as well, but I guess that can just be a different > header for forwarding. > It would be most appreciated if you'd populate it on ingress to begin with and not just when forwarding. it's easier to ask a user which reported an incident when a mail landed in spam to forward it, rather than ask them to try to locate the spam reasoning bar in their UI (if it's present at all, assuming they don't use an MUA, etc...). many providers and anti-spam packages do that (cloudmark, cyren to name two off the top of my head), I haven't seen any ill effects to it and the support benefit is extremely handy. It would also allow third party MUAs to parse and display this data. Are there any good reasons not do so? I am trying to think of the cons and I can't come up with anything really good. Brandon > > ___ > mailop mailing list > mailop@mailop.org > http://chilli.nosignal.org/mailman/listinfo/mailop Regards, Gil Bahat, DevOps/Postmaster, Magisto Ltd. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On 15-09-10 05:13 AM, Rich Kulawiec wrote: Spam (and all other forms of abuse) is/are best stopped as close to the source as possible: every hop away from there makes the problem harder and pushes the error rate up. Thus the ideal place is*at* the source. This doesn't require SPF or SRS or DKIM or any of these other bits of technology. It requires competent, diligent, hard-working professionals who actually give a damn about making sure that their operation isn't an operational menace to the entire rest of the Internet. While you are absolutely right that network operators and email server operators should be the place that the majority of the work is done (at the source), (egress filtering, blocking DUL traffic to Port 25 et al), and simple monitoring and rate limiting. (Today's pet peeve, I am talking to all those VPS houses that let people sign up online, possibly with a stolen credit card or bitcoin, and have access to a big PIPE, get a block of IP(s) and then 'crush' the internet with spam, while the hosting operator acts 'surprised'.. you can tell what is happening on your network, don't put the onus on the rest of the internet to deal with it) But in the end, the final decision of what is spam and what isn't lies with the recipient.. "One man's spam, is another man's reading material" What bother me most is that many of 'these other bits' of technology, are work around's for simpler technologies. ESP's have to stop sending 'rewritten' forwarded email, which simply obfuscate the real sender.. bou...@esp.com doesn't allow the end user to make decisions.. not matter what the technical excuse.. * We want to receive bounces for our customers.. so we can remove bad addresses.. - Really? First, why do you have so many bad addresses? - For bounces? Haven't we already classed that as 'backscatter? - End user should be able to reject based on sender, don't hide that. (oh, if we send them all the same, hehehe, no-one can blacklist) but you also prevented the reciever from 'whitelisting' easily Okay, looks like I am going to start the day with a 'rant'.. Some ESP's at least some identity related to the domain, which is better than nothing.. But of course end users are used to putting '@nationbuilder.com' in the blacklist/whitelist, or even maybe '@constantcontact.com' but what ordinary citizen would think.. '@in.constantcontact.com'? What ever happened to clearly identifying the sender? Should an email server have to process thousands of messages, just so they can parse the headers and see if a 'forgable' From: address is the one they want? (Yes, there are specific cases of mailing lists that need strange sending addresses, but at least they have the domain portion right) Return-Path: If we clearly presented the senders's half of these 'other technologies' would not be needed. clean rDNS/PTR record, clean Return-Path, proper rWhois/SWIP would make things a lot simpler.. -- "Catch the Magic of Linux..." Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
>IMHO everything about SPF and SRS borders on somewhere between pointless >and craziness. Is there any evidence it's been useful in any way to help >stop or identify spam? A plain SPF '-all' to say this domain sends no mail at all works great. Other than that SPF has been somewhat useful for phishes of domains like paypal.com that send all their mail mechanically and don't have human users. (The humans at Paypal use another domain.) SRS was mostly useful as an exercise to confirm that the world is not going to completely change how it works just because the FUSSP du jour can't describe the way it's been sending mail for 30 years. R's, John ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
>Does anyone understand SRS? I thought it was pretty much a dead end. It dates from the magic bullet phase of SPF, so yeah. >The reason we rewrite is so that bounces come back to us so we can >automatically disable forwarding if the account we're forwarding to goes >away. Well, actually, you're doing SRS with different syntax. Local bounce management is one of the few things it does successfully. The original plan was that you'd forward the bounces back which unsurprisingly turned out not to be a great idea. >Which reminds me, I need to ping the spam folks again, that page is still >recommending putting SPAM in the subject, which breaks dkim, which is the >last thing you should do. I think we're going to support an X-Spam header >instead... except of course that's a violation of RFC 6648. Anyone want to >recommend a generic header name? Please use X-Spam-Status: which is what Spamassassin adds, and I think several other filter packages. If you parse RFC 6648 carefully, you'll see that while it tells you not to invent any new X- headers, it says it's OK to keep using the ones that already exist. R's, John ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
>> In general, it seems we're way past the point where we should have a more >> explicit system for forwarding. > Agree. Who wants to write one? :) On needs to think of what ‘forwarding’ means: - It could mean that someone wants to forward his/her email from localp...@example.com to a third party, e.g. Gmail. Two mailservers with different owners. - It could mean that the whole domain is forwarded to a mailserver which does the spamfiltering again (failing e.g. SPF; i.e. a case of bad spamfilter setup which happens a lot). Two mailservers with one owner. This may be a specific form of the first. In the third-party-case, the user wants emails from localp...@example.com to their Gmail. Without (more) spamfiltering (regarding the sender). There are two issues: How does example.com authenticate to Gmail that this mail is legitimate. The second issue is that Gmail now may have ‘unsafe’ content on their platform (because even if the source is legit, it ‘may’ be compromised*). Third: There is spam from legitimate companies who somehow abuse their legitimate channels (content-wise or opt-in-wise); Gmail needs to keep track of that as well (how do you do that with forwarding?). The first issue can be technically solved with e.g. public/private keys. One may even stretch it so not only forwarders can use it as a one-hop permission, but senders in general. One would need to think about the way to exchange keys (without bothering the recipient too much). It may solve large parts of opt-in issues. The second and third issue is not so simple. How do you solve (compromised) content issues from people with bad/uninformed intentions. My Eur 0.01, rant away. David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) *for large receiving parties on the internet, there are always compromised legitimate sources sending to them. Van: mailop [mailto:mailop-boun...@mailop.org] Namens Robert Mueller Verzonden: Thursday, September 10, 2015 1:46 PM Aan: Brandon Long CC: mailop Onderwerp: Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk Ok, just to confirm, does this mean you don't recommend or recognise SRS rewritten MAIL FROM addresses as special in any way? Does anyone understand SRS? I thought it was pretty much a dead end. IMHO everything about SPF and SRS borders on somewhere between pointless and craziness. Is there any evidence it's been useful in any way to help stop or identify spam? Which reminds me, I need to ping the spam folks again, that page is still recommending putting SPAM in the subject, which breaks dkim, which is the last thing you should do. I think we're going to support an X-Spam header instead... except of course that's a violation of RFC 6648. Anyone want to recommend a generic header name? Maybe go with something that's already commonly added? https://wiki.apache.org/spamassassin/X_Spam_Status At least the Yes/No bit on the front? In general, it seems we're way past the point where we should have a more explicit system for forwarding. Agree. Who wants to write one? :) Rob Mueller r...@fastmail.fm<mailto:r...@fastmail.fm> ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
> On 10-Sep-2015, at 5:15 PM, Robert Mueller wrote: > > IMHO everything about SPF and SRS borders on somewhere between pointless and > craziness. Thank you. —srs___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Thu, Sep 10, 2015 at 09:45:40PM +1000, Robert Mueller wrote: > IMHO everything about SPF and SRS borders on somewhere between pointless > and craziness. Is there any evidence it's been useful in any way to help > stop or identify spam? No. SPF was announced by an ignorant newbie with this grandiose claim: "Spam as a technical problem is solved by SPF." That was enough for me to conclude, on inspection, that it was utterly worthless. [1] Nobody with any significant anti-spam expertise thinks that any one measure would suffice. For those holding out some hope, their first clue should have been that the earliest and most prolific adopters of SPF were spammers. Spam (and all other forms of abuse) is/are best stopped as close to the source as possible: every hop away from there makes the problem harder and pushes the error rate up. Thus the ideal place is *at* the source. This doesn't require SPF or SRS or DKIM or any of these other bits of technology. It requires competent, diligent, hard-working professionals who actually give a damn about making sure that their operation isn't an operational menace to the entire rest of the Internet. And those are in precious short supply these days -- even at places that could afford to hire them by the dozens. (I'm looking at you, Google, Microsoft, Yahoo and AOL.) ---rsk [1] This should go down in history along with "I have here in my briefcase..." ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
>> Ok, just to confirm, does this mean you don't recommend or recognise >> SRS rewritten MAIL FROM addresses as special in any way? > > Does anyone understand SRS? I thought it was pretty much a dead end. IMHO everything about SPF and SRS borders on somewhere between pointless and craziness. Is there any evidence it's been useful in any way to help stop or identify spam? > Which reminds me, I need to ping the spam folks again, that page is > still recommending putting SPAM in the subject, which breaks dkim, > which is the last thing you should do. I think we're going to support > an X-Spam header instead... except of course that's a violation of RFC > 6648. Anyone want to recommend a generic header name? Maybe go with something that's already commonly added? https://wiki.apache.org/spamassassin/X_Spam_Status At least the Yes/No bit on the front? > In general, it seems we're way past the point where we should have a > more explicit system for forwarding. Agree. Who wants to write one? :) Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
> Segregating it onto its own IP which is clearly named - like > forwarder.fastmail.fm - would be a very good idea. FYI, we already do this. I think Bron got a bit sidetracked into this, because the delays were mostly our out "outgoing mail" IPs, not on our "forwarded mail" IPs. -- Rob Mueller r...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
> On 10-Sep-2015, at 3:22 AM, Bron Gondwana wrote: > > We have SPF records. The problem is that our customers can set up > sieve rules to forward any mail at all, so we can't guarantee that SPF > will always pass. If you aren’t treating forwarded mail like it has leprosy, you really ought to. Segregating it onto its own IP which is clearly named - like forwarder.fastmail.fm - would be a very good idea. Else, the blocking you face will most likely be because of huge amounts of spam that slips past your inbound filters and leaks out of your outbounds due to the forwarding.DKIM / DMARC / SPF your customers as much as you will, having your outbound traffic mixed with bot, snowshoe, nigerian and random other spam that leaks past your inbounds is essentially hanging a giant “block me!!” sign on your outbound MTAs. —srs ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
> We don't recommend doing that: > > https://support.google.com/mail/answer/175365 > > If you are forwarding mail, you'll inevitably forward spam, and you > don't want your reputation to take a hit on that. > > Or, damned if you do, damned if you don't. Ok, just to confirm, does this mean you don't recommend or recognise SRS rewritten MAIL FROM addresses as special in any way? In that case, why does gmail do some form of SRS style rewriting when you forward *from* gmail to somewhere else? Return-Path: gmailusername+caf_=targetusername=targetdomain@gmail.com[1] That seems pretty inconsistent. Don't rewrite when forwarding to us, but we'll rewrite when forwarding to others? Rob Mueller r...@fastmail.fm Links: 1. mailto:fastmail...@gmail.com ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
Best is to ensure in a clean forward that the DKIM signature does not get broken. But yes forwarded emails should go via anti-spam filters too. On Wed, Sep 9, 2015 at 4:34 PM, Brandon Long wrote: > We don't recommend doing that: > > https://support.google.com/mail/answer/175365 > > If you are forwarding mail, you'll inevitably forward spam, and you don't > want your reputation to take a hit on that. > > Or, damned if you do, damned if you don't. > > Brandon > > On Wed, Sep 9, 2015 at 4:24 PM, Dave Warren wrote: > >> On 2015-09-09 14:52, Bron Gondwana wrote: >> >>> On Thu, Sep 10, 2015, at 05:23, Cedric Knight wrote: >>> >Plus I got a kind response from stevepostmas...@btinternet.com, >suggesting any SPF record (eg softfail or neutral) would reduce number >of SPF fails, or delays. >>> We have SPF records. The problem is that our customers can set up >>> sieve rules to forward any mail at all, so we can't guarantee that SPF >>> will always pass. >>> >> >> Not to beat the drum too hard, but SRS? Or at least rewrite in some >> fashion such that the mail you emit passes SPF. >> >> -- >> Dave Warren >> http://www.hireahit.com/ >> http://ca.linkedin.com/in/davejwarren >> >> >> >> >> ___ >> mailop mailing list >> mailop@mailop.org >> http://chilli.nosignal.org/mailman/listinfo/mailop >> > > > ___ > mailop mailing list > mailop@mailop.org > http://chilli.nosignal.org/mailman/listinfo/mailop > > ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On 2015-09-09 14:52, Bron Gondwana wrote: On Thu, Sep 10, 2015, at 05:23, Cedric Knight wrote: >Plus I got a kind response from stevepostmas...@btinternet.com, >suggesting any SPF record (eg softfail or neutral) would reduce number >of SPF fails, or delays. We have SPF records. The problem is that our customers can set up sieve rules to forward any mail at all, so we can't guarantee that SPF will always pass. Not to beat the drum too hard, but SRS? Or at least rewrite in some fashion such that the mail you emit passes SPF. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
On Thu, Sep 10, 2015, at 05:23, Cedric Knight wrote: > Plus I got a kind response from Steve postmas...@btinternet.com, > suggesting any SPF record (eg softfail or neutral) would reduce number > of SPF fails, or delays. We have SPF records. The problem is that our customers can set up sieve rules to forward any mail at all, so we can't guarantee that SPF will always pass. > So brownie points from me for professionalism, responsiveness and a > consistent answer. > > However, I'm less convinced that apparently random greylisting based on > SPF results is a good substitute for general IP reputations and content > scanning, as it can build up delivery delays as you mention. A huge > amount of spam passes SPF, while a huge amount of ham fails SPF. And we > don't want to add SPF on behalf of client organisations who may for > example use some ESP we don't know about. This too. Even for our own hundred or so domains, we've had customers on them for 15+ years, and some of them are bound to have an ESP sending things on their behalf. We can't hard-fail domains by default. > Plus the policy isn't publicly documented or very clear: converting SPF > none results into passes *doesn't* reduce fails. There will be SPF > fails from this IP address because it receives a lot of mail to users' > mailboxes and mail that they choose to forward on to an address at say > @btinternet.com, and forwarding generally breaks SPF. > > They may just need to take other factors into account when > greylisting/throttling. Anyway, I'm still seeing some 421s with > 1.5.6.1 and 1.5.6.2 (and a couple of 1.2.6.1), but not in the same > volume as before. The good news is, our mail appears to have cleared over night, one way or the other... Ahh, we switched outbound IPs for an unrelated reason. And there's still some of this: status=deferred (host mx.bt.lon5.cpcloud.co.uk[65.20.0.49] said: 421 Too many messages (1.5.6.1) from 66.111.4.25 (in reply to MAIL FROM command)) > https://community.bt.com/t5/Email/BT-email-accounts-rejecting-emails-we-send-on-behalf-of-our/m-p/1531608#M37145 > > Looks like it's been ongoing for months. *sigh* > > Since BT moved contract from Yahoo, in fact. I'm not sure what we can say to our customers other than "tell your contacts at BT Internet to move to someone who isn't so crap at receiving email". Given how often this has been reported, it looks like Openwave are stubbornly digging their heels in over this SPF blocking policy. > At the moment, problem 3) appears to be resolved. As for problem 2): > > On Mon, 07 Sep 2015 22:22:26 +1000 Bron Gondwana wrote: > > > > We're getting connection dropped after RCPT TO for customers trying > > to email to BTInternet. > > > > (delivery temporarily suspended: lost connection with > mx.bt.lon5.cpcloud.co.uk[65.20.0.49] while sending RCPT TO) > > I *didn't* see this on Monday. However I have seen periods of timeouts > on 27 August, although some messages were getting accepted at the same > time. So still not sure if it is a policy disconnect against RFCs or > capacity problem. I've seen tons of it over the past few days. Sounds like probably policy. ... I guess, in theory, it would be possible to scan outbound email to see if it would trigger an SPF fail at the receiving end, and if so rewrite the envelope or something. Kind of sucky workaround, but anything is better than having customer email bounce back hours or days later. That stuff can really mess up people's lives if it was a job application or scheduling something important. And the worst thing is the leakage - the affected customers aren't necessarily the ones who "caused" the problem in the first place :( Bron. -- Bron Gondwana br...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
I have seen weird emails coming from that IP: 65.20.0.49 Anyone has a contact there? On Fri, Jul 24, 2015 at 2:22 PM, Cedric Knight wrote: > Hi > > Is anyone else seeing problems delivering to recipients > @btinternet.com, @btopenworld.com and @talk21.com ? We've been seeing > the following to some extent since BT moved its email outsourcing from > Yahoo to Critical Path, but it seems to be getting worse if anything. > > All these destinations are routed via a IP address, 65.20.0.49 > [mx.bt.lon5.cpcloud.co.uk]. This sometimes accepts mail, but often > defers with a fairly random split between: > > 1) "421 Too many messages (1.5.6.1)" (after MAIL FROM) > 2) server dropping connection (while sending RCPT TO) > 3) "451 System policy engine error" (after end of DATA section) > 4) 250 acceptance > > 1) makes it sound like rate-limiting based on sender domain, but I > wonder if 1) and 3) mean the MX is simply overloaded or having > problems connecting to a back-end. A search for the response gives a > lot of people having similar problems, but no solution: > > https://community.bt.com/t5/Email/BT-Email-bounce-backs/td-p/1459015/page/11 > > Greylisting can happen after a RCPT TO has been sent, but should give > a 4xx response, not drop the connection (which violates RFC 5321 > section 3.8), and there seems to be no pattern to the length of time a > message can spend in our queue, many waiting all day. > > Ours is mostly individual user email, with some non-marketing email lists. > > If anyone from BT or Critical Path/Openwave is able to contact me > off-list, please do. > > -- > All best wishes, > > Cedric Knight > GreenNet > > GreenNet supports and promotes groups and individuals working for > peace, human rights and the environment through the use of > information and communication technologies. > > GreenNet, Development House, 56-64 Leonard Street, London EC2A 4LT > Tel: UK 020 7065 0942 (Intl +44) 20 7065 0935 Fax: 020 7253 2658 > Registered in England No. 02070438 VAT Reg GB 473 0262 65 > > > ___ > mailop mailing list > mailop@mailop.org > http://chilli.nosignal.org/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
Summary from 25 July: three causes of deferral sending to mx.bt.lon5.cpcloud.co.uk (btopenworld.com etc) 1) "421 Too many messages (1.5.6.1)" (after MAIL FROM) 2) server dropping connection (while sending RCPT TO) 3) "451 System policy engine error" (after end of DATA section) On Wed, 09 Sep 2015 20:58:21 +1000, Bron Gondwana wrote: > Did you ever hear back from them? I've had a > little bit of response, but I still have a queue full of emails which > aren't moving. It kinda sucks for my customers to have their emails > hanging for days. I spoke to OpenWave support (+800 22288800), who decoded 1.5.6.1 as too many non-SPF-authenticated (?) connection attempts, and referred me to fairly generic advice at http://bt.custhelp.com/app/answers/detail/a_id/47055/~/bt-mail---best-practices-for-postmasters-and-senders-of-bulk-mail Plus I got a kind response from Steve postmas...@btinternet.com, suggesting any SPF record (eg softfail or neutral) would reduce number of SPF fails, or delays. So brownie points from me for professionalism, responsiveness and a consistent answer. However, I'm less convinced that apparently random greylisting based on SPF results is a good substitute for general IP reputations and content scanning, as it can build up delivery delays as you mention. A huge amount of spam passes SPF, while a huge amount of ham fails SPF. And we don't want to add SPF on behalf of client organisations who may for example use some ESP we don't know about. Plus the policy isn't publicly documented or very clear: converting SPF none results into passes *doesn't* reduce fails. There will be SPF fails from this IP address because it receives a lot of mail to users' mailboxes and mail that they choose to forward on to an address at say @btinternet.com, and forwarding generally breaks SPF. They may just need to take other factors into account when greylisting/throttling. Anyway, I'm still seeing some 421s with 1.5.6.1 and 1.5.6.2 (and a couple of 1.2.6.1), but not in the same volume as before. > https://community.bt.com/t5/Email/BT-email-accounts-rejecting-emails-we-send-on-behalf-of-our/m-p/1531608#M37145 > Looks like it's been ongoing for months. *sigh* Since BT moved contract from Yahoo, in fact. At the moment, problem 3) appears to be resolved. As for problem 2): On Mon, 07 Sep 2015 22:22:26 +1000 Bron Gondwana wrote: > > We're getting connection dropped after RCPT TO for customers trying > to email to BTInternet. > > (delivery temporarily suspended: lost connection with mx.bt.lon5.cpcloud.co.uk[65.20.0.49] while sending RCPT TO) I *didn't* see this on Monday. However I have seen periods of timeouts on 27 August, although some messages were getting accepted at the same time. So still not sure if it is a policy disconnect against RFCs or capacity problem. CK ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk
Did you ever hear back from them? I've had a little bit of response, but I still have a queue full of emails which aren't moving. It kinda sucks for my customers to have their emails hanging for days. https://community.bt.com/t5/Email/BT-email-accounts-rejecting-emails-we-send-on-behalf-of-our/m-p/1531608#M37145 Looks like it's been ongoing for months. *sigh* Bron. On Sat, Jul 25, 2015, at 07:22, Cedric Knight wrote: > Hi > > Is anyone else seeing problems delivering to recipients > @btinternet.com, @btopenworld.com and @talk21.com ? We've been seeing > the following to some extent since BT moved its email outsourcing from > Yahoo to Critical Path, but it seems to be getting worse if anything. > > All these destinations are routed via a IP address, 65.20.0.49 > [mx.bt.lon5.cpcloud.co.uk]. This sometimes accepts mail, but often > defers with a fairly random split between: > > 1) "421 Too many messages (1.5.6.1)" (after MAIL FROM) > 2) server dropping connection (while sending RCPT TO) > 3) "451 System policy engine error" (after end of DATA section) > 4) 250 acceptance > > 1) makes it sound like rate-limiting based on sender domain, but I > wonder if 1) and 3) mean the MX is simply overloaded or having > problems connecting to a back-end. A search for the response gives a > lot of people having similar problems, but no solution: > https://community.bt.com/t5/Email/BT-Email-bounce-backs/td-p/1459015/page/11 > > Greylisting can happen after a RCPT TO has been sent, but should give > a 4xx response, not drop the connection (which violates RFC 5321 > section 3.8), and there seems to be no pattern to the length of time a > message can spend in our queue, many waiting all day. > > Ours is mostly individual user email, with some non-marketing email lists. > > If anyone from BT or Critical Path/Openwave is able to contact me > off-list, please do. > > -- > All best wishes, > > Cedric Knight > GreenNet > > GreenNet supports and promotes groups and individuals working for > peace, human rights and the environment through the use of > information and communication technologies. > > GreenNet, Development House, 56-64 Leonard Street, London EC2A 4LT > Tel: UK 020 7065 0942 (Intl +44) 20 7065 0935 Fax: 020 7253 2658 > Registered in England No. 02070438 VAT Reg GB 473 0262 65 > > > ___ > mailop mailing list > mailop@mailop.org > http://chilli.nosignal.org/mailman/listinfo/mailop -- Bron Gondwana br...@fastmail.fm ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
