Re: [mailop] Hotmail/Outlook feedback loop processing delay?
On Tue, 09 Jan 2018 20:59:04 +0200, Sotiris Tsimbonis said: > Hi all, > > I received today (9 Jan 2018) a message from outlook's feedback loop > with a message that was originally sent to a hotmail address on 30 Jan 2017. Just as a gentle reminder - sometimes the Date: is incorrect because the system clock on the box is horribly broken. It's amazing how long stuff runs on autopilot - as of last year, there were still some 800 systems that were pointing NTP at one certain IP address that used to be in my office running a stratum-2 NTP server. The weird part? That box was removed from the public 'clocks.txt' document in 1998 and decommissioned in 1999, the IP never re-used. Think about that for a bit. pgpG44g9l4Lvp.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Google groups dropping mail?
On Wed, 22 Nov 2017 11:28:08 +0100, Leo Gaspard said: > hours (between 10.200.48.129 and 10.55.109.198 if someone knows what > those IPs mean), and then for exactly 8 hours (between > mail-vk0-f56.google.com and and... itself?) before reaching my server. Sounds almost like two different processes on the same server, but running with different timezones in their environment. pgpOUjBcoDqun.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some
On Thu, 09 Nov 2017 13:46:05 -0800, "Luis E. Muñoz via mailop" said: > On 9 Nov 2017, at 13:33, Charles McKean wrote: > > > Legal? Was that a threat? Do you have prior experience attacking a > > lunatic asylum with a banana? Best of luck. > > I suspect^Whope this is a language thing. Almost positive. > >> When will a legal explanation come from Hotmail (or Microsoft)? I think the word Emre was looking for was "legitimate" pgplACpYW8DQp.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail forwarding blowback
On Wed, 08 Nov 2017 11:42:41 -0800, Michael Peddemors said: > Besides, you want to keep the customer, not make him a gmail customer ;) If the mail service is bundled with something else that's a profit center, unbundling the cost center part and handing that to Google will improve your bottom line.. ;) pgp8awhZxd04o.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SENDERSCORE
On Wed, 25 Oct 2017 12:50:16 -0600, "Anne P. Mitchell Esq." said: > Weirdly, every single email in this particular thread ended up in Gmail's > spam folder. Any good guesses as to why? My email is also hosted at GMail, but none of the thread ended up in my spam folder. So whatever it was, it must be something subtle... pgp8U67IA6C4Q.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] AOL Postmasters - Syntax replacement for http://postmaster.aol.com/faq/mailerfaq.html#syntax
On Tue, 24 Oct 2017 07:56:19 -0400, "Kevin A. McGrail" said: > Recently we were alerted to a valid address that did not meet the syntax. Are you able to tell us in what way it didn't meet the syntax, and how you confirmed it's valid anyhow? pgp8_pvw2dwEM.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
On Sat, 07 Oct 2017 01:30:27 +0200, Philip Paeps said: > On 2017-10-06 15:18:45 (-0700), Brandon Long via mailop wrote: > >It can also aid in using say geohop stats. Ie, one easy way to try to > >detect hijacking is to geoloc the accessing IP, and see how close it > >was to the last access, or keep track of where the user is accessing > >from. This has obvious issues if your users travel. If a user with a > >phone that supports it goes somewhere else, chances are they'll access > >from the phone first, even if their desktop client doesn't support > >client-token, so you have a strong signal that they traveled somewhere > >else. > > This paragraph sounds incredibly creepy... I'm glad I'm not one of your > users! I read it as "even if they travel, we have a way to identify it's them and not an impostor". Can be really handy sometimes. I notified my bank that I was going to the Philippines once - and had my card declined in the Beijing airport because it wasn't the Philippines. Now that they have given out new cards that have chips on them, my bank can be more sure that it's really my card in the Beijing airport next time pgpwLPdZ_FFiQ.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] [RFC 2822] RFC Header Line Length..
On Thu, 10 Aug 2017 07:57:14 -0700, Michael Peddemors said: > Seeing more and more cases of this not being honoured.. > Surprised that there is not more breakage, but noticed that Yahoo's DKIM is > now one long line, in addition to Microsoft's VERY long header lines.. I wonder if this is the source of some "never did figure it out" DKIM breakage? pgpu_qnIOj957.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] self-signed cert for inbound TLS
On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said: > Why can't smtp software being expected to maintain a list of trusted CAs? > Or at least run on an OS that is expected to do so. Quick: What two CAs did Google just remove from Chrome's list? Has your OS vendor followed suit? And what percent of your OS vendor's installs are prompt in applying patches? pgpwnCPJNDv7D.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] User question about getting off blocklists
On Wed, 12 Jul 2017 12:10:21 -0500, "Scott Bonacker CPA" said: > The IP for abanet.org is (currently) listed on CASA and SORBS as a bad sender > What authority is required to make a request for removal from a block > list? Certainly not a user, but what level in the sending > organization? As a user, you can vote with your feet/wallet and find hosting someplace that doesn't have that happen to them often. pgpkjCc_3bts_.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] btinternet.com blacklist
On Wed, 12 Jul 2017 00:46:28 -, Michael Wise via mailop said: > Youâd be surprised how many people think that their sincerity is flagged in > the protocol somehowâ¦. RFC3514 was written explicitly to add support for that. pgpzmD8obTwjW.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] So, about this iOS10 unsubscribe feature...
On Tue, 23 May 2017 09:29:34 -0400, Joey Rutledge said: > Do you guys have any samples of the invalid Unsubscribe headers? There is a > newish spec (RFC8058; https://tools.ietf.org/html/rfc8058) that Iâve seen > floating around and wondering if those are the headers screwing things up. That probably isn't it - 8058 adds a new "one-click' option to the very old List-Unsubscribe: (how old? RFC2369 is from last century). Or more properly, it's a method to tag the URI as being a one-click auto-ambush link, and that gratuitously following it in the MTA may piss the user off. For it to add to your queues, somebody would need to be using the one-click unsub with a mailto: URI, *and* your local e-mail purgatory software needs to (a) chase the URI as part of anti-spam/malware protection and (b) do so even if it's a mailto: rather than http: or ftp: or gopher: or so on. Having said that, I've seen lots more questionable design decisions pgpvrkeAxU5L5.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF record
On Mon, 22 May 2017 14:42:20 -0700, W Kern said: > I am talking about the scenario where a third party sender WITH an -all > SPF record sends to my customer and then MY customer forwards it > elsewhere (gmail, hotmail). So you accept spam if it has a valid SPF? pgp1vLecxuz_9.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF record
On Mon, 22 May 2017 13:21:08 -0700, W Kern said: > On 5/22/2017 11:22 AM, valdis.kletni...@vt.edu wrote: > > not an SPF problem. > > Forwarding has worked just fine for 30 or so years, if not longer. The > > "problem" only happens if you insist on attaching SPF to it. > Except when it is a shared server and that server forwards enough > spam/virii (despite anti-spam efforts) to a common email host (gmail, > outlook, etc) to get EVERYONE on that server blocked. Then it's your fault for *accepting* the spam/virus that ended up getting forwarded. > failure or when their customers Website is delivering transactional > email but the customer didn't alter their SPF record to include the > webserver. That isn't even related to the point under discussion - SPF and forwarding. pgpGokSVJjYbq.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] SPF record
On Mon, 22 May 2017 10:59:21 -0700, Michael Peddemors said: > Some have pointed out on the list the problem with 'forwarding', however > that is a forwarding problem, and not an SPF problem. Forwarding has worked just fine for 30 or so years, if not longer. The "problem" only happens if you insist on attaching SPF to it. If a car manufacturer had been making perfectly usable vehicles with perfectly functional windshield wipers for decades, and you discovered that the windshield wipers tend to malfunction when you attach other devices to the windshield, is that the fault of the windshield wipers, or the other devices? > Since every email client out there can check multiple mailboxes, if you > want to properly take advantage of SPF as a recipient, don't do email > forwarding ;) No, what you meant was: If you want to properly take advantage of SPF as a recipient, ensure that no users at other sites set a forward to your mail system if their sysadmin has set an SPF record that will cause problems. Which is, in general, obviously not achievable. pgplKjkIt9ptZ.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Speaking of too many SPF, Many SPF failures lately
On Thu, 18 May 2017 08:53:37 -0700, "Luis E. Muñoz" said: > large ranges in the SPF validation. I suppose it would be plagued with > false positives, but if enough people did it, it would give some > priority to actually think about your SMTP flows when setting up your > SPF records. That sort of thinking may have worked 3 decades ago, when Sendmail 5.67 was the latest and greatest way to move e-mail around, and pretty much all the sysadmins on the network knew each other by reputation, and posting "Hey guys, I can't seem to get this working, what am I missing?" was guaranteed to get you useful help. However, I haven't seen much evidence that it's been a workable strategy anytime this century. In particular, it would require a number of 800 pound gorillas who are mostly centered around increasing the success percentage to voluntarily choose a course of action that would lower the percentage - and they'd be relying on the set of sysadmins who did the *least* thinking about their configuration to fix their stuff. Phrased differently - did anybody in school *ever* voluntarily choose to work on a project with the least clued and engaged student in the class, in hopes of improving their own grade on the project? pgpKpSNoaca12.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] does Google use SAME outbound IPs for "G suite" as they do for gmail?
On Fri, 05 May 2017 14:50:54 -0700, Brandon Long via mailop said: > In reality, ESPs exist along a spectrum, both in their ability to keep > spammers out and their desire to. And "spammers" also exist along a > spectrum, from folks clearly knowing they are doing it to folks who don't > to entities who have controls in place but occasionally fail. And entities > can also be compromised and used by spammers. The word "egregious" was used. That pretty much rules out entities that have controls in place, and most cases of compromised entities. "Egregious" does cover folks who clearly know they are doing it. And in 2017, if you're somebody who doesn't know if they're spamming, there's only two options: (a) You are a spammer in denial or (b) You need to get a lot more clue *now* or get out of the business. pgp7YqWohSXaa.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] does Google use SAME outbound IPs for "G suite" as they do for gmail?
On Fri, 05 May 2017 10:48:46 -0400, Rob McEwen said: > Does Google use the SAME?... or DIFFERENT?... outbound IPs for "G suite" > (or any other customers who are using their own domain names) ...as they > do for @gmail.com addresses? Don't your own logs have enough info in them for that? See what addresses you receive @gmail.com mail from, and @google-hosted-stuff.com pgptsysZZlkNw.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Do we need a new list for reporting spam? (Was Re: Admin: This is not a place to report Spam. )
On Mon, 10 Apr 2017 12:21:45 -0600, Ryan Harris via mailop said: > It might be helpful to understand why people want to post on email forums > rather than an abuse desk. Is it to gain public attention on the matter? Is > there a bit of shaming going on and the reporter wants the community to > know they are fed up with the ESP? Are people reporting on public forums > b/c they want to know if others are experiencing the same problem? Posting the spam itself on forums is pretty much pointless. On the other hand, having a forum where you can ask "Are the guys who are supposed to be dealing with ab...@robot-penguins.xyz merely clueless or actively rogue?" or "Does anybody have a contact at helium-filled-cows.com?" does have value Cue somebody saying "in 2017, being clueless *IS* actively rogue" in 5..4..3 :) pgp1pfV05N4c5.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] conventional wisdom, was Google rejects a TLS connection
On 17 Mar 2017 15:47:50 +0100, "John R Levine" said: > I used to have my own credit card account and my card processor demanded > PCI compliance. About 1/4 of it was reasonable, 3/4 was cargo cult stuff > that mostly involved stuff like setting packet filters so they couldn't > probe ports that weren't going to answer anyway. I gave up on thinking that PCI was something other than an extortion racket a number of years ago, when somebody reported on the major breaches of the year and noted that 100% of them were in full PCI compliance at the time of the breach. pgpFr_Mad6Rf1.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]
On Wed, 15 Feb 2017 05:59:36 +, Phil Pennock said: > I believe Brandon's point is that this is a probe _of_ Gmail, not _by_ > Gmail, and the service purporting to be testing RFC conformance is > instead doing a very old-style message with no headers at all. Right. The test sends something that's not 5322 compatible, so gmail saying it's not 5322 is correct behavior. So unless it's a test to ensure that particular flavor of broken is correctly rejected, I'm not sure what the point being made was... > As of ye olde RFC2822, there are mandatory headers, "From:" and "Date:", > so Gmail is insisting upon having the RFC-mandated headers, so rejects > the mail, so the RFC conformance testing tool is issuing a > false-positive. I believe the phrase "violently in agreement" applies here. :) pgpagTr5OXmV9.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] blocking mails/networks (was: Mails to microsoft)
On Mon, 13 Feb 2017 09:16:42 -0800, ml+mai...@esmtp.org said: > How would a user know that (s)he missed a mail? > > I sometimes send patches to various open source projects and if a > mail to the maintainer bounces due to some "anti-spam" measures, > then I take that as an indication that they don't care -- so why > should I try to reach the maintainer in some other way? Turn that around. How would the *maintainer* know he missed a mail due to their provider's anti-spam magic incantations? If nobody tries to reach them in some other way, they may be sitting there wondering why they get so few patches to merge pgpkL7u7wEyFM.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Enforcement of RFCs [was: GoDaddy Email admins' in the house?]
On Sun, 12 Feb 2017 07:52:25 -0500, Rich Kulawiec said: > On Wed, Jan 11, 2017 at 12:33:47PM -0800, Michael Peddemors wrote: > > More and more, if you want to deliver email in today's environments, you > > have to ensure your email servers are correctly configured. > > I think there's considerable value in slowly enforcing this in stepwise, > announced fashion. And where do you announce it where all the mail system administrators who don't read the *current* BCPs will see it and act on it? pgp1mxrhriC_L.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Odd spamcop glitch
On 23 Jan 2017 21:30:20 +, "John Levine" said: > That led to great merriment, since that's Blue State Digital and mail > from mainstream political groups went into spamtraps that tested the > URLs, some of which were "Click here to donate now with your preregistered > credit card!" Oops. OK, I'll bite. How did the mail end up at a spamtrap address in the first place? Somebody maliciously signed the address up for a mailing list? Or some other failure mode? pgppvCDnIC97w.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Mysterious DKIM failure.
On Mon, 12 Dec 2016 13:26:04 -0700, Luke Martinez via mailop said: > Whether or not you should ignore changes to whitespace and capitalization > seems like a fairly trivial thing. Not when you're talking about a cryptographic signature, where a single changed bit should change the signature drastically. pgpvlrqjHabwc.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection
On Sat, 19 Nov 2016 08:33:27 -0800, Carl Byington said: > Of the 220 sites identified above, 218 of them manage to see the icmpv6 > packet and respond by resending with a packet that makes it thru the > tunnel. I suspect that packets from at least one of those 218 sites goes > thru many of the same systems as the packets from login.yahoo.com. > https://www.mega.nz and https://www.1fichier.com seem to have the same > icmpv6 filtering issue. OK, you're *almost* done. Now take the sites that failed, and traceroute -6 to them, and then to several sites that work (just as a control). What router(s) do the 3 failing sites (yahoo, mega, and lfichier) have in common, which are *not* in the path to a site that works? ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection
On Fri, 18 Nov 2016 13:01:50 -0800, Carl Byington said: > response to that will be a bunch of full size packets from Yahoo with > the certificate, etc. The *far* end of my tunnel will be sending the > icmpv6 "packet too big" back to Yahoo. And you identified that the problem was at Yahoo, and not one or more of the hops between the far end of your tunnel and Yahoo, how, exactly? pgptbYp3YHmou.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Anyone from Yahoo - icmpv6 filtering breaks login.yahoo.com MTU detection
On Fri, 18 Nov 2016 11:58:58 -0800, Carl Byington said: > If you have IPv6 connectivity thru a tunnel, with a smaller MTU, that > will fail. With a 1500 byte MTU, it works. The TCP handshake works - it > then hangs during the TLS handshake which sends full size packets. Did you do anything to specifically identify Yahoo's routers as the offenders? Hint: If there's a tunnel in the path, it will be *your* end of the tunnel that sends back the "can't frag" ICMP. So the filtering is happening somewhere between your end of the tunnel and you. pgpBSyxc1Fhnl.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Microsoft Blacklisting IPs
On Thu, 17 Nov 2016 16:58:35 +0100, Hetzner Blacklist Support said: > our customers who use them on their own dedicated servers. They're the > ones having issues, since Microsoft has blacklisted large parts of our > network. That should be your big hint that you have a customer problem. (The other possibility is that Microsoft actually screwed up, but when you're talking huge chunks of address space, it's more likely quite intentional on their part and done for good reason) > In this case, I'm talking about hundreds of thousands of IPs from our > network being blacklisted by Microsoft. At some point, people get fed up with blacklisting individual IP addresses and start blocking /24s and working up to /16s. Especially if the number of *legitimate* e-mails from the /24 or /16 is far less than the number of spam e-mails. Hopefully, at some point the collateral damage makes the owner of the address space finally take action (remember - it's causing Microsoft a lot less pain than it is causing your legitimate customers) If in fact you have hundreds of thousands of blocked IPs, that means you've managed to get multiple /16s (or larger) blocked. That takes some doing. And at that point, you should probably be checking where *else* you've been blacklisted - I highly doubt that Microsoft has been the only one your customers have been spamming. Step 0 is going to be figuring out what's *really* going on with your customers. pgpk03ICq3KMs.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] connection issues from .*?.bullet.mail.(skk|kks).yahoo.co.jp
On Fri, 28 Oct 2016 11:09:27 +0200, Benoit Panizzon said: > > PS: Maybe I am not supposed to send multiline prompts if a server > > greets with HELO instead of EHLO? > > Note to self, next time read RFC before sending email... > > Old RFC 821 does not state, that a reply to HELO can be multiline. > After changing my spamtrap to only send one line in reply to HELO, it > is getting a lot of spam from all over yahoo.co.jp. What RFC 821 actually says in section 4.2: An SMTP reply consists of a three digit number (transmitted as three alphanumeric characters) followed by some text. The number is intended for use by automata to determine what state to enter next; the text is meant for the human user. It is intended that the three digits contain enough encoded information that the sender-SMTP need not examine the text and may either discard it or pass it on to the user, as appropriate. In particular, the text may be receiver-dependent and context dependent, so there are likely to be varying texts for each reply code. A discussion of the theory of reply codes is given in Appendix E. Formally, a reply is defined to be the sequence: a three-digit code, , one line of text, and , or a multiline reply (as defined in Appendix E). Only the EXPN and HELP commands are expected to result in multiline replies in normal circumstances, however multiline replies are allowed for any command. Note the last sentence. pgpT84Y6uOeHL.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] 21cn.com connection reset before QUIT
On Thu, 20 Oct 2016 17:59:46 -0400, Mitchell Kuch said: > Filtering by either > the List-Id header contains "" > or > a Received header contains "for mailop@mailop.org" "D'Oh!" -- H. Simpson. Apparently, the last time I looked at this and gave up in disgust, List-Id: wasn't as common out in the wild. And Recieved: headers are so often a morass of non-standard formats I never considered filtering on them pgpm82msrL6rZ.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] 21cn.com connection reset before QUIT
On Thu, 20 Oct 2016 15:57:24 -0400, Mitchell Kuch said: > inbox. Gmail discards what it considers to be duplicate messages. I > find this to be a frustrating behavior. And most of the time, that's not too bad - if somebody cross-posts to two lists that you're on, you'll get only one copy. And that's OK, because almost nobody does mail filtering of such things into separate folders (or more correctly, there's usually no sane way to do so, because whatever rule you set in .procmailrc or whatever, *both* copies will end up going the same path). The *annoying* part is that if you post via Google, it records the Message-ID: that it assigns to you *outbound* post, and then filters out *all* inbound copies with that ID. This means that you don't get to see your own post. The best workaround I've found so far is to have your MUA do message submission to a non-Google mail server. Whether you can find one that will accept mail with your From: is a different matter (for me, $DAYJOB runs a suitable service locally). pgpHp1SFZKSGl.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Spamhaus and Spamcop Blacklisting
On Tue, 13 Sep 2016 14:23:20 +0100, Rupesh Gohil said: > Yes email marketer having those IPs. Is it really hard to come out from > Drop? - Email Marketer has 20 to 25 Spamtraps and these spamtraps has been > removed now. Removing the spamtraps won't fix the problem. Your Email Marketer needs to fix the very deep issues in their business process that allowed those spamtraps to get *onto* their lists in the first place. pgpCKNl_Q5yIi.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Google: Increase in false positives?
On Fri, 02 Sep 2016 14:27:39 -0400, Jim Popovitch said: > On Fri, Sep 2, 2016 at 4:28 AM, Brandon Long via mailop >wrote: > > The spam team would love to send all unauthed mail to the spam label or even > > reject it (they call it no auth no entry). > I'd love to see "no auth no entry", but I'd prefer to see native PGP. ;-) Only if you agree to handle all the support calls regarding web-of-trust. :) (This is a major problem for deploying e-mail crypto at scale - http://pgp.cs.uu.nl/plot/ says the strongly connected set in the web-of-trust is right around 60,000 keys - which amounts to about 0.001% of the world population. You want PGP to take off, you need to find a sane way for the *other* 99.999% of the population to do keys correctly) pgpfFCPKJ5xY8.pgp Description: PGP signature ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop