Re: [mailop] mailop + DMARC + mailman = mung_from
> On 22 Feb 2016, at 09:14, Renaud Allard via mailop <mailop@mailop.org> wrote: > > Hi, > > I am not sure it does the trick, … ... > In the headers, I have: > Return-path: <mailop-boun...@mailop.org> > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mailplus2015-12; > d=mailplus.nl; > From: David Hofstee <da...@mailplus.nl> > > So it seems the From: header has not been changed. That’s because the domain doesn’t publish dmarc records. The header is only munged for domains that do publish dmarc records. In this thread, the email from Franck Martin has this header: From: Franck Martin via mailop <mailop@mailop.org> And yours has this From header: From: Renaud Allard via mailop <mailop@mailop.org> -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] I have developed a new method of blocking spam that's a game changer
He’s right, in April 2007 he got a patent on SPF, for which the RFC was published exactly 12 months earlier. His claims include "1. Domain validation comprising methods and apparatus for checking whether another machine is allowed to send emails for the specified sender, 2. Domain validation as described in Claim 1 whereby Mail Sender (MS) records may be added to the domain name sever configuration to denote machines that can send email for a domain," 3. some nonsense with CNAMEs! Except that: after validation, claim 1 was restricted to client machines, not MTAs. That renders the patent useless, since clients might be anywhere. If there is some restriction, there’s no reason to publish it. > On 18 Jan 2016, at 21:19, Michelle Sullivan <miche...@sorbs.net> wrote: > > Jay Hennigan wrote: >> On 1/14/16 7:43 AM, Jay R. Ashworth wrote: >>> I'm sorry; I didn't get to read your message. It was blocked: >>> >>> %EXCLAMATION-MARK-IN-BODY-ON-TECHNICAL-LIST: 4 >>> >>> (Obviously I need to upgrade, since you only actually used one, but >>> maybe >>> my filter can extract them from the tone of prose. ;-) >> >> It could be a spacer or comment in a Cisco config, those are fairly >> common on technical lists. >> >> As for me, I'm making popcorn while eagerly awaiting the latest, >> greatest patent-pending, FUSSP. > > You're not the only one... and interestingly I got this earlier... > > > > > To: "Michelle Sullivan [Webform]" <miche...@sorbs.net> > From: dave.w...@ntlworld.com > Subject: [Webform] How to cure 90+% of fake emails > Date: Mon, 18 Jan 2016 05:14:21 -0800 (PST) > > Michelle, > > I invented Domain Validation back in 2007. It works by introducing MS records > in DNS, which act as the reverse of MX records. > > That is, the sending machine looks up MX records of the recipient's domain > and connects to a machine, and the receiving machine looks up the MS records > of the sender's domain. > > It's that simple and can be bolted into existing infrastructure. You can read > the whole patent at www.ipo.gov.uk reference GB2449653. > > Regards > Dave Wain > > ==== > > > > -- > Michelle Sullivan > http://www.mhix.org/ > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] I have developed a new method of blocking spam that's a game changer
> On 14 Jan 2016, at 15:43, Jay R. Ashworth <j...@baylink.com> wrote: > > I'm sorry; I didn't get to read your message. Me too. It wasn’t blocked, it was just displayed in a tiny font. Except the SIG. Weird. > It was blocked: > > %EXCLAMATION-MARK-IN-BODY-ON-TECHNICAL-LIST: 4 > > (Obviously I need to upgrade, since you only actually used one, but maybe > my filter can extract them from the tone of prose. ;-) > > Cheers, > -- jra > > - Original Message - >> From: "Marc Perkel" <supp...@junkemailfilter.com> >> To: mailop@mailop.org >> Sent: Wednesday, January 13, 2016 11:50:28 PM >> Subject: [mailop] I have developed a new method of blocking spam that's a >> game changer > >> OK - this might sound a little unbelievable but I'm not making this up. >> I want to introduce this because I'm hoping to release this soon and I >> want to create some buzz and anticipation. I'm not going to talk about >> the details yet but I hope to soon. >> >> I just filed a provisional method patent on the method and tomorrow I'm >> going to be talking to some investor types about it. I'm also working on >> improving the methods I'm using, but this new trick is so accurate that >> 1 month ago if someone asked me if this level of accuracy was possible, >> I would have said - no way! >> >> I'm calling it the Evolution Filter. The name is somewhat of a clue to >> how it works. >> >> I'm seeing levels of accuracy getting really close to 100%. And it's >> especially good at actively detecting good email so false positives are >> almost not existent. >> >> I've been filtering spam now for 15 years and been on this list for >> about that long and I'm not the kind of guy to just make this stuff up. >> >> My intent right now is to just get enough IP protection so I can get a >> license fee from the big corps. I plane on giving it away free to the >> little guys. So that if you have less that 10,000 email accounts it's >> free. Hoping to get like 1 cent per email account per year from the big >> guys. >> >> Although this idea is very unique, it's actually rather simple to >> implement. I'm using Redis and since SA is also using redis it should be >> trivial to add it to SA. My programming skills are good but not great. >> So the developers here should be able to do a significantly better job >> than me. It only took me an afternoon to implement the concept and it >> was already impressive with just 3 hours of learning. >> >> This is not Bayesian or remotely similar to Bayesian. It does use a DB >> like Bayesian does and there is learning involved. But it's probably >> 100x better at detecting spam and 1000x better at detecting good email. >> And yes - it can actively detect good email. >> >> My plan is that this technique is going to be so good that everyone is >> going to immediately implement it. And because of that the big boys will >> license it from me. >> >> The accuracy is so good that it could put many spammers out of business. >> It can recognize spam more accurately that I can by hand looking at >> someone elses email. >> >> If someone on this list wants to verify that I'm not just smoking the >> wrong kind of cigarettes I'm willing to let people test it on the >> condition that you report back here and tell everyone what your >> experience is. >> >> If anyone has some feedback about how I can make this available to >> everyone and make a little something in licensing fees I'm definitely >> listening. I do want to release this to you all soon because you'll >> probably make it better than I have. >> >> I have a little more info on Dvorak's blog. >> >> http://www.dvorak.org/blog/2016/01/12/i-invented-a-new-way-to-filter-spam-thinking-about-a-patent/ >> >> >> >> -- >> Marc Perkel - Sales/Support >> supp...@junkemailfilter.com >> http://www.junkemailfilter.com >> Junk Email Filter dot com >> 415-992-3400 >> >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > -- > Jay R. Ashworth Baylink > j...@baylink.com > Designer The Things I Think RFC 2100 > Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII > St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274 > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
at 11:35 PM, Brandon Long <bl...@google.com> wrote: > We have automated systems, especially for Google groups, which are basically > doing the same thing, and it's a pain. > > I agree that the SMTP status code is mostly useless from this prospective, > and the extended ones aren't much better. > > It might be nice if there was a concept of whether a failure is message > specific, sender specific, etc... But anything like that would be gamed both > for antispam and for spammers. > > Still, may be worth a thought experiment, a replacement for the extended > status codes or even a bcp about how they should be used. > > On Dec 16, 2015 6:03 PM, "Karen Balle" <kba...@rcn.com> wrote: > Since there's been a lot of drift on this topic and I'm not talking about > IPv6, DNSSEC, or delivery to Gmail > > For NDRs and DSNs to be truly useful to an ESP, we tend to break them down > into more buckets than two. > > Hard bounce/invalid (do not retry, generally a 5xx) > Soft bounce (temporary and related to a specific email address, generally a > 4xx, try again later during the current send, Yahoo uses 4xx where we would > expect a 5xx such as with some of the traffic shaping deferrals) > Technical (DNS failures and the like, try again later, generally 5xx but > depends on the reason) > Spam or block (stop for this send, try this recipient on future sends, mix of > 5xx and 4xx) > Unknown (parser doesn't have an appropriate string, manual review and update > of systems required) > > The primary challenge from a technical perspective is making sure that any > changes in friendly language in an NDR or DSN is updated on the bounce > parser. We do tend to MOSTLY ignore 5xx and 4xx, but that is more a function > of how those are used by mailbox providers. The desired end result is that > we send all email in a manner that is acceptable to each mailbox provider > based on their (technical and personal) feedback and desired rate limits. > Extended codes are useful, when you know how a provider applies them, but > again, there is such variation in the how codes are applied and when that > it's all but impossible for someone not steeped in the intricacies of RFCs to > interpret them properly. > > Not all customers have access to people who spend a lot of time going over > bounces and making them actionable. A lot of our job as an ESP is taking the > technical and making it understandable to someone who doesn't have the > training and background on RFCs and "proper" technical jargon. I've spent > the last 18 years or so going over NDRs and DSNs and some still throw me. > Filters are also increasingly more complex and we see the same bounce used > for multiple purposes, so cross-referencing which bounces happen where is > becoming more important to understanding the root issue for a customer. > > > > Cheers, > Karen > > On Fri, Dec 11, 2015 at 9:06 AM, Ian Eiloart <i...@sussex.ac.uk> wrote: > I wonder why they don’t use the terminology from the RFCs: "reject", "defer", > "non-delivery notification", "delay notification"? > > As it is, when you say "Hardbounce", I don’t know whether you’re referring to > an SMTP 5yz reply (a rejection) by the receiving MTA or an rfc 3461 "failed" > DSN sent to the sender to alert them to the problem. > > Similarly, I don’t know whether "softbounces" means an rfc5321 temporary > failure reply , or an rfc 3461 "delayed" DSN. Neither of which mean quite > what you said, since the intention is that the sending MTA will retry for a > period. The sending MTA can’t use other means. If the original sender tries > again, then the recipient will get duplicate messages when the fault is > resolved. > > If the ESP is good, the the sender will have access to a support team, so all > faults should be actionable. > > > > On 11 Dec 2015, at 11:59, David Hofstee <da...@mailplus.nl> wrote: > > > > That’s why, in ESP parlance, there are two sorts of bounces, to keep it > > simple: > > - Hardbounces: The recipient address does not work. Contact > > through other means. > > - Softbounces: This email did not arrive. Try again later or > > contact through other means. If this keeps happening the address > > effectively does not work. > > > > What else is there to do? The sender might be curious to what the reason is > > (if the bounce is even telling you that) but it does not change the outcome > > or the call to action. The only things that are actionable for a sender, in > > a message, is when the content gets un
Re: [mailop] Delivery to gmail via IPv6
> On 10 Dec 2015, at 18:43, Franck Martin <fmar...@linkedin.com> wrote: > > It also has to do with people not understanding DSN. Seriously they are ugly > and hard to find the relevant information in them... Agreed, but if the recipient doesn’t understand the message, and doesn’t act on it, then it doesn’t matter whether it’s a bounce or a delay warning. But my experience is that some people do report bounces, and some people do report delays warnings. In fact, some report delay warnings *as* bounces. And, if we’re talking about all messages to Google being delayed, then someone will report one. And I will notice. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Delivery to gmail via IPv6
> On 8 Dec 2015, at 18:31, Franck Martin <fmar...@linkedin.com> wrote: > > Yes, reject > > It seems that email systems that send you a DSN because of a temporary > rejection are becoming rarer… Well, that might be an artefact of more reliable mail systems, and market concentration around medium and large mail providers that tend to fix things quickly when they do go wrong. I think Exim has a default first warning after 24 hours. But really, that’s not the responsibility of the recipient’s mail provider, it’s the responsibility of the sender’s mail provider. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] The way ahead
> On 22 Oct 2015, at 16:36, Kurt Andersen (b) <kb...@drkurt.com> wrote: > > +arc-discuss > > On Thu, Oct 22, 2015 at 11:22 AM, Jim Popovitch <jim...@gmail.com> wrote: > > This has a feeling of "cart before the horse". :-) Mailman, and > presumably other list mangers, now "wrap" dmarc'ed emails before > forwarding, where's the value-add for ARC? > > Jim, > > While there have been options for mailing lists to "wrap" email conversations > for a long time, many list administrators and participants have fairly > violent objections to doing so. ARC is a mechanism to inform local policy > decisions that does not require the intermediaries to take "ownership" of the > mail via DMARC alignment on the mail from. > > --Kurt Andersen It’s good to see this stuff being addressed, Kurt. Thanks! A couple of minor errors in the draft: 1. The two references to RFC5321 (in section 5.1.1) should I think be references to RFC5322. https://tools.ietf.org/html/draft-andersen-arc-00#section-5.1.1 2. Formatting problems in the Examples, specifically in the Return-Path lines, and all with opening square brackets in the Received headers. Return-Path: jqd@d1.example> Received: from \[10.10.10.131] (w-x-y-z.dsl.static.isp.com \[w.x.y.z]) -- 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] Spam to "published" address?
> On 15 Oct 2015, at 19:56, Jay Hennigan <mailop-l...@keycodes.com> wrote: > > > And, I've never seen language like "publishing implies consent" in the policy > of any legitimate ESP. The ESP’s policy isn’t relevant. What’s relevant are the laws in your jurisdiction. In the EU, there are two conditions that permit sending marketing (including charity, political, and pressure group campaigning) email to personal email addresses. First an existing business relationship. Second explicit permission. It doesn’t matter how the permission is expressed, but it must be expressed. So, publishing a call for business proposals might qualify, I suppose: top tip, give a deadline if you’re doing that! But you’ve said you aren’t. So this is a red herring. Even then, EVERY email must carry an easy to use mechanism to opt-out. That means a visible link, in my view. Anyway, if you haven’t published a request for emails, then this clause isn’t relevant. They’re spamming you. -- 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] Mail servers tracking list substrictions
> On 25 Sep 2015, at 01:01, Michael Peddemors <mich...@linuxmagic.com> wrote: > > On 15-09-24 04:49 PM, Hal Murray wrote: >> How many of the bulk mail senders would cooperate? Would they be willing to >> switch all their customers to real opt-in? > > Called 'confirmed double opt-in', and I think everyone wishes they would :) > Also very interesting studies on conversion rates for confirmed double opt-in > vs single opt-in. > > And amazing how many people still like to sign up other ppls' email addresses > ( like fake ordering pizzas ) as a lark.. I’ve run community events where we’ve gathered several dozen email addresses, on paper forms, for the explicit purpose of contacting those people later. I tried adding them to a mailing list, that week, with confirmed opt-in, and about 10% of people responded to the email asking them to confirm the opt in. So, I abandoned that approach, and signed them up to a email list (Google Groups), without confirmation. I got no complaints. So, while confirmed double opt-in is essential for online signups, I don’t think it’s essential or even desirable for face to face sign-ups. The problem is that it’s really hard for a mailing list system to tell the difference. -- 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 08:23, Brandon Long <bl...@google.com> wrote: > > On Wed, Sep 9, 2015 at 5:32 PM, Robert Mueller <r...@fastmail.fm> 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 <r...@fastmail.fm> 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] Hotmail/Microsoft/Outlook - getting their attention
> On 5 Sep 2015, at 00:18, Brandon Long <bl...@google.com> wrote: > > but my trolling through the online archive "Trawling", surely ;^) -- 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] Hotmail/Microsoft/Outlook - getting their attention
> On 3 Sep 2015, at 18:42, Marc Perkel <supp...@junkemailfilter.com> wrote: > > Does anyone have any suggestions about how to get their attention and fix > their problem? > > I'd be happy to replace their lame spam filtering with mine. :) We have a hybrid exchange setup, with staff on a local Exchange server, and students using Exchange Online (EOL). We get all inbound mail through a local gateway, and delivered to the local server, which then delivers it locally or to EOL. There’s an option to use MS spam filtering for traffic going from one part of the hybrid to the other. Today, I saw it mark up, as "High Confidence Spam", a message sent by Microsoft to one of our Students. Fortunately, I can switch this off! -- 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] [uk-mail-managers] Blacklisted by hotmail/live (fwd)
That doesn’t look like a paraphrase to me. That looks like a Microsoft web error message. Searching for that string returns several hits on MS forums, for example. Of course, more details about the context would help! One of the forum messages is complaining about the response from the Sender Information for Outlook.com Delivery form at https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0wfname=capsubproductkey=edfsmsbl3ccsid=635664100181092734 for example. On 23 Jun 2015, at 16:44, Michael Wise michael.w...@microsoft.com wrote: What's the IP range in question? What's the error, exactly? Paraphrasing in this context helps no-one. If it's an error in the ticketing system, I might be able to get eyes on it, but otherwise... There is a support procedure that must be followed, no exceptions as per Legal. Aloha, Michael. -- Sent from my Windows Phone From: J.R.Haynes Sent: 6/23/2015 8:21 AM To: mailop@mailop.org Cc: c.mcdow...@qub.ac.uk Subject: [mailop] [uk-mail-managers] Blacklisted by hotmail/live (fwd) I know there are hotmail people who monitor this list - can somebody help my colleague at another UK university with their blacklisting please? Thanks -- -- Jonathan Haynes Senior Network Specialist, IT Department Building 63, Cranfield University, Cranfield, Bedfordshire MK43 0AL W: https://na01.safelinks.protection.outlook.com/?url=www.cranfield.ac.ukdata=01%7c01%7cmichael.wise%40microsoft.com%7c10750ba72ed941b63b0d08d27bdf7750%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=FsyLyazchWyeSQ2Ry4R%2bLlfZghUnX6YMssYp8zG1G14%3d E: j.hay...@cranfield.ac.uk T: +44 (0)1234 754205 -- Forwarded message -- Date: Tue, 23 Jun 2015 15:24:42 +0100 From: Clive McDowell c.mcdow...@qub.ac.uk To: uk-mail-manag...@jiscmail.ac.uk Subject: [uk-mail-managers] Blacklisted by hotmail/live It looks as though our entire address space has been blacklisted by Hotmail/live. When we try to contact Microsoft via the support web pages we get the helpful message - Oops, we've encountered a temporary technical problem. We're working on resolving this right away but in the meantime, please try again! This has been going on for two days now and is extremely detrimental to the business of the university. Does anyone have any contacts or other useful information that may help with this? Thanks, Clive McDowell Information Services The Queen's University of Belfast ___ mailop mailing list mailop@mailop.org https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fchilli.nosignal.org%2fmailman%2flistinfo%2fmailopdata=01%7c01%7cmichael.wise%40microsoft.com%7c10750ba72ed941b63b0d08d27bdf7750%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=4Yd64gEpT1lxHL6pvZ%2bd4ePIOUKx0WMTWwwmIUessxQ%3d ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop -- 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] spam filter deleting emails with php links
On 25 Mar 2015, at 15:55, Franck Martin fmar...@linkedin.com wrote: On Mar 25, 2015, at 8:24 AM, Howard F. Cunningham howa...@macrollc.com wrote: I was told that the problem was that there was a rule in their filters that delete, without notice, all emails that have php links in the emails? Has anyone ever heard of deleting emails with php links in a spam filter? A bit drastic, the message should have been bounced during the SMTP transaction. I prefer the term rejected or denied. To me, bounced implies the sending of a non-delivery notification: you can’t be sure that will happen unless you generate the notification yourself. I think that’s the sense in which the terms are used in the SMTP RFCs. It does not surprise me someone would want to block such emails, considering the number of compromised wordpress installation (that uses php). However it is likely to have significant collateral damage. Too true. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ mailop mailing list mailop@mailop.org http://chilli.nosignal.org/mailman/listinfo/mailop
