Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

[Vick Khera]

On Wed, Aug 29, 2018 at 6:13 PM Michael Rathbun  wrote:

>
> What's satisfying is that Harris Polls (now part of Nielsen), one of the
> earliest villains in the narrative, is now a client of mine, with
> subscription
> policies so restrictive that I wasn't able manually to subscribe a seed
> account -- their fraud detector detected me and locked me out.  I had to
> make
> a phone call to get sample traffic.  Some days, the magic works.
>
>
I think this falls in the "known trouble makers" category that some address
validation vendors report as "do not send". I used to keep a list of
anti-spam folks as part of my traps against new customer list imports, and
shockingly it did trigger from time to time and never being legitimate
opt-in.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] QQ Postmaster

[Vick Khera]

On Mon, Jul 16, 2018 at 2:43 PM, Udeme Ukutt  wrote:

> Please can a QQ (China) postmaster (or someone that knows one) contact me
> off-list? Thanks.
>
>
I'd be curious to know if you are successful. My recollection is they just
don't care if you are outside of China.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] verizon.com Postmaster

[Vick Khera]

On Wed, May 9, 2018 at 7:03 AM,  wrote:

>
> dcsactrans2.verizon.com
>
> The hostname is invalid.
>

I'm curious what your FP rate is on this strict checking of the HELO host
name. I don't believe any of the major inbox providers do it, which should
be a clue it is not very accurate of a signal.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] No MX records for mail.mil

[Vick Khera]

On Thu, May 3, 2018 at 10:33 AM, Frank Bulk  wrote:

> This doesn’t look so good, though:
>
> http://dnsviz.net/d/mail.mil/dnssec/
>
>
>
>
>
Yes, that looks bad :(

I have to learn more how to query/interpret my dns server's DNSSEC output,
or make it more strict.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] No MX records for mail.mil

[Vick Khera]

My own office resolver running unbound has DNSSEC enabled with strict
checking, and the response I get shows it is authenticated data: the "ad"
flag is on.  Based on that, DNSSEC is working for them as far as my
understanding goes. My first guess was also it would be a DNSSEC issue.


; <<>> DiG 9.10.6 <<>> mail.mil mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25907
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mail.mil. IN MX

;; ANSWER SECTION:
mail.mil. 797 IN MX 10 pri-jeemsg.eemsg.mail.mil.
mail.mil. 797 IN MX 20 sec-jeemsg.eemsg.mail.mil.

;; Query time: 0 msec
;; SERVER: 192.168.135.1#53(192.168.135.1)
;; WHEN: Thu May 03 09:51:57 EDT 2018
;; MSG SIZE  rcvd: 97





On Thu, May 3, 2018 at 9:32 AM,  wrote:

> Looks to be a DNSsec issue ... please correct me if I have that wrong.
>
> Frank
>
> -Original Message-
> From: Frank Bulk (frnk...@iname.com) 
> Sent: Thursday, May 3, 2018 8:28 AM
> To: 'mailop@mailop.org' (mailop@mailop.org) 
> Subject: No MX records for mail.mil
>
> I haven't investigated this thoroughly, but it seems like mail.mil is not
> returning MX records from certain DNS resolvers.
>
> Frank
>
> 
> DNS server: 1.1.1.1 (Cloudflare DNS)
>
> ; <<>> DiG 9.7.3 <<>> MX mail.mil @1.1.1.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49376
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;mail.mil.  IN  MX
>
> ;; Query time: 67 msec
> ;; SERVER: 1.1.1.1#53(1.1.1.1)
> ;; WHEN: Thu May  3 08:24:43 2018
> ;; MSG SIZE  rcvd: 26
>
> 
> DNS server: 1.0.0.1 (Cloudflare DNS)
>
> ; <<>> DiG 9.7.3 <<>> MX mail.mil @1.0.0.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39108
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;mail.mil.  IN  MX
>
> ;; Query time: 4171 msec
> ;; SERVER: 1.0.0.1#53(1.0.0.1)
> ;; WHEN: Thu May  3 08:24:47 2018
> ;; MSG SIZE  rcvd: 26
>
> 
> DNS server: 8.8.8.8 (Google DNS)
>
> ; <<>> DiG 9.7.3 <<>> MX mail.mil @8.8.8.8
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29691
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;mail.mil.  IN  MX
>
> ;; Query time: 34 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Thu May  3 08:24:42 2018
> ;; MSG SIZE  rcvd: 26
>
> 
> DNS server: 8.8.4.4 (Google DNS)
>
> ; <<>> DiG 9.7.3 <<>> MX mail.mil @8.8.4.4
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27285
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;mail.mil.  IN  MX
>
> ;; Query time: 76 msec
> ;; SERVER: 8.8.4.4#53(8.8.4.4)
> ;; WHEN: Thu May  3 08:24:42 2018
> ;; MSG SIZE  rcvd: 26
>
> 
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft IPs automatically unsubscribing recipients?

[Vick Khera]

On Thu, Mar 1, 2018 at 6:26 PM, David Carriger <
david.carri...@infusionsoft.com> wrote:

> Yes, I'm still seeing this. So, an open question:
>
> As an ESP, how am I supposed to tell my users to practice good list
> hygiene and remove unengaged recipients from their lists when my data is
> being tainted by Google/Microsoft/etc triggering all of my engagement
> mechanisms (open tracking pixel, tracked links, etc)? These show up as
> their *most* engaged recipients.
>
Build in some intelligence to the tracking to detect a single remote IP
tripping every single link in your message within a few seconds, and ignore
it. Over time you will start to learn the IPs to just ignore up front. I'm
sure you can come up with some more intelligent methods too, using neural
networks or some such fancy pants trendy technology. :)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GSuites looking too closely at first-hop Received: headers?

[Vick Khera]

On Tue, Feb 27, 2018 at 1:43 AM, Philip Paeps  wrote:

> Of course relays do get compromised from time to time, so peeking at the
> first hop is not a completely crazy thing for GSuites to do. But silently
> dropping the email after accepting feels a little disproportionate. Perhaps
> a 451 would be more appropriate?
>
>
>
A while back Brandon helped me figure out that this was caused by having
set one machine as a known relay in the G Suite configuration. This caused
it to always check the prior hop's IP reputation and more or less ignore
that it came from the relay machine.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mail Transfer Agent Alternatives

[Vick Khera]

On Mon, Feb 5, 2018 at 2:23 AM, Emre Üst |euro.message| <
emre@euromsg.com> wrote:

> Hello everyone ,
>
> We are using Powermta(Port25) but their support service fee is rediciously
> high . We are looking for new mta . Could anyone recommend to Port25
> altenatives ?
>
>
Just before we got bought out, I too was looking for replacements to our
sending infrastructure. We were on Message Systems Momentum in-house, and
were one major version behind. We were at the point of having to buy the
next version up since annual maintenance did not cover the major version
bump. We looked at the solutions listed here, as well as one that has not
yet been mentioned, mailerq. I met the folks behind it a M3AAWG meeting and
they were very impressive and the product seems very impressive as well.
Definitely worth a look. It was one of my top contenders.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Earthlink trouble with our PTR

[Vick Khera]

On Thu, Dec 14, 2017 at 9:27 AM, Ryan Prihoda 
wrote:

>
> What about SPF, DMARC, DKIM ? I am sending 250k/day and only Earthlink
> seems to care. How many checks are actually necessary ?
>
>
You should look to implement SPF and DKIM for sure.

As for only earthlink seeming to care, how do you know this? You cannot
reliably and accurately measure inbox placement. Just because they don't
block you at the gate doesn't mean you are not being penalized for having
inconsistent DNS.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] lost connection with amazon-smtp.amazon.com

[Vick Khera]

On Mon, Aug 7, 2017 at 4:24 PM, Doug Barton  wrote:

> "lost connection with amazon-smtp.amazon.com [some_IP_address] while
> receiving the initial server greeting"
>

My first thought is some sort of timeout, or possibly a firewall rule
breaking the connection. Or maybe Amazon just hangs up on you for some
other unknown reason.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

[Vick Khera]

I've not had any issues with self signed certs with TLS on SMTP. That said,
lately I've been using Lets Encrypt certificates with the certbot program
to manage them, and that has worked really well. The initial setup takes a
little effort to do a DNS based verification since the mail hosts are not
running HTTP servers to do the automatic verification. Renewals are
automatic, though.


On Tue, Jul 25, 2017 at 10:51 AM, Jonathan Leist  wrote:

> Hello,
>
> We're looking to implement inbound TLS on machines that are only used to
> send mail and receive bounces, and I was wondering if anyone has
> encountered problems using a self-signed cert for that purpose. It seems
> like it would be easier to implement on a larger scale than would CA-signed
> certs—and using the self-signed cert worked fine in tests—but we also
> obviously don't want to do anything that would prevent us from receiving
> bounces.
>
> Thanks for your time.
>
> --
> Jonathan
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo! CFL Sign-up Difficulty

[Vick Khera]

On Tue, Jun 20, 2017 at 4:16 PM, David Landers <
david.land...@livingsocial.com> wrote:

> I am attempting to change the reporting email address for the Yahoo! Complaint
> Feedback Loop (CFL) service, and submitting the new information via either
> an "Add" or "Update" request does not seem to be working.
>

I have been trying for 2.5 years to do the same... since before ReturnPath
was handling it, while ReturnPath was handling it (and got some RP
engineers I know involved, who were also unsuccessful), and again after RP
was done handling it.

I finally punted and set up filter bypass rules and special forwarding from
the old reporting address to the new.

LMK if you ever figure out how to make it happen.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SNDS in Red after List Clean up

[Vick Khera]

On Thu, Jun 8, 2017 at 9:03 AM, Chris Truitt  wrote:

> My question to you is what can be done to essentially educate Smart Screen
> that our content, though containing medical jargon is acceptable to the end
> user and to place it into the inbox, and how many days of clean sending
> will it take to see changes in SNDS?
>

Get people to add your sending address to their address book. That is the
one big magic bullet for Hotmail/Outlook/Live mail.

SNDS reports daily stats, so today's numbers really have nothing to do with
yesterday's.

Run your messages through a service like Litmus and see what they have to
say about your content and who might be filtering it and why.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] dkim signature failures sendmail/opendkim

[Vick Khera]

On Fri, May 26, 2017 at 11:00 AM, Carl Byington 
wrote:

> Any ideas for debugging this?
>

Do your messages have non-ascii in them? If so, be sure to QP encode them,
otherwise some intermediate transit relays may muck up the signatures by
rewriting them.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] International Fix-Your-SPF day

[Vick Khera]

On Tue, May 16, 2017 at 12:11 PM, D'Arcy Cain  wrote:

> Heck, we may not even need to do it.  Enough coverage and the threat may
> get a bunch of them fixed anyway.
>

hahahaha. you are very optimistic.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] help with yahoo fbl

[Vick Khera]

On Tue, May 2, 2017 at 11:37 AM, Peer Heinlein <
p.heinl...@heinlein-support.de> wrote:

> I never received any feedbacks or complaints from Yahoo. I requested a
> FBL loop several times during the last few month.
>

My FBL still works, just goes to an address I'd like to retire. It was set
up so long ago before we knew better than having FBL reports go to our main
domain instead of a dedicated sub-domain...

I suspect requests are being caught up in the chaos from the merger with
AOL/Verizon.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] help with yahoo fbl

[Vick Khera]

Off and on for the last two years or so, I've been trying to get my FBL
with yahoo updated to a new reporting address. It is becoming more urgent
now as we are changing the mail service which is currently just forwarding
the old reporting address internally.

At first I worked directly with ReturnPath who was running it at the time,
and they were unable to fix it. Then I tried the yahoo fbl online forms to
request changes, but again it was not updated. I tried again recently using
their online forms, but got zero feedback or results.  My best guess is
that my FBL is so old that it pre-dates the current system entirely (based
mostly on the difficulties RP had when they were managing it).

Is there anyone with whom I can speak that may have a chance of changing
it? Or will it just get subsumed by the AOL reporting soon?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] QQ form submission question

[Vick Khera]

My experience with qq in any way shape or form trying to contact their
postmaster is black hole. But I haven't tried in at least a year.
___
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

[Vick Khera]

On Thu, Mar 16, 2017 at 8:38 PM, John Levine  wrote:

> So just out of nosiness, when's the last time Something Bad Happened
> in real life due to sending credit card info by e-mail?
>

One of my buddies does design and consulting of networks for industries
regulated by federal statutes. By refusing certain content at the gateway
it never enters their control so they are not responsible for securing it.
If they can detect the attachment is potentially in the class of "needs to
be securely handled" they can avoid the problems of having sensitive
information left in email where it is not considered securely stored. It is
not just about the transmission over the internet.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Anyone from Proofpoint on the list?

[Vick Khera]

On Fri, Feb 24, 2017 at 11:57 AM, Laura Atkins 
wrote:

> Most mail-type folks (including the ProofPoint postmaster) were at a
> conference this week. Try mailing postmaster, they’re responsive to that
> mail.
>

I've rarely gotten response from Proofpoint, but usually the blocks are
cleared anyway.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Are there any TimeWarner (rr.com) people on list?

[Vick Khera]

On Tue, Jan 31, 2017 at 10:32 PM, Mark Dale  wrote:

> Hi,
>
> We're suddenly seeing a ton of NDRs for "Too many concurrent
> connections" when discussion-lists try to send email to "rr.com"
> addresses. Our MTA limit is for 2 concurrent connections.
>
>
I sat on a panel discussion a few M3AAWG meetings ago, and their
representative said that's how they tell you to adjust your limits. This is
the feedback they want to give you. They were not explicit on what their
general limits are or how they decide to adjust them per sender, obviously.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] AOL Service unavailable on connect

[Vick Khera]

On Mon, Jan 23, 2017 at 10:29 AM, Derek Diget 
wrote:

> Anyone else seeing connection issues to AOL?  Saturday morning (EST) we
> started getting
>
> 421 mtaig-maa03.mx.aol.com Service unavailable - try again later
>
> on the initial connection where the responding AOL hostname varies.
>
>
I see that from our ticketing system (auto-ack of new ticket). Our bulk
senders don't have any AOL backlog.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google SPF checking intermediate server

[Vick Khera]

On Tue, Jan 10, 2017 at 1:17 PM, Brandon Long  wrote:

> Also, if your mail flow MX to google goes through multiple IPS, you should
> list them all as internal gateways.
>

Does it make sense to just remove my private relay server from the list of
gateways? It never receives and forwards mail from the public, only from
our LAN.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Google SPF checking intermediate server

[Vick Khera]

I have mail that comes from our in-house Jira which goes from the Jira
instance on 192.168.7.25 to a local postfix instance. This instance
forwards all mail to a public facing postfix using a public IP provided by
the firewall via NAT, 74.92.149.60, which ultimately delivers the mail to
gmail. The IP of the public facing postfix is 199.83.96.14 and that is
listed within our SPF record.

Google is claiming the messages are unauthenticated, with this:

Authentication-Results: mx.google.com;
   spf=softfail (google.com: domain of transitioning y...@kcilink.com
does not designate 74.92.149.60 as permitted sender) smtp.mailfrom=
y...@kcilink.com

Even though clearly it is receiving the message from the server at
199.83.96.14:

Received: from lorax.kcilink.com (lorax.kcilink.com. [199.83.96.14])
by mx.google.com with ESMTPS id
r63si41213060qkb.179.2017.01.06.15.29.00
for 
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 06 Jan 2017 15:29:00 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning y...@kcilink.com
does not designate 74.92.149.60 as permitted sender) client-ip=74.92.149.60;
Authentication-Results: mx.google.com;
   spf=softfail (google.com: domain of transitioning y...@kcilink.com
does not designate 74.92.149.60 as permitted sender) smtp.mailfrom=
y...@kcilink.com
Received: from projects.int.kcilink.com (
74-92-149-60.static.comcast.kcilink.com [74.92.149.60]) by lorax.kcilink.com
(Postfix) with ESMTP id 440A219BF30 for ; Fri,
  6 Jan 2017 18:29:00 -0500 (EST)
Received: from projects.int.kcilink.com (projects.int.kcilink.com
[192.168.7.25]) by projects.int.kcilink.com (Postfix) with ESMTP id
28A6C2B2BF for ; Fri,
  6 Jan 2017 18:29:00 -0500 (EST)

Curiously, only sometimes does the gmail interface show the big red
"unauthenticated" question mark, even though every message I examine has
this same soft fail.

Why would gmail be checking the next-hop IP? It is part of my internal
infrastructure even though it has a routable IP. Am I misunderstanding
something of how this should be configured? Am I supposed to list all
intermediate IPs in my SPF too? I don't see that recommended anywhere.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Vick Khera]

On Sat, Jan 7, 2017 at 7:04 PM, Michelle Sullivan 
wrote:

> Therefore, I'm not even going to discuss the issue of 'problem solved
>> within minutes' issue at this point as you will note the above covers where
>> this is likely to be true, as apposed to those (who we get on a regular
>> basis) who claim to have 'fixed the issue' whilst we are noting spam still
>> emanating from the host(s)... (don't know if they just cluelessly fail to
>> flush the queued spam to /dev/null or whether they are just saying anything
>> to get delisted - I suspect both in many cases.)
>>
>> Next!?
>>
>
> Still waiting Vick...  What else needs to be solved?
>

I said what I needed to say, and you dismissed it out of hand. I see no
point in continuing to discuss this topic with you, considering how
abrasive you are.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Vick Khera]

On Fri, Jan 6, 2017 at 9:01 PM, Noel Butler  wrote:

> People go away, businesses shutdown over weekends etc, so you need time
> for them to find out they have a problem and resolve it.
>
>
That makes sense if you get no response from the affected sender. However,
if they are able to show you how the problem was fixed then what's the
purpose? Especially when you already have reputation data for that sender
over long time periods and can see whether they should be trusted or not.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Vick Khera]

On Thu, Jan 5, 2017 at 7:07 PM, Michelle Sullivan 
wrote:

> So taking your blatant attack literally which I was under the impression
> was against list policy, lets instead attempt to be constructive and have a
> clam discussion...  "SORBS does not seem interested in solving problems,
> but in punishing people." quite the opposite is in fact true, but often is
> could be seen this way, what would *YOU* suggest we do instead, and what do
> *YOU* perceive as "not interested in solving problems" and what do *YOU*
> perceive as "punishment"... and I will answer why we can/cannot implement
> such policies/changes... you never know we might come up with changes that
> work better for everyone, though having been around this very attack many
> times in the past, I'll be upfront and honest... I highly doubt it.
>

So if you're goal is to solve problems, then what's the point of having a
minimum 48 hour block when the problem is solved at the origin within
minutes? That's just punitive and not constructive.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SORBS help

[Vick Khera]

On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest  wrote:

> If someone from SORBS could contact me off list or on list I don't care,
> either way we need to get this block removed.
>

How much trouble is it causing you? I find it doesn't cause all that much
trouble in terms of mail being blocked. SORBS does not seem interested in
solving problems, but in punishing people.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamcop: 'this is not spam' feedback form broken?

[Vick Khera]

On Mon, Jan 2, 2017 at 5:36 AM, Benoit Panizzon 
wrote:

> 1: Mark those submissions to spamcop to be not spam, to prevent spamcop
>blocking the ip used to submit those reports.
> 2: Send a note to the reporter to get in contact with us to clear the
>issue, maybe the contact data @ RIPE is wrong.
>

It is my experience with Spamcop that whatever you may say, it doesn't
matter to them as long as the recipient said it was spam. My sense is that
there is no exception to what can be reported.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GMail Reputation

[Vick Khera]

On Tue, Dec 20, 2016 at 11:57 AM, Paul Witting
 wrote:
> Is this the tag you are referring to, if so, what are the other tags?

https://support.google.com/mail/answer/6254652?hl=en

That's the feedback loop. It is based on tags provided in a
"Feedback-ID" header, which you DKIM sign.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GMail Reputation

[Vick Khera]

On Mon, Dec 19, 2016 at 1:27 PM, Paul Witting
 wrote:
> Since discovering the issue we’ve been going over our system with a fine
> toothed comb, We generally have SPF and DKIM deployed, and based on Google’s
> recommendations, DMARC, as well as updating mail headers to be what seems to
> be in line with Google’s recommendations. We’ve also turned our eyes on what
> is being sent, and found some minor issues where a small volume of unwanted

You need 100% DKIM coverage if you want to get mail to inbox at gmail.
Perhaps rotate out the signing key and make sure *only* your
transactional mail uses that one specific identifier.

I'll suggest doing some some subject line rewording and possibly
re-word the content as well. Since you're sending receipts, that may
be a little tricky.

How many IPs are you sending through (does anyone else share them),
and what is your volume? Maybe you can segregate the various types of
mail to see if one or the other is causing problems. Do you get any
reports from the gmail FBL? You should use one of the 4 tags they
allow to identify the type of mail, if that provides clues.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Multivariate Subject testing influences Gmail's filters?

[Vick Khera]

On Tue, Dec 13, 2016 at 7:26 AM, Marco Franceschetti via mailop <
mailop@mailop.org> wrote:

> Or, could the new style approach be to blame?
>

Seems like your client should test the same subject line with and without
emoji and find out.

We have not studied yet the effect emoji in subject lines to message
response rates.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Mysterious DKIM failure.

[Vick Khera]

On Mon, Dec 12, 2016 at 3:23 PM, Steve Atkins  wrote:

>o Use quoted-printable for all body text
>

This one bit me pretty well with AOL a few years ago -- rewriting of 8-bit
to 7-bit. The only solution was to QP encode everything.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo blacklist removal

[Vick Khera]

On Wed, Nov 16, 2016 at 3:53 PM, David Sgro, Dataspindle
 wrote:
> - A company called ProofPoint had my block along with several other 
> neighboring /20's listed due to a SPAM incident that happened in 2013. Spoke 
> to them. Very nice people. They understood and cleared it up right away. 
> Yahoo uses ProofPoint to help determine email reputation.

Proofpoint provides reputation to others too, most notably icloud.com.
You probably want to check *every* known reputation source. I'm sure
you're listed elsewhere if it was that bad.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Listbomb issue

[Vick Khera]

On Wed, Oct 19, 2016 at 3:35 PM, Brett Schenker  wrote:
> We're currently looking to implement a combination of preventions with the
> leading idea being:
> honeypot on sign up pages + IP intelligence + email address intelligence +
> coi
>
> The idea being the honeypot will stop some bots, the IP monitoring will look
> for numerous sign ups within a short periond of time (which we currently do
> for credit cards) and then also look for email addresses being signed up
> acorss clients in a short period of time.

My thought on this is that *I* cannot detect the rate of signups as
well as reputation services can. To this end, I use the following
algorithm on our list signup forms. The beauty of it is that you
really only get to see the CAPTCHA if you are a trouble maker.
Normally you will never get presented with it, so it looks like
business as usual to everyone else. I do this test both when
displaying the form and when processing the form, because bots never
fetch the form itself, and humans don't want to fail a captcha they
never saw in the first place.

1) Is the remote IP listed in CBL? Yes -> force CAPTCHA
2) Is the remote IP listed in CleanTalk.org/blacklists?  Yes -> force CAPTCHA
3) Is the remote IP listed in minFraud open proxies? Yes -> force CAPTCHA

Then proceed with the normal signup form, which in our case is always
COI for all customers. I do the tests in the above order, and short
circuit once I have a positive match. Each of the three services
catches about ⅓ of the bad actors, amazingly enough. I do the queries
in the order of cost to me, so as to minimize how much I have to
spend. :-)  I also cache the results.

A couple of my customers have asked for 100% CAPTCHA because they
wanted a 100% block of the bots. This mechanism I use gets close to
75% of them based on my testing two months ago.

If you're the lucky guy who is first hit when the bots get a new IP,
you'll be out of luck. But, if you're lower down their list, then
likely these guys will have detected that IP by the time they get to
you. minFraud will even notify you if they subsequently detect bot
activity on an IP you queried, which is nice sometimes to go back and
clean up.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vick Khera]

On Fri, Aug 12, 2016 at 7:12 PM, Tim Starr  wrote:
> The only benefit I can see from sending the exact same message from
> somewhere else would be to drive recipients to the same payload link, which
> suggests another possible way to stop this from paying off after detection:
> Make it so that all content links get turned into redirects you control, and
> can break upon request

You're not assuming the person doing the re-send is out for some form
of revenge to ruin the other person's reputation...

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Dealing with a DKIM replay attack and yahoo's use of DKIM domains for FBL reports

[Vick Khera]

On Fri, Aug 12, 2016 at 12:34 PM, Steve Atkins  wrote:
> You're vouching for / accepting responsibility for every mail you sign.
> If your users are bad actors - as they are in this case - you're accepting
> responsibility for that.

So if I took any random message that I came upon signed by you and
spammed the world with it, you take responsibility for that?

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamcop blows a fuse.

[Vick Khera]

On Tue, Aug 2, 2016 at 7:22 PM, Michael Rathbun  wrote:
> This server sends a spam feed to Spamcop (it's Nadine, in fact).
>
> So, of course, the IP is now listed on Spamcop.

No good deed...

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] automated looking mailchimp opt-ins (confused by)

[Vick Khera]

On Thu, Jun 30, 2016 at 12:04 PM, Michael Wise via mailop  wrote:

> They're BURYING the target in thousands of confirmation requests.
>

In some cases we're seeing the recipient address repeatedly submitted, and
it is known to not exist, ie we get a DNE bounce.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] automated looking mailchimp opt-ins (confused by)

[Vick Khera]

On Wed, Jun 29, 2016 at 9:46 PM, Mark Jeftovic  wrote:

> I look at the complaint data, it's all weird looking signups, this time
> all from:
>
> aol.com
>
>
> netscape.net
>
>
> verizon.net
>
>
>
> and the "First Name Field" in all of them are like this:
>
> 5773fb91d07ad
>
> Again, looks automated or bot-like, or maybe it's some list management
> software?
>
> This is what I'm confused about, namely WHAT'S THE POINT?
>

I've seen these coming for a while now for several of our customer's signup
forms. Recently there was a big uptick on the volume and we had to
implement various robot defenses to block these. If you collect any other
data, they will all have an incrementing hex number like that in them as
well.

For some customers, enabling reCAPTCHA was the solution because of the
volume of bogus signups. For everyone else we opportunistically require
reCAPTCHA if the submitting IP is on either CBL or minFraud's proxy list.
This latter mechanism matches just shy of 75% of the fake signups
exhibiting this pattern historically. Some IP's we observe become "bad"
after the fact, so I suspect the actual block rate to be a bit lower.

Now the most curious part is that a fair number of these signups actually
confirm by following the confirmation link. I know some percentage of those
are automated scanning by our friends at Barracuda and other such services.

I asked this question to quite a few people at M3AAWG a couple of weeks
ago, and the most plausible answer I got was from Elizabeth at yahoo: the
scammers are trying to make their inboxes look "real" so they can game the
"this is not spam" feature.  She says it is fairly easy for them to ignore
the TINS if the entire mailbox from where it came is just spam because they
know it is someone trying to game delivery for their own spam. However, if
there are other non-spam messages in there it is harder for them to
determine automatically (ie, without human looking at the mail which they
are not allowed to do) if the inbox is "real".

Michael's theory that it is a harassment technique for the recipient is
also strong. I've had it happen to me recently at a small scale (someone
signed me up for *every* debian mailing list). The guess that they're
coming from western europe is in my case incorrect. Spot checking the IPs
they are from *everywhere* including large cable providers in the US.
Clearly these are bots and/or open proxies.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] looking for contact at / info about comcast fbl

[Vick Khera]

On Wed, Jun 29, 2016 at 12:50 PM, Miles Fidelman  wrote:

> Is there anybody here from Comcast mail operations who can provide some
> guidance as to how to identify the originator of an abuse report, so I can
> remove them from the list(s)?
>

If you VERP the SMTP envelope sender address, that should help you out. It
comes back embedded in the report as "Original-Mail-From:"
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Vick Khera]

On Fri, Jun 10, 2016 at 2:18 PM, Laura Atkins 
wrote:

> You demonstrated the need for a flag day when you stated that the ESPs
> need to give the ISPs “a hint” that things are changing. Expecting every
> ESP to contact every ISP is ridiculous.
>

I don't have to contact anyone. I just add the hint. If they use it, great
if not who cares -- everything continues to work as it does today. 100%
backward compatible.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Vick Khera]

On Fri, Jun 10, 2016 at 12:17 PM, Laura Atkins 
wrote:

> The beauty of the proposal is that you can with some cooperation of the
> mail user agent convert the two-click unsub into a one-click.
>
>
> And the failure of this proposal is that it requires the MUA to change
> current behavior without a clear benefit to doing so. It also means there
> can be no partial adoption or roll out. ESPs and ISPs need to coordinate on
> a flag day for the new changes. All of this makes it a hard sell for a lot
> of people.
>

I'm not following why there has to be a flag day for the change. I as the
ESP give you the ISP a hint to make something work "better" for the end
user. If you don't act on the hint, the unsubscribe is still possible and
works just fine with a second click. If I don't give you a hint, then the
same happens. If you do follow my hint, then the user has an optimized
experience of one-click unsubscribe. The other benefit is that scanners
will not cause the unsubscribe.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] "One-Click" List-Unsubscribe URIs

[Vick Khera]

On Fri, Jun 10, 2016 at 11:23 AM, Laura Atkins 
wrote:

> Also in this case, there is a significant chance that the proposal will
> result in sub-optimal or harmful results. It is a fact that there are
> appliances and filters out there that follow every link in an email.
> Implementing a protocol where a link being followed means a user is
> unsubscribed immediately will result in people being unsubscribed. I
> understand this proposal makes whatever is automatically clicking the link
> append a magic token to the URL, in an effort to stop this. I think that
> makes the proposal overly complex and fragile.
>
>
I kind of like Tobias' proposal (not just because we've thrown back a lot
of beers...)

The way I interpret it is that naive and current filters will just follow
the URL as-is. The anchor will just be mostly ignored by the landing page,
where you would normally then have to click a "confirm" button on that
page. If, however, your ISP (or mail user agent) detects this magick
one-click anchor and rewrites it for the user to click with the params
appended, then it becomes converted into a one-click unsubscribe by the
landing page. The key is that the automated scanning stuff will (and
should) not do any rewriting. If some filter scanner decides to do the
rewrite then all bets are off, and they should be punched in the face :)

The beauty of the proposal is that you can with some cooperation of the
mail user agent convert the two-click unsub into a one-click.

I also am not 100% in agreement that "GET" for HTTP means no altering of
state. I think that's a recent convention coming over from REST based APIs.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Vick Khera]

On Fri, May 27, 2016 at 1:57 PM, Michael Peddemors 
wrote:

> Putting your business card in a bowl to win a prize is definitely not
> giving permission to get on a mailing list ;)
>

I for one pretty much expect that I'll be put on a list. I'm sure a lot of
other folk do, too.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Excluding Message-ID from DKIM Signature

[Vick Khera]

On Fri, May 27, 2016 at 11:26 AM, Joel Beckham  wrote:

> Thanks, Vick. I'm curious, what initially lead you to exclude the
> message-id from your signature?
>

We sign in our application, and let the MTA throw in the Message-ID. Always
did it that way. I also let the MTA insert the required Date header :)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Vick Khera]

On Wed, May 25, 2016 at 6:04 PM, Al Iverson 
wrote:

> I've heard John Levine propose the "hidden link to catch scanning
> robots" solution but I've never heard of an email system implementing
>

I'm running through my head how that would work, and makes for some very
complicated state transition diagrams to go from "signup requested" to
"confirmed". What if they scan in parallel and the timing works out they
poked them in the opposite order, etc. I see a few new states and many
transitions, and some timeout based events. Not pretty.


> it. Similarly, senders have often suggested that spamtrap systems
> shouldn't follow links. (Security systems, sure, but don't do that
> with spamtrap addresses.) And today I heard it suggested that it would
> be wiser to have COI have a second click (probably an HTTP POST-based
>

What if the confirmation email button itself was a POST form rather than
just a GET to a page? Are scanning systems following POSTs too?


>
> button) on the landing web page, to prevent security systems from
> erroneously completing COI confirm steps. All good stuff, but it
>

I don't think you're going to get much buy-in for requiring so many clicks
to get activated. I know we already lose customer just for requiring COI.
Making the COI be more work for the subscriber will just make people go
elsewhere faster.


> doesn't sound as though any of it has been widely broadcasted as a
> best practice or requirement.
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Vick Khera]

In the confirmation message, there is a link (which looks like a button) to
click to confirm you want to be on the list. That link is being followed
and the addresses activated. My working theory is that some mail filtering
software is fetching the URLs it sees.

On Wed, May 25, 2016 at 5:47 PM, Michael Wise <michael.w...@microsoft.com>
wrote:

> When you say, “Confirmation Clicks”, do you mean on a link provided via
> email, or a confirmation button of a web form?
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
> <http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Vick
> Khera
> *Sent:* Wednesday, May 25, 2016 2:14 PM
> *To:* Erwin Harte <eha...@barracuda.com>
> *Cc:* mailop@mailop.org
> *Subject:* Re: [mailop] signup form abuse
>
>
>
>
>
> On Wed, May 25, 2016 at 3:02 PM, Erwin Harte <eha...@barracuda.com> wrote:
>
> I did a spot check of a recent attack. The email address was
> jabradb...@kanawhascales.com and it got signed up to 12 lists during May
> 17 and 18. Amazingly, whoever is on the other end of that address clicked
> to confirm every one of those confirmation messages. All confirmation
> clicks appear to come from a netblock owned by Barracuda Networks... Hmm...
>
> Which netblock was that?
>
>
> 64.235.144.0/20
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f64.235.144.0%2f20=01%7c01%7cmichael.wise%40microsoft.com%7c06de737a7a6840fa5ca908d384e4c158%7c72f988bf86f141af91ab2d7cd011db47%7c1=vzNvba4az0YFZEVEU7BPcnFpDG%2bJuzhiwZGWOzYem9o%3d>
>
>
>
> Specifically: 64.235.154.109,
> 64.235.153.2, 64.235.150.252, 64.235.153.10, 64.235.154.105, 64.235.154.109
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Vick Khera]

On Wed, May 25, 2016 at 3:02 PM, Erwin Harte  wrote:

> I did a spot check of a recent attack. The email address was
> jabradb...@kanawhascales.com and it got signed up to 12 lists during May
> 17 and 18. Amazingly, whoever is on the other end of that address clicked
> to confirm every one of those confirmation messages. All confirmation
> clicks appear to come from a netblock owned by Barracuda Networks... Hmm...
>
> Which netblock was that?
>

64.235.144.0/20

Specifically: 64.235.154.109,
64.235.153.2, 64.235.150.252, 64.235.153.10, 64.235.154.105, 64.235.154.109
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Vick Khera]

On Tue, May 24, 2016 at 2:18 PM, Michael Wise 
wrote:

> Are these IP addresses on CBL?
>

I did a spot check of a recent attack. The email address was
jabradb...@kanawhascales.com and it got signed up to 12 lists during May 17
and 18. Amazingly, whoever is on the other end of that address clicked to
confirm every one of those confirmation messages. All confirmation clicks
appear to come from a netblock owned by Barracuda Networks... Hmm...

Each signup request came from a different IP address. 5 were on CBL (as of
right now) and 7 were not. In case anyone is interested, I also checked
them against MinFraud from Maxmind. Of the 7 CBL did not detect, it said 5
of them were high risk of being fraudulent source. Between the two, only 2
would get through.

If anyone is interested, these are the IPs used for the signup form
submission:

 107.184.168.161 - CBL, MF
 67.208.149.17 - CBL, MF "low"
 116.212.155.5 -
 73.4.8.181 - MF
 76.74.237.61 - CBL, MF
 96.245.176.53 - MF
 50.196.42.201 - MF
 32.213.237.56 -
 50.192.254.21 - MF
 76.74.237.61 - CBL, MF
 74.196.162.37 - MF
 76.74.237.61 - CBL, MF

I am definitely going to start checking CBL and MinFraud for these forms.
Thanks for the tip.

Are these addresses in a larger pool, like a Nigerian coffee shop?
>

Doesn't seem like it. I spot checked a couple and they look like ISPs in
the states.


> At some point, you should have a CAPTCHA, and also possibly a list of
> ranges of known bad actors.
>
>
>

We do have CAPTCHA available. I think it is time to start pushing it on the
customers a little harder...
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] signup form abuse

[Vick Khera]

On Wed, May 25, 2016 at 10:45 AM, Matthew Black 
wrote:

> Are your customers using confirmed opt-in mailing lists? If not, they
> should not be running mailing lists.
>
>
Yes, the only effect is to send a confirmation message, which is quite
generic and at most contains the customer's logo and name of the list, to
the victim.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] signup form abuse

[Vick Khera]

As an ESP, we host mailing list signup forms for many customers. Of late,
it appears they have been getting pounded on with fraudulent signups for
real addresses. Sometimes the people confirm by clicking the confirmation
link in the message and we are left scratching our heads as to why they
would do that. Mostly they get ignored and sometimes they come back as spam
complaints.

One opinion I got regarding this was that people were using bots to sign up
to newsletter lists other bot-driven email addresses at gmail, yahoo, etc.,
to make those mailboxes look more real before they became "weaponized" for
use in sending junk. That does not seem to be entirely what is happening
here...

Today we got a set of complaints for what appears to be a personal email
address at a reasonably sized ISP. The complaint clearly identified the
messages as a signup confirmation message and chastised us for not having
the form protected by a CAPTCHA. Of course, they blocked some of our IPs
for good measure :( They characterized it as a DDoS.

What are the folks on this fine list doing about this kind of abuse? We do
have ability to turn on CAPTCHA for our customers, but often they have
nicely integrated the signup forms into their own web sites and making it
work for those is pretty complicated. If I enabled CAPTCHA naively, the
subscribers would have to click the submit form twice and then click the
confirm on the email. The UX for that sucks, but such is the cost of
allowing jerks on the internet...

Rate limiting doesn't seem to be useful since the forms are being submitted
at low rates and from a wide number of IP addresses.

I look forward to hearing what others here are doing.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Vick Khera]

On Thu, May 12, 2016 at 4:52 PM, Jeffry Dwight 
wrote:

> I can't figure out how to tell the
> difference between a "real" untrusted root and a cert issued by some
> admin's
> personal CA.
>

Because there is none.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Vick Khera]

On Thu, May 12, 2016 at 1:24 PM, Jeffry Dwight 
wrote:

> So, what do you all do? Right now, I'm verifying the cert and its chain,
> but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but
> rather defeats the purpose of knowing we're connecting to the proper
> server.
>
> Second question: How do you handle self-signed certs? Do you just ignore
> cases
> where the root isn't a trusted root?
>

Don't bother verifying the certificate host names. You've identified many
issues already.

Just use it for the opportunistic encryption unless you're dealing with a
lot of high-risk mail like banks. From what I gather, they only do
certificate checks on specified destinations (ie, other banks they know to
have certificates set up correctly to match) and in those cases they fail
if the cert does not match. For general consumer mail there is no way to do
this.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo Mail Servers having new issues?

[Vick Khera]

On Tue, May 10, 2016 at 10:11 AM, Vladimir Dubrovin via mailop <
mailop@mailop.org> wrote:

> We observe this behavior periodically and it seems the number of lost
> connections still grows.
>
> < *@yahoo.com
>
> >: delivery temporarily suspended: lost connection
> with
> mta5.am0.yahoodns.net
>
> [98.136.217.203] while sending RCPT TO
>
> We've contacted Yahoo support for multipe times and we've got a reply
> this issue is fixed, but actually it doesn't.
>
> Does anyone experience same problems with Yahoo?
>

I see nothing like that error message last couple of days. We use TLS
opportunistically as well.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Truncate DNSBL

[Vick Khera]

My monitoring service just notified me that an IP from my shared general
outbound pool is listed on the Truncate DNSBL. This is really the first
I've heard of this list. From what I read on their web pages, they claim
that an IP is only listed if > 95% of the mail they detect is spam. I
personally find this quite improbable coming from my systems.

Overall, the messages in that pool are statistically identical across IPs
as everything is round-robin delivered. I'm measuring about 0.02% spam
complaint rate, Hotmail SNDS is reporting "green", AOL postmaster says the
stream is clean. There is nothing different about these numbers for a very
long time.

The IP in question is 199.83.97.5.

Questions:

1) is this list used to cover a consequential number of inboxes?
2) is this list true to their self-proclaimed description of 95% spam
required?
2a) if so, how would the data from the FBLs and from hotmail and AOL be so
different?

Thanks!
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes

[Vick Khera]

On Wed, Mar 23, 2016 at 11:15 AM, Steve Atkins <st...@blighty.com> wrote:

>
> > On Mar 22, 2016, at 9:35 PM, <frnk...@iname.com> <frnk...@iname.com>
> wrote:
> >
> > Are you taking that approach because the workaround is less than ideal?
> Otherwise the current “workaround” could be the new standard.
>
> The workaround is terrible and breaks basic email functionality.
>

What's so terrible about setting the visible From address to something you
control, and setting reply-to to the original address? I thought that was
the acceptable workaround, at least as discussed at sessions at M3AAWG.


>
> It's likely that ARC will become the new - much better - workaround
> eventually, modulo the inevitable deployment issues. http://arc-spec.org
>
> Cheers,
>   Steve
>
> >
> > Frank
> >
> > From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Vick Khera
> > Sent: Tuesday, March 22, 2016 8:54 PM
> > To: mailop <mailop@mailop.org>
> > Subject: Re: [mailop] Yahoo DMARC changes
> >
> >
> > On Tue, Mar 22, 2016 at 7:52 PM, Steve Atkins <st...@blighty.com> wrote:
> >> So if you've been doing anything special with forwarders or mailing
> lists for yahoo.com
> >>
> >> it's probably a good idea to do it for their other domains too in the
> next few days.
> >
> > When Y! first set up p=reject on their main domain, we built our
> system's evasive maneuvers to work around it to be domain independent. Our
> systems do a DNS lookup for the DMARC record and if they find p=reject or
> p=quarantine and we do not sign using their From address in the domain, we
> automatically enable the workarounds to avoid falling in the trap. No
> manual configuration necessary.
> >
> > ___
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes

[Vick Khera]

On Tue, Mar 22, 2016 at 10:36 PM, Luke Martinez <luke.marti...@sendgrid.com>
wrote:

> That's interesting. From an ESP's prospective, deciding to use a different
> domain in the from address is simply not an acceptable option. That being
> said, I wish we had a good way to tell senders that they are heading for
> trouble. You would be surprised how many senders don't know that there is a
> part of their infrastructure that is using these domains in their from
> address.
>

We are a small ESP, too. Our evasive maneuvers consist of setting the
visible From address to one from our own domain, and setting reply-to to
the original customer's address. This works just splendidly. We do notify
the customers and so far they've tended to switch to using their own
domains. The notification is all automatic in our UI.

I suppose that's harder to do when most of your customers are accessing
your service via an API.


>
> On Tue, Mar 22, 2016 at 7:54 PM, Vick Khera <vi...@khera.org> wrote:
>
>>
>> On Tue, Mar 22, 2016 at 7:52 PM, Steve Atkins <st...@blighty.com> wrote:
>>
>>> So if you've been doing anything special with forwarders or mailing
>>> lists for yahoo.com
>>>
>>> it's probably a good idea to do it for their other domains too in the
>>> next few days.
>>>
>>
>> When Y! first set up p=reject on their main domain, we built our system's
>> evasive maneuvers to work around it to be domain independent. Our systems
>> do a DNS lookup for the DMARC record and if they find p=reject or
>> p=quarantine and we do not sign using their From address in the domain, we
>> automatically enable the workarounds to avoid falling in the trap. No
>> manual configuration necessary.
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>>
>>
>
>
> --
>
> Luke Martinez
> SendGrid Deliverability Consultant
> 520.400.5693
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Email issue with Synacor?

[Vick Khera]

On Wed, Mar 16, 2016 at 1:23 PM, Frank Bulk  wrote:

> Anyone else seeing the same?
>

Yes, for some of it. It looks like more is going through than not going
through.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Google DNS Servers not returning results for Hotmail today?

[Vick Khera]

On Mon, Mar 7, 2016 at 6:00 PM, Carl Byington  wrote:

> Yes, arin.net
>
> failed to renew the dnssec signatures on 65.in-addr.arpa.
> They have expired, and anyone behind a dnssec enforcing resolver can no
> longer see ptr records in that tree.
>

Looks to be corrected now. It resolves for both my own recursive resolver
which enforces DNSSEC as well as 8.8.8.8.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop