Re: [mailop] DMARC forensic reports

[Gil Bahat via mailop]

I believe Tim draegan from DMARCian would probably have all of them covered
in between his clients and so will Agari and Returnpath. They might be
willing to share.

On Jun 8, 2017 21:24, "Laura Atkins"  wrote:

Thank you to everyone who responded!


On Jun 8, 2017, at 10:33 AM, John Levine  wrote:

In article  you
write:

Is there a way to find out / determine who is sending DMARC forensic
reports?


Other than sending broken DMARC and seeing who reports back (as noted,
mailing lists are a good start) I'm not aware of any.


That’s what I thought, but wasn’t sure.

If people want, I can make a summary of the addresses that have sent
them to me and we can swap them around.  I have about 62000 reports.


Sounds like work. But if the list gets generated, I’ll take a copy :)

laura

-- 
Having an Email Crisis?  800 823-9674

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741

Email Delivery Blog: http://wordtothewise.com/blog







___
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

[mailop] Anyone from GoDaddy?

[Gil Bahat via mailop]

Hi,

I am trying to report a phishing incident (someone spoofing docusign with a
cousin domain docusgn.com, malicious link also hosted on godaddy) and your
web interface fails to accept the report. please contact me off-list.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Anyone from proofpoint on the list?

[Gil Bahat via mailop]

One of my clients experiences a mutual drop from proofpoint (both sending
to proofpoint and receiving from proofpoint to gapps). Please contact me
off-list.

Regards,

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

Re: [mailop] Naver and Hanmail assistance?

[Gil Bahat via mailop]

Unless you have physical presence in korea, KISA will not admit you. Even
if you do, there are apparently legal ramifications to sending spam in
korea which must be accounted for.

If that doesn't deter you, you can do the following:

1. Create the most encompassing yet still valid SPF record for your IP
space. publish that under DomainA.tld
2. Have another SPF record published for DomainB.tld
3. Admit DomainA.tld to KISA
4. When sending to korean recipients, send from the DomainA envelope. When
sending to non-korean recipients, send from the DomainB envelope.

as for daum, looking at mailop archives, here's my posting as of about 1.5
years ago:

"FWIW I managed to get a speedy reply by appealing to them directly at
http://cs.daum.net. you will need an @daum.net or @hanmail.net account,
they are free to register although a few hurdles need to be gotten past
(e.g. a korean captcha which I fulfilled using google virtual korean
keyboard). block has been removed in less than 24 hours after approaching
them this way.

Gil"


On Mon, Jan 30, 2017 at 9:07 PM, Zack Aab  wrote:

> I had good luck by subscribing to naver and opening a ticket. You may need
>> to pass a Korean captcha, which you can do by redrawing characters in any
>> draw-based input method
>
>
> Thanks for the response!
>
> I did submit a ticket with Naver, and the reply I got was essentially "get
> on KISA" which is something we're having separate issues with because of
> their SPF policy: to whitelist, KISA requires the SPF record to have no
> include statements and be un-CIDR'd, which makes our record invalid due to
> length.
> My ticket with Hanmail didn't get past the robot/form reply stage.
>
> Any input is appreciated!
>
>
> *Zack Aab | *Deliverability Strategist
> M: 706.870.1061
> *Inbox Pros | *678.214.3739
> 1995 North Park Place I Suite 200 | Atlanta, GA 30339
>
> [image: Reply monitoring image]
> <https://inboxpros.sigstr.net/uc/57bde77d825be96f3e8e5be5>
> [image: Powered by Sigstr]
> <https://inboxpros.sigstr.net/uc/57bde77d825be96f3e8e5be5/watermark>
>
> On Mon, Jan 30, 2017 at 11:32 AM, Gil Bahat  wrote:
>
>> I had good luck by subscribing to naver and opening a ticket. You may
>> need to pass a Korean captcha, which you can do by redrawing characters in
>> any draw-based input method
>>
>> On Jan 30, 2017 5:57 PM, "Zack Aab"  wrote:
>>
>>> Hi all,
>>>
>>> I'm working with a very high volume sender who sends to Korea and we're
>>> having a tough time with Hanmail and Naver.
>>> We've done all of the DNS work but are still having some trouble, so I
>>> was hoping somebody could help me with the latest requirements and/or
>>> contact information.
>>>
>>> Any info is greatly appreciated.
>>>
>>> Thanks!
>>>
>>> Zack Aab
>>>
>>> ___
>>> 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] Naver and Hanmail assistance?

[Gil Bahat via mailop]

I had good luck by subscribing to naver and opening a ticket. You may need
to pass a Korean captcha, which you can do by redrawing characters in any
draw-based input method

On Jan 30, 2017 5:57 PM, "Zack Aab"  wrote:

> Hi all,
>
> I'm working with a very high volume sender who sends to Korea and we're
> having a tough time with Hanmail and Naver.
> We've done all of the DNS work but are still having some trouble, so I was
> hoping somebody could help me with the latest requirements and/or contact
> information.
>
> Any info is greatly appreciated.
>
> Thanks!
>
> Zack Aab
>
> ___
> 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] Offtopic: How does an taiwanese IRT work / ppt.cc URL shortening

[Gil Bahat via mailop]

I would email TWNIC and ask them whether they are aware what is the right
abuse contact for HINET. it's pretty obvious that a NIC cannot conduct
investigations in registered networks, but it is likely that they do have a
valid contact.
You're right that it's silly to advertise a pointless IRT record...

Gil

On Sun, Jan 29, 2017 at 10:58 AM, Benoit Panizzon 
wrote:

> Hi all
>
> My spamtraps are being hit by chinese spam advertizing the URL on the
> shortening service ppt.cc for several day now, with an incredible rate!
>
> Source is obviously a botnet as source IP's are spread around the globe.
>
> So it's time to look into the issue and send some personal email to the
> abuse desk of the operator of this shortening service and his hoster to
> find out what they do about it and how they could help stop the abuse.
>
> In the WOT comments, I also found that they didn't remove redirection
> to malicious sites that were reported nearly two years ago. One more
> reason to get in contact with them and see what they think about
> helping the internet community by stopping such abuse.
>
> The service is hosted by taiwan based ISP hinet.net
>
> So let's find the appropriate abuse contact.
>
> inetnum:125.224.0.0 - 125.231.255.255
> netname:HINET-NET
> descr:  Data Communication Business Group,
> descr:  Chunghwa Telecom Co.,Ltd.
> descr:  No.21, Sec.1, Xinyi Rd., Taipei City
> descr:  10048, Taiwan
> country:TW
> admin-c:HN27-AP
> tech-c: HN27-AP
> mnt-by: MAINT-TW-TWNIC
> mnt-irt:IRT-TWNIC-AP
>
> Good, they have published an IRT contact handle:
>
> irt:IRT-TWNIC-AP
> address:Taipei, Taiwan, 100
> e-mail: hostmas...@twnic.net.tw
> abuse-mailbox:  hostmas...@twnic.net.tw
> admin-c:TWA2-AP
> tech-c: TWA2-AP
> auth:   # Filtered
> remarks:Please note that TWNIC is not an ISP and is not
> empowered
> remarks:to investigate complaints of network abuse.
>
> What? Did I get that right? Their IRT Contact, responsible for abuse
> complaints has a comment that they do not investigate abuse complaints?
>
> No wonder abuse from their network never ceases...
>
> I suppose no-one else had any success with contacting them about any
> abuse case.
>
> Cheers!
>
> --
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> 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

[mailop] Engine(s) used to detect suspicious attachments?

[Gil Bahat via mailop]

Hi,

Do providers document which engine(s) they're using to flag suspicious
attachments?
I am having a case where a client is forwarding attachments which are
deemed dangerous by the destination (in this particular case it's gmail but
it might as well be any other), but no engine on virustotal flags these as
suspect. I believe the repercussions for sending purported malware on
deliverability can be very bad, but I suspect that no inbound spam
filtering will prevent the problem.

thoughts/suggestions welcome.

Regards,

Gil Bahat,
Director of Online Operations,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Spamcannibal?

[Gil Bahat via mailop]

That is correct. At least from my personal perspective, the solution was to
find out if any major destination was making decisions based on this list.

After engaging that sole meaningful provider, I'm happy to report they
dropped spamcannibal. So unless someone picked it up, you can likely safely
ignore any spamcannibal listing.

The list maintainer couldn't care less about my concerns and that's his
prerogative, just like it's mine to try and convince it's few remaining
users to drop it.

On Dec 9, 2016 6:13 PM, "Al Iverson"  wrote:

Every blacklist operator has done something that has pissed somebody off at
some point. I recognize their right to exist, and tend not to judge, even
if they don't run things they way I would. Life is more pleasant and
stress-free that way.

Because even though you might say "why would you ever use that piece of
crap" about any blacklist -- and you could even be correct some of the time
-- but somebody does use it somewhere, so it exists and one has to deal
with it sometimes.

Cheers,
Al


--
Al Iverson
www.aliverson.com
(312)725-0130 <(312)%20725-0130>

On Fri, Dec 9, 2016 at 10:44 AM, Gil Bahat via mailop 
wrote:

> +1 unreasonable for an indiscriminate block on all of Amazon SES. Why
> would anyone want to use such a BL is beyond me given that there are many,
> much better alternatives.
>
> On Dec 9, 2016 5:30 PM, "Vladimir Dubrovin via mailop" 
> wrote:
>
> 25.11.2016 22:50, Al Iverson пишет:
>
> Hi Otto,
>
> Long time no talk. Hope things are going well.
>
> The Spam Cannibal maintainer is a reasonable guy. He doesn't spread
> his contact info far and wide, perhaps because he doesn't want to
> argue with spammers. So, I would feel bad about sharing his details
> publicly. But I will forward your post to him and invite him to follow
> up with you. Hope that helps.
>
>
> I really doubt it. This reasonable guys blacklisted our (Mail.Ru) front
> servers due to same reason ('Generic PTR'). Yes, we have few hundreds of
> front servers, because we host >50% of mailboxes for russian-speaking users
> so we need to count our servers somehow. If you use Spamcannibal you will
> probably have deliverability problems.
>
>
>
> Best regards,
> Al Iverson
>
> --
> Al Iversonwww.aliverson.com(312)725-0130 <(312)%20725-0130>
>
>
> On Fri, Nov 25, 2016 at 8:14 AM, Otto J. Makela   
> wrote:
>
> Sending this to a couple of secret societies, apologies if you see this twice.
>
> Is there any point in trying to contact Spamcannibal?
>
> One of our clients (we're the Finnish NREN, so an university in Finland)
> was notified via Shadowserver that a swathe of their unused IP space is
> listed on Spamcannibal:
> https://www.shadowserver.org/wiki/pmwiki.php/Services/Blacklist
>
> Since the network in question has no assigned addresses, there are no DNS
> records for it. We suspect that the netblock was momentarily snatched from
> them via BGP (or some other routing trick) and then used to send spam.
> We'd really like to know more, like get spamples or at least time stamps.
>
> When I tried to get in touch with Spamcannibal about one IP address via
> their contact form, submitting the form resulted in the glib message:
>
> xxx.xxx.xxx.xxx not eligible for removal: GENERIC PTR
>
> So, anyone know if the form went through, does someone have a contact there,
> and is there any point in doing so?
>
> --
>/* * * Otto J. Makela   * * * * * * * * * */
>   /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
>  /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
> /* * * Computers Rule 0100 01001011 * * * * * * */
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
> ___
> mailop mailing 
> listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
> --
> Vladimir Dubrovin
> [image: @Mail.Ru]
>
> ___
> 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
>
>

___
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] Spamcannibal?

[Gil Bahat via mailop]

+1 unreasonable for an indiscriminate block on all of Amazon SES. Why would
anyone want to use such a BL is beyond me given that there are many, much
better alternatives.

On Dec 9, 2016 5:30 PM, "Vladimir Dubrovin via mailop" 
wrote:

25.11.2016 22:50, Al Iverson пишет:

Hi Otto,

Long time no talk. Hope things are going well.

The Spam Cannibal maintainer is a reasonable guy. He doesn't spread
his contact info far and wide, perhaps because he doesn't want to
argue with spammers. So, I would feel bad about sharing his details
publicly. But I will forward your post to him and invite him to follow
up with you. Hope that helps.


I really doubt it. This reasonable guys blacklisted our (Mail.Ru) front
servers due to same reason ('Generic PTR'). Yes, we have few hundreds of
front servers, because we host >50% of mailboxes for russian-speaking users
so we need to count our servers somehow. If you use Spamcannibal you will
probably have deliverability problems.





Best regards,
Al Iverson

--
Al Iversonwww.aliverson.com
(312)725-0130


On Fri, Nov 25, 2016 at 8:14 AM, Otto J. Makela   
wrote:

Sending this to a couple of secret societies, apologies if you see this twice.

Is there any point in trying to contact Spamcannibal?

One of our clients (we're the Finnish NREN, so an university in Finland)
was notified via Shadowserver that a swathe of their unused IP space is
listed on Spamcannibal:
https://www.shadowserver.org/wiki/pmwiki.php/Services/Blacklist

Since the network in question has no assigned addresses, there are no DNS
records for it. We suspect that the netblock was momentarily snatched from
them via BGP (or some other routing trick) and then used to send spam.
We'd really like to know more, like get spamples or at least time stamps.

When I tried to get in touch with Spamcannibal about one IP address via
their contact form, submitting the form resulted in the glib message:

xxx.xxx.xxx.xxx not eligible for removal: GENERIC PTR

So, anyone know if the form went through, does someone have a contact there,
and is there any point in doing so?

--
   /* * * Otto J. Makela   * * * * * * * * * */
  /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
 /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
/* * * Computers Rule 0100 01001011 * * * * * * */

___
mailop mailing 
listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


___
mailop mailing 
listmailop@mailop.orghttps://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
Vladimir Dubrovin
[image: @Mail.Ru]

___
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] why "not comply with best practices" on SpamRats?

[Gil Bahat via mailop]

I think we agree or else there I didn't phrase myself correctly (sorry, not
a native english speaker):

1. Using a regex over DNS pattern is a 'proxy' method for using a more
trusted method of identifying PBL space.
2. No 'Big' player uses it.
3. 'Big' players are the most performance sensitive out of all mail
recipients out there and most targeted by attacks.
4. Deriving from 1+2+3 - Using said regex pattern cannot be reasonably
justified by performance considerations.
5. Netease (one of the largest mail services in the world) would have been
flagged by it.
6. Deriving from 4+5, the practice attests to lazyness or apathy to false
positives by the operator deploying it.

Gil

On Wed, Jun 15, 2016 at 12:36 PM, Michelle Sullivan 
wrote:

> Gil Bahat via mailop wrote:
>
>>  public PBL registry. Do you see any big recipients
>> (gmail/hotmail/yahoo/netease/etc) 'optimizing' by such a regex?
>>
>
> I would also beg to differ if you think at least 3 of those you mention
> would use any of the public DNSbls as a sole decision point...  Nor would
> they use 'such a regex'... even the other massive one that immediately
> comes to mind that you didn't mention that does use a DNSbl on the border
> as a sole decision point for "quick rejects" doesn't use a Dynamic/Policy
> blocklist of any type - despite recommendations by technical experts and
> live statistics being taken showing a 25%(ish) efficiency gain with zero
> false positives all because there is a "chance" of false positives.
>
> --
> Michelle Sullivan
> http://www.mhix.org/
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] why "not comply with best practices" on SpamRats?

[Gil Bahat via mailop]

If you are knowingly giving up all of netease mail (or SES mail in the
other example), when you could have a very reasonable setup that doesn't do
so, you are being indifferent and uncaring about your users' email needs.
Your users will pay a price and netease will pay a price. the fact that a
certain indicator suggests something is 99% spam, doesn't mean the 1%
non-spam is not worth 'fighting' for. again, up to reasonable extents.
working with a proper local PBL data file, which should weigh a few megs?
you'd have to be google for that to really make a noticeable difference AND
evidently google doesn't need to use regexps.

I have a dream that one day senders will start implementing an RHSBL for
users logging in to their service. once a recipient finds themselves
blacklisted and their users refused service on big ecommerce sites due to
unreasonable email ground rules and some of the heat senders receive will
fall back at them, then we'll see some progress around that.

Gil

On Wed, Jun 15, 2016 at 10:30 AM, Noel Butler 
wrote:

> On 15/06/2016 16:59, Gil Bahat via mailop wrote:
>
> I beg to differ. Spamhaus offers the PBL in rsync format for big enough
> sites and i'm sure that if the cost is somehow a major factor, you could
> have a proper public PBL registry. Do you see any big recipients
> (gmail/hotmail/yahoo/netease/etc) 'optimizing' by such a regex? no, you
> don't, and their performance requirements are much more stringent than
> yours. That could be a good indication you're cutting corners and having
> someone else pay the price for it.
>
> Gil
>
>
> I'm very aware S.H. sell rsync connections, doesnt make any difference.
>
> I, like most here I would think, will do whatever they want to protect
> their own network, that comes first, above all else, and if I or others
> choose to deny access to our resources to people we don't know who are
> using an address format common with those that dont typically have a need
> to send direct mail, then so be it. I see nobody paying the price for
> anything, since pretty much all of those connections will not be legitimate
> mail senders that is my experience in over 20 years. Also, you are not to
> know that gmail or hotmail etc dont do some for of scoring based on a
> myriad of ways to decide to either inbox or junk box, maybe they dont,
> maybe they do, its irrelevant because they are not my networks so I have no
> need to know, just as they have no need to know all the methods we use else
> the bad guys get an advantage.
>
>
> --
> If you have the urge to reply to all rather than reply to list, you best
> first read  http://members.ausics.net/qwerty/
>
> ___
> 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] why "not comply with best practices" on SpamRats?

[Gil Bahat via mailop]

I beg to differ. Spamhaus offers the PBL in rsync format for big enough
sites and i'm sure that if the cost is somehow a major factor, you could
have a proper public PBL registry. Do you see any big recipients
(gmail/hotmail/yahoo/netease/etc) 'optimizing' by such a regex? no, you
don't, and their performance requirements are much more stringent than
yours. That could be a good indication you're cutting corners and having
someone else pay the price for it.

Gil

On Wed, Jun 15, 2016 at 9:48 AM, Noel Butler  wrote:

> On 15/06/2016 16:09, Gil Bahat via mailop wrote:
>
> Prudency aside, this is one of the things wrong in the email world. I
> don't get it why recipients do something which is patently lax (having a
> naive regex) when a more appropriate solutions exist (spamhaus PBL) with a
> 'screw the sender, it's their problem, they'll bear the wrath of their
> users' - obviously allowing recipients to do this even for one of the
> largest senders in the world (126/163/yeah.net with over 700m users!).
>
>
> Its more about stopping spam, not just deliberate spam, but the
> accidental, as in malware infected PC's , contacting DNSBL's uses network
> resources, why take seconds when you can decide in nano seconds, no need to
> keep throwing hardware at the problem, when you can cull it there and then,
> our DNSBL's and anti spam-anti virus systems work 40% less through blocking
> these types of hosts, since they are for the most part malware/virus
> infected machines.
>
> In an ideal world all ISP's would block port 25 outbound except for
> official mail servers and make users use submission port, that would go
> along way to curbing the noise, but not eliminate it.
>
> --
> If you have the urge to reply to all rather than reply to list, you best
> first read  http://members.ausics.net/qwerty/
>
> ___
> 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] why "not comply with best practices" on SpamRats?

[Gil Bahat via mailop]

Prudency aside, this is one of the things wrong in the email world. I don't
get it why recipients do something which is patently lax (having a naive
regex) when a more appropriate solutions exist (spamhaus PBL) with a 'screw
the sender, it's their problem, they'll bear the wrath of their users' -
obviously allowing recipients to do this even for one of the largest
senders in the world (126/163/yeah.net with over 700m users!).

Gil

On Wed, Jun 15, 2016 at 9:03 AM, Noel Butler  wrote:

> On 15/06/2016 13:52, Suresh Ramasubramanian wrote:
>
>> That too is a workable approach. Though market forces usually deal
>> with poorly managed bls over time.
>>
>>
> Its not just DNSBL's as has been pointed out by people other than myself
> who use similar rules locally, the safest bet is to accept this is how the
> world works in many places, and slightly changing the DNS should resolve
> all the problems, in fact, now it has been explained by several people in
> many different ways I hope the OP has understood (yes I accept language
> barriers can be problematic) and has already begun changing their A/PTRs to
> something that is less eye catching to remote sites.
>
>
> --
> If you have the urge to reply to all rather than reply to list, you best
> first read  http://members.ausics.net/qwerty/
>
> ___
> 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] why "not comply with best practices" on SpamRats?

[Gil Bahat via mailop]

I wouldn't recommend this approach. If your email carries high business
value, even a relatively small ISP could justify the time investment needed
to resolve the situation. when we had issues with spamcannibal BL and the
operator was unyielding, I went the time to research which of the providers
using it were too reliant on it, and convinced them to drop the list - it
was a local mail provider in hungary, with relative notability in-territory.

in the larger scope of mail volume? sure, doesn't matter. but why hurt even
one country's performance just because there are millions of other mail
users? that doesn't make sense.

On Wed, Jun 15, 2016 at 6:33 AM, Suresh Ramasubramanian  wrote:

> Or just don't bother about some random  DNSBL  with ill defined criteria
>
> If Spamhaus lists you, or a few other such list you, then sure you have
> problems.  Other than that there's several dozen others around with a
> comparatively minuscule userbase if at all.
>
> --srs
>
> > On 15-Jun-2016, at 8:36 AM, 陈俊平  wrote:
> >
> > SpamRats using is not clear, we may figure it out by our continuing
> discussions. Or catch the notice of SpamRats.
>
> ___
> 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] "One-Click" List-Unsubscribe URIs

[Gil Bahat via mailop]

FWIW I understood that the policy of large recipients is to already
'demand' and 'assume' that the URLs in List-Unsubscribe behave as 1-clicks
and that mailto: links can also be triggered from backend systems. That was
the requirement that I passed to our R&D. I'd be happy if anyone from a
large recipient can comment on that - not sure what would happen if it
didn't indeed function like this, or if there are separate streams and this
shuts off only a specific stream or what happens if the users regrets
unsubscribing and re-activates it.

Regards,

Gil Bahat,
Director of Online Operations,
Magisto Ltd.

On Thu, Jun 9, 2016 at 12:32 PM,  wrote:

> Hi List,
>
> I'm working on a document about a topic that came out of an open
> roundtable discussion at M³AAWG, it is more or less a way for mail
> senders to signal that a URI in the List-Unsubscribe Header has
> "One-Click" functionality and therefore can be triggered by backend
> systems to provide MUA users a better way to unsubscribe from bulk
> commercial mail that is reputable enough.
>
> We as an ESP implemented it for our customers so if you are curious
> about it, there is a chance that you already getting traffic with this
> feature enabled.
>
> I'm writing here because I'm looking for more input about it and if it
> interesting enough for ISPs or MUA provider.
>
> It's a public document and I welcome requests with updates...
> https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
>
> For people on the road a copy of the document is attached to this
> mail...
>
>
> Kind regards,
>
> / Tobias Herkula
>
> --
> optivo GmbH
> Head of Deliverability & Abuse Management
> Wallstraße 16
> 10179 Berlin
> Germany
>
> Tel: +49(0)30-768078-129
> Fax: +49(0)30-768078-499
>
> Email:mailto:t.herk...@optivo.com
> Website:  http://www.optivo.com
> Linkedin: http://www.linkedin.com/in/tobiasherkula
>
> Commercial register: HRB 88738 District Court Berlin-Charlottenburg
> Executive board: Dr. Rainer Brosch, Thomas Diezmann
> Vat reg. no.: DE813696618
>
> optivo A company of Deutsche Post DHL Group
>
> ___
> 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] What in the name of all that is evil is this new spam technique?

[Gil Bahat via mailop]

It's called bounceio 'domain monetization' and it's not new at all. They
will send bounces specifically back to the sender address and not the
return path address. Like any spam operation, it's UCE. Unlike any other
spam operation, not enough people mark them as spam, so their email still
gets accepted. I asked our ESP to avoid sending email to any domain with a
BIO server in the MX.

Gil
On May 6, 2016 11:43 PM, "Aaron C. de Bruyn"  wrote:

A user sent a message to the django-users list asking for help.  I replied
and about 5 minutes later I got a 'bounce' message that is basically a
bounce message laden with spam.

http://imgur.com/Ohn6sPE

Is this a new method of delivering spam?  Get 'someone' like
j...@piccloud.com to sign up for the mailing list, then delete the account
and have piccloud.com send spam thinly-disguised as bounce messages?

-A

___
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 deferred with a page not found

[Gil Bahat via mailop]

We've been GL'ed by yahoo for over a year now and I pretty much gave up all
hope of ever getting it fixed, despite the fact that we send time-sensitive
emails. We get a mix of the postmaster-21 notice and another notice with a
vague/generic text.

Gil
On Apr 27, 2016 1:23 AM, "Renaud Allard via mailop" 
wrote:



On 27/04/16 00:00, Brandon Long via mailop wrote:

> Big companies are big, never underestimate the challenges involved.  We
> recently went through ours to find out that the editors had drifted the
> content of several of the links we pointed to in smtp responses to the
> point where they were not relevant at all.  At least they all still
> existed, or redirected to new pages which were tangentially related, I
> guess.
>
>
I also work for a big company, and I quite understand the challenges making
anything move even a tiny bit and even for the best reason. But I know that
when poking the right people at the right time, you can get some changes
done, even if it takes some (long) time to get the real move.

Now, to be honest, we recently got some messages from a big provider (I
think you all know who we are talking about) hinting at the fact they might
have understood that they should not silently drop email which were
accepted by their MTA.

Changes never happen if no one points out at problems.


___
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] Gmail throttles anyway

[Gil Bahat]

you know, I think that's one of the highly undesirable unintended
consequences of DMARC ATM - the habit it's forming to dig out messages from
spam. I keep thinking to myself how I need not make a mistake about
something patently spammy or risky when digging out these from spam. so I
spend a lot more time looking at spam.

Gil

On Thu, Feb 4, 2016 at 11:10 PM, Franck Martin  wrote:

>
>
> On Thu, Feb 4, 2016 at 1:02 PM, Michael Wise 
> wrote:
>
>> It looks like the DKIM bits were added by Gmail.
>>
>> As to point 4 … Do Not Get Me Started.
>>
>>
>>
> This list is not hosted by Google? So the bits that break DKIM are added
> by mailman, and it is a statement not a judgement.
>
> As for 4, why deny so much fun? :P
>
> ___
> 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] Delivery to gmail via IPv6

[Gil Bahat]

Also bounce.io , but these are very bad services. They bounce to the reply
to, not bounce address: former is likely monitored, latter is likely
automated removal.
On Dec 11, 2015 10:40 AM, "Franck Martin"  wrote:

> There a whole business, https://betterbounces.net, based on rewriting the
> NDR into something any user can read, with a meaningful call to action.
>
> I love the technical info too, but as Brandon said, it could be later in
> the email.
>
> On Thu, Dec 10, 2015 at 1:23 PM, Brandon Long  wrote:
>
>> I was just discussing this issue with our support folks, and we're
>> looking at improving ours for this reason.  We also see a remarkable number
>> of our NDRs marked as spam, especially by those whose primary language
>> isn't English.
>>
>> We'll definitely still include the technical information, but it'll be
>> further down.
>>
>> And we'll do our best with handling the remote server's error messages,
>> but ugh.  It's too bad that the extended status codes are still so
>> generic... though, as our tech writer and ux folks pointed out, really, all
>> the user cares about is "did I do something wrong? Is there something else
>> I can do?"
>>
>> Brandon
>>
>> On Thu, Dec 10, 2015 at 12:18 PM, Dave Warren  wrote:
>>
>>> And unfortunately the friendlier they are, the less useful they usually
>>> are.
>>>
>>> The ugly ones are the only ones that are useful, but for whatever
>>> reason, it's beyond MTA developers to start with friendly messages with a
>>> "Troubleshooting information below" that contains a useful transcript.
>>>
>>> As a techie, I appreciate the info, but the reality is that unless you
>>> expect the sender to take some action, transient error messages aren't
>>> usually useful. We've scaled back the transient failures that we send, at
>>> most you get a single transient and single permanent error, and even still,
>>> I question the value of the transient error since the user can't actually
>>> do anything (and nor does forwarding it to support@ help). Of course,
>>> we also allow users to view the SMTP queue for all messages involving their
>>> account for those who care, so that might skew my viewpoint.
>>>
>>> I'm not a fan of the current trend of using permanent error codes in
>>> SMTP for what might well be transient errors (DNS problems, for example),
>>> but at the same time, as a sender, I don't see any value in retrying more
>>> than 24 hours.
>>>
>>> It's tough to balance user expectations though.
>>>
>>> --
>>> Dave Warren
>>> http://www.hireahit.com/
>>> http://ca.linkedin.com/in/davejwarren
>>>
>>> On 2015-12-10 10:43, Franck Martin wrote:
>>>
 It also has to do with people not understanding DSN. Seriously they are
 ugly and hard to find the relevant information in them...


>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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] Gmail selectively treating email as spam

[Gil Bahat]

Hi,

FWIW we're indeed seeing a large influx of fake intuit emails on our
corporate mail. IMHO A company like intuit should go full DMARC reject, not
just the bare minimum of SPF and DKIM cross the board. their SPF is invalid
due to many excessive lookups (26 at time of writing). If anybody has
contacts there or at least access to some inmails, they'd be doing everyone
a big favour.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Tue, Nov 3, 2015 at 7:59 PM, Brandon Long  wrote:

> It goes to spam because we think it's phishy. It sometimes doesn't go to
> spam if there are enough whitelisting signals in the user's account.
> Apparently we're seeing a high volume of intuit.com/mint.com phishing
> messages.
>
> I agree with the recommendation to add an intuit.com DKIM key.
>
> If you aren't with Intuit or Salesforce, the best you can do is add a
> "never flag as spam" filter.
>
> Brandon
>
> On Tue, Nov 3, 2015 at 9:32 AM, Franck Martin 
> wrote:
>
>> I would suggest to add a DKIM d=intuit.com to the email... It is now
>> possible with Salesforce.
>>
>> On Tue, Nov 3, 2015 at 8:11 AM, Steve Atkins  wrote:
>>
>>>
>>> > On Nov 2, 2015, at 10:59 PM, Yang Yu  wrote:
>>> >
>>> > Lately I see a lot of emails from
>>> > mintcustomersupport-no-re...@intuit.com (sent from salesforce) are in
>>> > gmail spam folder with message "Our systems couldn't verify that this
>>> > message was really sent by intuit.com". However not all emails go into
>>> > spam (a few slipped through, I just can't tell the difference from the
>>> > headers). The emails are legitimate support tickets.
>>>
>>> Intuit are publishing invalid SPF records, so if Google is checking
>>> whether this mail is plausibly from intuit.com based on a combination
>>> of the 822.From
>>> and the peer IP (a check that wouldn't be recorded in the Received-SPF
>>> field) that
>>> won't be working the way that Intuit might like it to - and would likely
>>> lead to the
>>> "couldn't verify that this message was really sent by intuit.com" and
>>> to treating the
>>> mail with some suspicion.
>>>
>>> Cheers,
>>>   Steve
>>>
>>>
>>> >
>>> >>>>
>>> >
>>> > Header from email that went into spam
>>> >
>>> > Delivered-To: mygm...@gmail.com
>>> > Received: by 10.28.113.210 with SMTP id d79csp2061485wmi;
>>> >Mon, 2 Nov 2015 22:09:55 -0800 (PST)
>>> > X-Received: by 10.13.237.4 with SMTP id
>>> w4mr18970504ywe.110.1446530995490;
>>> >Mon, 02 Nov 2015 22:09:55 -0800 (PST)
>>> > Return-Path: >> intuit.com__1swqj00nzvzul...@ky00ew61ipso.e-a8tlmay.na14.bnc.salesforce.com
>>> >
>>> > Received: from smtp14-sjl.mta.salesforce.com
>>> > (smtp14-sjl.mta.salesforce.com. [204.14.234.77])
>>> >by mx.google.com with ESMTPS id
>>> 14si11140665ywe.241.2015.11.02.22.09.55
>>> >for 
>>> >(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256
>>> bits=128/128);
>>> >Mon, 02 Nov 2015 22:09:55 -0800 (PST)
>>> > Received-SPF: pass (google.com: domain of
>>> > mintcustomersupport-no-reply=
>>> intuit.com__1swqj00nzvzul...@ky00ew61ipso.e-a8tlmay.na14.bnc.salesforce.com
>>> > designates 204.14.234.77 as permitted sender) client-ip=204.14.234.77;
>>> > Authentication-Results: mx.google.com;
>>> >   spf=pass (google.com: domain of
>>> > mintcustomersupport-no-reply=
>>> intuit.com__1swqj00nzvzul...@ky00ew61ipso.e-a8tlmay.na14.bnc.salesforce.com
>>> > designates 204.14.234.77 as permitted sender)
>>> > smtp.mailfrom=mintcustomersupport-no-reply=
>>> intuit.com__1swqj00nzvzul...@ky00ew61ipso.e-a8tlmay.na14.bnc.salesforce.com
>>> > Return-Path: >> intuit.com__1swqj00nzvzul...@ky00ew61ipso.e-a8tlmay.na14.bnc.salesforce.com
>>> >
>>> > Received: from [10.236.9.132] ([10.236.9.132:58425]
>>> helo=ops-mta1-3-was)
>>> > by mx2-sjl.mta.salesforce.com (envelope-from
>>> > >> intuit.com__1swqj00nzvzul...@ky00ew61ipso.e-a8tlmay.na14.bnc.salesforce.com
>>> >)
>>> > (ecelerity 3.6.8.47404 r(Core:3.6.8.0)) with ESMTPS
>>> (cipher=DES-CBC3-SHA)
>>> > id 52/43-37971-2BF48365; Tue, 03 Nov 2015 06:09:54 +
>>> > Received: from [10.23

Re: [mailop] Spam to "published" address?

[Gil Bahat]

On Thu, Oct 15, 2015 at 8:57 PM, Jay Hennigan 
wrote:

> I've been getting an increasing amount of spam to various of my addresses
> some of which have not been been actively used for some time. The amount of
> spam received is kicking upward fairly rapidly.
>
> All of this spam is sent by a third-party, not the company whose primary
> domain appears in the "From".
>
> The content of this spam seems to be somewhat related to my interests in
> most cases but definitely not from anyone from whom I've given permission.
>
> In investigating this third-party mailer I came across this interesting
> policy:
>
>   "Unsolicited Email" is defined as email sent to persons other than:
>   (i) persons with whom you have an existing business relationship, OR
>   (ii) persons who have consented to the receipt of such email,
>   including publishing or providing their email address in a manner
>   from which consent to receive email of the type transmitted may be
>   reasonably implied.
>
> It's section (ii) that concerns me. Scraping addresses from Usenet, blogs,
> comments, or subscribed discussion lists could easily fall under
> "Publishing", could it not?
>

I'd wager this is meant to specifically cover things like the ultra-common
situation of confirmation via social network proxy (i.e. "facebook login").
To be honest for us it's been some sorts of a catch-22: users get upset if
we re-require them to verify their email as nobody does that and it ruins
the smooth flow / usability promise of social login. OTOH we've seen data
issues such as spamtraps occasionally, as we cannot attest to the
'freshness' of the facebook data. (replace facebook with your favorite
social network as required)

with regards actual scraping - to be honest, even this is actually not as
clear cut as well about what's being scraped and for what purpose. I've
seen products that scrape outreach address for websites to solicit
placements and that's kind of an industry thing and they haven't had
deliverability problems with it, as long as messages were indeed about
placements - that's how that business goes when you want to avoid an
intermediate ad agency or want to do an exchange. it really is all a
case-by-case thing, even scraping is susceptible to exceptions.


> What is the opinion of this group, is this policy that of a legitimate ESP
> or a garden-variety spammer?
>
>
As Brandon wrote, that's kinda moot - as long as there is
temporal/localized consensus that something is spam, there will be
repercussions and our opinions are kind of as good as any. their TOS does
not matter as much as using it to boot (or to avoid booting) spammers.
my 2 cents - I can see this policy working out and spammers still getting
the boot for their actions.


> --
> Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Excess deferrals from Yahoo

[Gil Bahat]

Does anyone have any contacts from Yahoo? we somehow seem to be able to
maintain very good reputation with anyone but them, even after trying the
postmaster interface 'more than once'(TM)...

while this was a parser error, if we hadn't been greylisted to begin with,
we wouldn't have been impacted by this. so that's worth settling once and
for all, our time-sensitive emails notwithstanding...

If reply includes contact please reply off-list.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Mon, Oct 12, 2015 at 11:43 AM, Gil Bahat  wrote:

> Hi,
>
> we are seeing excess repeat deferrals incoming from yahoo. it's the same
> GL01 we've been seeing for a while now, but now they seem to recur enough
> for same emails, causing our ESP to treat these successive deferrals as
> bounces. score -1 yet again for greylisting as a stupid, stupid policy...
>
> has anyone else encountered this too? can anyone help?
>
> Regards,
>
> Gil Bahat,
> DevOps/Postmaster,
> Magisto Ltd.
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Excess deferrals from Yahoo

[Gil Bahat]

Hi,

we are seeing excess repeat deferrals incoming from yahoo. it's the same
GL01 we've been seeing for a while now, but now they seem to recur enough
for same emails, causing our ESP to treat these successive deferrals as
bounces. score -1 yet again for greylisting as a stupid, stupid policy...

has anyone else encountered this too? can anyone help?

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Ex-post-facto spam complaints, a possible UI problem / other mitigation

[Gil Bahat]

On Thu, Sep 24, 2015 at 10:40 PM, Michael Wise 
wrote:

> Ignore any reports where the email was received by the recipient beyond a
> certain window.
>
>
>
These usually come with at least 1 genuine complaint. we unsubscribe them
anyway, we don't want to risk it. In particular I cannot trust automated
systems not to treat it as a 'send after complaint' which ostensibly could
be more severely penalized.


> 24 hours is probably too soon.
>
> 1 week may very well be the sweet spot, because … if it really **IS** a
> campaign, chances are you dealt with it well within the 24 hour window. 1
> month is way too late.
>
>
>
It's not even a campaign, it's transactional emails which have been acted
upon by the client.


> Condense volume of complaints from the same recipient about the same
> sender down to a single cluster….
>
>
> That's what I am looking for. With lack of transparency on filtering, I
can't say this is what's happening and I suspect it's not.


> Other guidelines will present themselves I’m sure.
>
>
>
> Oh, and a bunch of False Positive complaints from a given sender to
> similar recipients (ie, all to the same or a small number of domains) …? If
> the sender domain and the recipient domain are siblings somehow, mark the
> sender as abusive and discard. Or send a nasty note… or fire the customer.
> YMMV.
>
>
>

We already follow practice and unsubscribe them. now hopefully, since we
see a relative few FBL complaints in total, it means the entire thing has
little effect on our sending. But we simply don't know and we have good
reason to suspect otherwise, across all 3 largest providers.



> 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 *Gil Bahat
> *Sent:* Thursday, September 24, 2015 8:04 AM
> *To:* mailop@mailop.org
> *Subject:* [mailop] Ex-post-facto spam complaints, a possible UI problem
> / other mitigation
>
>
>
> Hi,
>
>
>
> Carefully observing our FBL complaints one by one, I see a disturbing
> phenomena: users marking swaths of email, sometimes received over a month
> ago as spam, accounting for a significant volume of complaints.
>
>
>
> I have good reason to believe this does not represent actual spam
> reporting, but rather an easy to perform what would have been a more
> complex (UI wise) task, tandem delete and unsubscribe.
>
>
>
> Users do this to emails which they clearly read and found useful (e.g. the
> welcome or email verification emails, emails which they opened, clicked and
> even forwarded at times, etc etc).
>
>
>
> I would like to request all providers to (A) consider changing their UI to
> account for this option / suggest unsubscription and deletion instead and
> (B) mitigate the impact of multiple consecutive reports. I am not able to
> quantify how this exactly affects our service but I have good reason to
> believe these are counted to full effect as much as any other spam
> complaint (e.g. from sources like return path senderscore).
>
>
>
> Feedback (outside the loop, snicker snicker) would be most welcome.
>
>
>
> Regards,
>
>
>
> Gil Bahat,
>
> DevOps/Postmaster,
>
> Magisto Ltd.
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Ex-post-facto spam complaints, a possible UI problem / other mitigation

[Gil Bahat]

Responses Inline

On Thu, Sep 24, 2015 at 9:07 PM, Jay Hennigan 
wrote:

> On 9/24/15 8:04 AM, Gil Bahat wrote:
>
>> Hi,
>>
>> Carefully observing our FBL complaints one by one, I see a disturbing
>> phenomena: users marking swaths of email, sometimes received over a
>> month ago as spam, accounting for a significant volume of complaints.
>>
>
> I see a lot of this with AOL's FBL, very little with others. This may be
> due to the wording or layout of their GUI, perhaps the "Spam" and "Delete"
> buttons are close together or similar in appearance. These are typically
> timely, but occasionally long-delayed.
>
> I suspect that the long-delayed bunches are "throwaway" email addresses
> that are infrequently used and get a lot of spam. In fact, I personally am
> "guilty" of this. I maintain a Hotmail account with a hard-to-guess
> username that I use very rarely. It's only for one-off online purchases,
> hotel reservations and similar very infrequent or one-time transactional
> email. I only log in to read this mailbox when I expect email regarding a
> recent transaction.
>
> Despite very conscientiously unchecking all of the pre-checked "Send me
> offers" buttons and *every time* in the order comments putting "This email
> address is to be used for correspondence regarding this transaction only,
> no spam please", it gets a TON of spam from many of the companies with
> which I have done business once as well as their "affiliates". It isn't
> unusual for me to log in to the Hotmail account after a month or two to
> find it full of spam from an outfit I once purchased from years ago, etc.
>
> I mark it as the spam that it is without opening it and thus triggering
> the tracking bugs, but it doesn't seem to put a dent in the flood.
>
> I have good reason to believe this does not represent actual spam
>> reporting, but rather an easy to perform what would have been a more
>> complex (UI wise) task, tandem delete and unsubscribe.
>>
>
> If the recipient never subscribed with closed-loop confirmation in the
> first place then "Unsubscribe" should never be necessary if the sender is a
> good actor, and is a bad idea for the recipient. Doing so confirms to an
> abuser that the mailbox is active and that email is being read.


None of the above seems to be the scenario. these are purely transactional
emails coming from the use of our service: our welcome email, our 'your
movie is ready' email, etc etc. I can easily see that these emails have
been used, e.g. the welcome email used to verify your email to the service.


>
> Users do this to emails which they clearly read and found useful (e.g.
>> the welcome or email verification emails, emails which they opened,
>> clicked and even forwarded at times, etc etc).
>>
>
> Tracking bugs may show if emails are opened, but they can't read the
> user's mind as to whether or not they were found useful. And they only work
> if the user loads remote images by default, a security risk.


I can deduce this not by the virtue of open bugs, but rather by the virtue
that the user used these: aside from the example above, e.g. they used the
"movie is ready" email because they registered on it with the GA UTM
source, or multiple hits because of forwarding of that email / multiple
opens, etc.


>
> I would like to request all providers to (A) consider changing their UI
>> to account for this option / suggest unsubscription and deletion instead
>> and (B) mitigate the impact of multiple consecutive reports.
>>
>
> An alternative would be a confirmation dialog box "This will send a report
> to the sender's ISP that the email is abuse. Future email from this sender
> will be routed to your "Junk" folder. Are you sure?"
>
> By the way, this isn't ex-post-facto. It's simply reported later than
> expected. Ex-post-facto would be if the definition of "spam" changed
> between when the mail was sent and when it was reported.
>
>
As per the above, it is exactly ex-post-facto - the users used these emails
and therefore did not consider them spam to begin with, and then a month
later changed their mind (or possibly meant something a bit different, like
trying to unregister from them in one fell swoop)


>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Ex-post-facto spam complaints, a possible UI problem / other mitigation

[Gil Bahat]

Hi,

Carefully observing our FBL complaints one by one, I see a disturbing
phenomena: users marking swaths of email, sometimes received over a month
ago as spam, accounting for a significant volume of complaints.

I have good reason to believe this does not represent actual spam
reporting, but rather an easy to perform what would have been a more
complex (UI wise) task, tandem delete and unsubscribe.

Users do this to emails which they clearly read and found useful (e.g. the
welcome or email verification emails, emails which they opened, clicked and
even forwarded at times, etc etc).

I would like to request all providers to (A) consider changing their UI to
account for this option / suggest unsubscription and deletion instead and
(B) mitigate the impact of multiple consecutive reports. I am not able to
quantify how this exactly affects our service but I have good reason to
believe these are counted to full effect as much as any other spam
complaint (e.g. from sources like return path senderscore).

Feedback (outside the loop, snicker snicker) would be most welcome.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Looking for a contact at Ziggo B.V. Netherlands

[Gil Bahat]

Hi,

I am looking for a contact at Ziggo Netherlands (ziggo.nl/home.nl/as9143.net)
to clear up some flagging of our emails as spam. Please contact me offlist,
help would be welcome.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Microsoft sending multiple Message-ID headers in password reset links..

[Gil Bahat]

Hi,

the archives will quickly tell you the list never was such and thus isn't
likely to become one. there's enough value in the list - varying of course
by your definition of value.
If I were you, I'd stick around the list, perhaps answer a bit less or only
when you find things interesting.

As a sidenote, I'm nowhere near surprised by the angst level of senders and
recipients alike, created by distrust between mailbox operators and
senders. IMHO If the industry would work on better communication
facilities, things should gradually cool down, on a long term scale.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Tue, Sep 15, 2015 at 9:44 PM, Michael Wise 
wrote:

> No, it doesn't.
>
> After all, technically Message-ID is an optional field.
> I bitch and moan about that, but nobody cares... They all end up pointing
> to, "SHOULD", and I can't really do anything but :'(
>
> And the information is not pertinent.
> If this ML is going to become a forum for reporting spam, I'm gone.
>
> Aloha,
> Michael.
> --
> Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been
> Processed." | Got the Junk Mail Reporting Tool ?
>
> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Steve
> Freegard
> Sent: Tuesday, September 15, 2015 11:33 AM
> To: mailop@mailop.org
> Subject: Re: [mailop] Microsoft sending multiple Message-ID headers in
> password reset links..
>
>
> On 15/09/15 18:24, Al Iverson via
> https://na01.safelinks.protection.outlook.com/?url=mailop.org&data=01%7c01%7cmichael.wise%40microsoft.com%7c014eb44783c04c70154808d2bdfd28d0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=iUlvmPaHW9GC7kLBrxjNx0ssuXy8JD5nGgnneQ%2bZV2I%3d
> wrote:
> > Is this truly having an immediate negative impact operationally? It
> > seems like this could be feedback you could give them directly,
> > offlist, without having to share it with the rest of us.
> >
> >
>
> Very funny.   Feedback to where?  Their 1st line support wouldn't have a
> clue what to do with that.
>
> I'm sure that plenty of us check RFC validity (e.g. there shouldn't be
> more than one Message-Id header), so it's pretty pertinent information.
>
> I'm sure it's causing them issues with deliverability because of it.
>
> Regards,
> Steve.
>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fchilli.nosignal.org%2fmailman%2flistinfo%2fmailop&data=01%7c01%7cmichael.wise%40microsoft.com%7c014eb44783c04c70154808d2bdfd28d0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nG6dlE9YS5zm9Ei7ERHdt%2b7AQj9S5YRtdilQ%2fgKgIzs%3d
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Hotmail/Microsoft Contact Available?

[Gil Bahat]

Why don't we take this to the next level then and hide it behind a 1x1
pixel and triple the level of tier-1 scripted support, after making it
available only via IVR with average 15 minutes wait?

let's weed out the weak-willed, because what this industry definitely needs
is more distrust and lack of communication between senders and receivers,
all in the (sometimes ludicrous excuse) name of spam fighting.

even if mailop doesn't actually resolve my issues (and for the most part it
has), it does have the special property of making you feel that somebody
cares about your email. from the perspective of a sender trying to keep
sane, that means a lot.



On Tue, Sep 15, 2015 at 1:02 AM, Michael Wise 
wrote:

>
> Or people who are in a desperate hurry...
> Both of which intersect on the Ven Diagram of a great many Mail Admins.
>
> Aloha,
> Michael.
> --
> Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been
> Processed." | Got the Junk Mail Reporting Tool ?
>
> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Steve Atkins
> Sent: Monday, September 14, 2015 2:54 PM
> To: mailop@mailop.org
> Subject: Re: [mailop] Hotmail/Microsoft Contact Available?
>
>
> > On Sep 14, 2015, at 2:33 PM, Michael Wise 
> wrote:
> >
> > It’s on my bucket list….
>
> OTOH, it's a reasonably effective method of filtering out people who refuse
> to read documentation.
>
> Cheers,
>   Steve
>
> >
> > Aloha,
> > Michael.
> > --
> > Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool ?
> >
> > From: Gil Bahat [mailto:g...@magisto.com]
> > Sent: Monday, September 14, 2015 2:29 PM
> > To: Michael Wise 
> > Cc: mailop@mailop.org
> > Subject: Re: [mailop] Hotmail/Microsoft Contact Available?
> >
> > That brings up a very good point: can anyone make this link at least
> mildly more prominent than a 'here' anchor in the middle of a large body of
> text under an unassuming header?
> >
> > Almost makes you feel unwanted.
> >
> > On Sep 15, 2015 12:16 AM, "Michael Wise" 
> wrote:
> > If it has anything to do with Hotmail, this is the wrong advice.
> > If it’s specific to Hotmail or
> https://na01.safelinks.protection.outlook.com/?url=Outlook.com&data=01%7c01%7cmichael.wise%40microsoft.com%7c453fcad8f70643c8143808d2bd4fda8f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=4ox8ZI%2b0mYIO4Es8bnHhxfbHC6U97qIhx2kk3V2zBcE%3d
> email addresses and such like…
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.live.com%2fmail%2ftroubleshooting.aspx&data=01%7c01%7cmichael.wise%40microsoft.com%7c453fcad8f70643c8143808d2bd4fda8f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZS3Sx%2bO3rHf81xgujzkgyCsBR66S8s9nAm67jjFqPlw%3d
> >
> > In particular, *THIS* bit:
> >
> > 
> >
> > Sooner or later, your discussions will end there, and the ticketing will
> begin.
> > There is *NO* way around it; Microsoft Legal has been very clear on the
> matter.
> >
> > Aloha,
> > Michael.
> > --
> > Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool ?
> >
> > From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Matthew
> Black
> > Sent: Monday, September 14, 2015 1:45 PM
> > To: Brian Curry ; mailop@mailop.org
> > Subject: Re: [mailop] Hotmail/Microsoft Contact Available?
> >
> > Are you a mail producer or a Microsoft Office365 / Exchange Online
> Protection customer? If so, call your normal support channels. If not, ask
> a few of your select customers to complain to Microsoft. I am one of those
> Microsoft customers that has experienced a number of so called “white hat”
> e-mail marketing companies that let many of their customers send UCE
> despite a zero-tolerance policy.
> >
> > matthew black
> > california state university, long beach
> >
> >
> > From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Brian Curry
> > Sent: Thursday, September 03, 2015 7:25 AM
> > To: mailop@mailop.org
> > Subject: [mailop] Hotmail/Microsoft Contact Available?
> >
> > Is anyone from Microsoft/Hotmail able to help me with a delivery issue
> that has been lingering for months?
> >
> > Long story short, I have been going in loops with the normal Hotmail
> support process for months and cannot seem to get a useful answer. IP
> address in question has pulled way back on engagement and I have tested the
> email conten

Re: [mailop] Hotmail/Microsoft Contact Available?

[Gil Bahat]

That brings up a very good point: can anyone make this link at least mildly
more prominent than a 'here' anchor in the middle of a large body of text
under an unassuming header?

Almost makes you feel unwanted.
On Sep 15, 2015 12:16 AM, "Michael Wise"  wrote:

> If it has anything to do with Hotmail, this is the wrong advice.
>
> If it’s specific to Hotmail or Outlook.com email addresses and such like…
>
>
>
> http://mail.live.com/mail/troubleshooting.aspx
> 
>
>
>
> In particular, **THIS** bit:
>
>
>
>
>
> Sooner or later, your discussions will end there, and the ticketing will
> begin.
>
> There is **NO** way around it; Microsoft Legal has been very clear on the
> matter.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org] *On Behalf Of *Matthew
> Black
> *Sent:* Monday, September 14, 2015 1:45 PM
> *To:* Brian Curry ; mailop@mailop.org
> *Subject:* Re: [mailop] Hotmail/Microsoft Contact Available?
>
>
>
> Are you a mail producer or a Microsoft Office365 / Exchange Online
> Protection customer? If so, call your normal support channels. If not, ask
> a few of your select customers to complain to Microsoft. I am one of those
> Microsoft customers that has experienced a number of so called “white hat”
> e-mail marketing companies that let many of their customers send UCE
> despite a zero-tolerance policy.
>
>
>
> matthew black
>
> california state university, long beach
>
>
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org
> ] *On Behalf Of *Brian Curry
> *Sent:* Thursday, September 03, 2015 7:25 AM
> *To:* mailop@mailop.org
> *Subject:* [mailop] Hotmail/Microsoft Contact Available?
>
>
>
> Is anyone from Microsoft/Hotmail able to help me with a delivery issue
> that has been lingering for months?
>
>
>
> Long story short, I have been going in loops with the normal Hotmail
> support process for months and cannot seem to get a useful answer. IP
> address in question has pulled way back on engagement and I have tested the
> email content outside of the normal IP address and can get it to deliver
> just fine.
>
>
>
> Any help is much appreciated, can contact me off list for me private
> details.
>
>
>
>
>
> Brian Curry
>
> Manager of Deliverability, Digital Messaging
>
> Merkle Inc.
>
> Phone: 720.836.2150
>
> bcu...@merkleinc.com
>
>
>
> This email and any attachments transmitted with it are intended for use by
> the intended recipient(s) only. If you have received this email in error,
> please notify the sender immediately and then delete it. If you are not the
> intended recipient, you must not keep, use, disclose, copy or distribute
> this email without the author’s prior permission. We take precautions to
> minimize the risk of transmitting software viruses, but we advise you to
> perform your own virus checks on any attachment to this message. We cannot
> accept liability for any loss or damage caused by software viruses. The
> information contained in this communication may be confidential and may be
> subject to the attorney-client privilege.
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Delivery to btinternet.com / cpcloud.co.uk

[Gil Bahat]

On Thu, Sep 10, 2015 at 11:29 PM, Brandon Long  wrote:

>
>
> On Thu, Sep 10, 2015 at 6:50 AM, John Levine  wrote:
>
>> >Does anyone understand SRS?  I thought it was pretty much a dead end.
>>
>> It dates from the magic bullet phase of SPF, so yeah.
>>
>> >The reason we rewrite is so that bounces come back to us so we can
>> >automatically disable forwarding if the account we're forwarding to goes
>> >away.
>>
>> Well, actually, you're doing SRS with different syntax.  Local bounce
>> management is one of the few things it does successfully.  The
>> original plan was that you'd forward the bounces back which
>> unsurprisingly turned out not to be a great idea.
>>
>
> Sure, I guess I view all of these as descendents from VERPS, but I guess
> that comes from spending so much time in the mailing list space.
>
>
>> >Which reminds me, I need to ping the spam folks again, that page is still
>> >recommending putting SPAM in the subject, which breaks dkim, which is the
>> >last thing you should do.  I think we're going to support an X-Spam
>> header
>> >instead... except of course that's a violation of RFC 6648.  Anyone want
>> to
>> >recommend a generic header name?
>>
>> Please use X-Spam-Status: which is what Spamassassin adds, and I think
>> several other filter packages.  If you parse RFC 6648 carefully,
>> you'll see that while it tells you not to invent any new X- headers,
>> it says it's OK to keep using the ones that already exist.
>>
>
> Sure, that may make the most sense.  We do usually expose the phishing
> status of the message as well, but I guess that can just be a different
> header for forwarding.
>

It would be most appreciated if you'd populate it on ingress to begin with
and not just when forwarding. it's easier to ask a user which reported an
incident when a mail landed in spam to forward it, rather than ask them to
try to locate the spam reasoning bar in their UI (if it's present at all,
assuming they don't use an MUA, etc...).
many providers and anti-spam packages do that (cloudmark, cyren to name two
off the top of my head), I haven't seen any ill effects to it and the
support benefit is extremely handy. It would also allow third party MUAs to
parse and display this data.

Are there any good reasons not do so? I am trying to think of the cons and
I can't come up with anything really good.

Brandon
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop


Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Hotmail/Microsoft/Outlook - getting their attention

[Gil Bahat]

Perhaps they are suggesting that the process itself needs improvement,
rather than the immediate problem being solved up until the next one.

my personal experience has been somewhat of a toss: At times I have been
able to escalate a noticeable problem to qualified engineers (which happen
to be familiar names on this list, so I didn't need the list) and at other
times (e.g. trying to report a broken DMARC forwarding setup between two
different machines at MS, btw still an open issue) I just couldn't get past
first level tech support...



On Thu, Sep 3, 2015 at 9:13 PM, Michael Wise 
wrote:

> Why do people always redact the critical details?
>
> I keep looking up xxx.xxx.xxx.xxx in the tools, and it keeps telling me
> I’ve made an error.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> *Michael J Wise* | Microsoft | Spam Analysis | "Your Spam Specimen Has
> Been Processed." | Got the Junk Mail Reporting Tool
>  ?
>
>
>
> *From:* Brian Curry [mailto:bcu...@merkleinc.com]
> *Sent:* Thursday, September 3, 2015 11:11 AM
> *To:* Michael Wise ; Marc Perkel <
> supp...@junkemailfilter.com>; mailop@mailop.org
> *Subject:* RE: [mailop] Hotmail/Microsoft/Outlook - getting their
> attention
>
>
>
> Agreed that legal action seems a bit extreme. I am taking the approach
> that Microsoft/Hotmail saw something that said spam was being sent and we
> need to work to correct this.
>
>
>
> I am taking an aggressive approach with the IP to pull way back and the
> recipients that are being sent and monitoring SNDS and complaints like
> crazy and in the last 5 months I just keep getting:
>
>
>
> We have reviewed your IP (*xxx.xxx.xxx.xx*) and determined that messages
> are being filtered (i.e. sent to the Junk folder) based on the
> recommendations of the SmartScreen
> ®
> Filter.
>
> Email filtering is based on many factors, but primarily it's due to mail
> content and recipient interaction with that mail.  Because of the
> proprietary nature of SmartScreen® and because SmartScreen® Filter
> technology is always adapting and learning more about what is and isn't
> unwanted mail, it is not possible for us to offer specific advice about
> improving your mail content. However, in general SmartScreen® Filter
> evaluates specific words or characteristics from each e-mail message and
> weights them, based on their likelihood to indicate that a message is
> unwanted or legitimate mail.
>
> Unfortunately, after reviewing the information you provided and in
> compliance with our mail policies, we are unable to offer immediate
> mitigation for your deliverability issue. However, we have some specific
> recommendations for you to consider that can help you to improve
> deliverability over time.
>
>
>
> Or:
>
>
>
> My name is x and I work with the Outlook.com Deliverability Support
> Team.
>
> We understand that you have additional questions regarding how to improve
> the content of your mail and, thereby, improve deliverability of your email
> to Outlook.com users.
>
> For your background, deliverability to a user's inbox is based on many
> factors including the reputation of the sending IP(s), the format of the
> mail and also user settings and preferences.
>
> After reviewing your case, I have some additional suggestions for you to
> consider that may assist you in the future with avoiding the deliverability
> issue you've been experiencing.
>
>
>
> Not looking for a miracle fix, but somewhere to have a real conversation
> to fix the issues for both sides.
>
>
>
>
>
> Brian Curry
>
> Manager of Deliverability, Digital Messaging
>
> Merkle Inc.
>
>
>
> *From:* mailop [mailto:mailop-boun...@mailop.org
> ] *On Behalf Of *Michael Wise
> *Sent:* Thursday, September 03, 2015 11:38 AM
> *To:* Marc Perkel; mailop@mailop.org
> *Subject:* Re: [mailop] Hotmail/Microsoft/Outlook - getting their
> attention
>
>
>
> When you get LCA involved, or even mention them, things grind to a
> complete halt.
>
> Aloha,
> Michael.
> --
> Sent from my Windows Phone
> --
>
> *From: *Marc Perkel 
> *Sent: *‎9/‎3/‎2015 10:25 AM
> *To: *mailop@mailop.org
> *Subject: *Re: [mailop] Hotmail/Microsoft/Outlook - getting their
> attention
>
> I've had some luck before doing extreme things to get their attention.
> And keep in mind this suggestion is aimed to get their attention.
>
> Lawyers for big corps are generally smart and if someone points out to
> them an issue they can often deal with it before it becomes a lawsuit.
> Same it true of negative publicity. Sales teams can often bring pressure
> to tech staff if the product isn't working and getting bad pres

Re: [mailop] Hotmail/Microsoft Contact Available?

[Gil Bahat]

This looks like the format for FBL complaints and not DMARC complaints.
Note the IP however is in the private use 10.0.0.0/8 block, which means
something is not correct with the setup.

when you get an FBL complaint, you also get a redacted copy of the email.
can you trace back and see if these are indeed your own, or someone else's,
or have a forged receive chain perhaps?

On Thu, Sep 3, 2015 at 9:07 PM, Laura Atkins 
wrote:

>
> > On Sep 3, 2015, at 8:05 AM, Jim Popovitch  wrote:
> >
> > On Thu, Sep 3, 2015 at 10:49 AM, Marc Perkel
> >  wrote:
> >> Hi Brian,
> >>
> >> I'm having problem with Microsoft too. It's just plain weird. Sometimes
> it
> >> takes 6 hours to deliver an email. And I can't quite understand what is
> >> happening.
>
> 6 hours happens. Mail is store and forward, not immediate delivery.
>
> >>
> >> I'm in the front end spam filtering business. Email comes to me - I
> clean it
> >> - and then forward it on to the recipient's server. That includes many
> >> domains hosted at outlook.com. I'm having this problem with all domains
> >> hosted there and only there.
> >>
> >> Who else is seeing this?
> >
> > I'm seeing it for confirmed-opt-in list subscribers using
> > hotmail/live/outlook addrs.
> >
> > And the beauty is I'm getting mailbombed by MS about 1918 addrs:
> >
> >From: st...@hotmail.com
> >To: postmas...@domainmail.org
> >Subject:  complaint about message from 10.162.145.146
>
> Are those complaints or are they DMARC notices?
>
> From discussions in other places, it seems Microsoft is doing an internal
> handoff that’s breaking authentication and a lot of messages are coming
> back as “unauthenticated” or “SPF fail.” This is the kind of message I
> would expect if they’ve really broken things and are actually sending out
> DMARC failure notices.
>
> Otherwise, have you created a JMRPP account with them and are you getting
> complaints? If you haven’t something is really broken. I’d use the publicly
> available postmaster pages to get a ticket opened. If that ticket doesn’t
> work, there are a couple MS employees on the list who may be able to help
> you more directly.
>
> laura
>
>
> --
> Having an Email Crisis?  800 823-9674
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: http://wordtothewise.com/blog
>
>
>
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Hotmail/Microsoft/Outlook - getting their attention

[Gil Bahat]

I wish I had an error message other than the regular/occasional 550 mailbox
unavailable.

I do have one gun that has a wisp of smoke to it: when analyzing FBL
complaints, an overwhelmingly large amount of them (~70% ballpark or so I
believe) are ex post factum FBL complaints coming in bulk: a given user
simply marks a large amount of emails (say from 2 to 10) and marks them all
as spam. I've been getting these for up to 2 months backwards. I have
nicknamed the phenomena 'Complaint amplification'.

the reason I doubt it explains anything is because our complaint rate
should be very very low either way.

On Thu, Sep 3, 2015 at 9:01 PM, Anne Mitchell  wrote:

> If someone can send me actual error messages, along with the IP address
> from which you are sending, we'll see what we can do.
>
> Anne
>
> Anne P. Mitchell,
> Attorney at Law
> CEO/President
> ISIPP SuretyMail Email Reputation, Accreditation & Certification
> Your mail system + SuretyMail accreditation = delivered to their inbox!
> Figure Out if It's Worth It:
> http://www.isipp.com/free-tools/roi-calculator/
> http://www.SuretyMail.com/
> http://www.SuretyMail.eu/
>
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Member, California Bar Cyberspace Law Committee
> Member, Colorado Cybersecurity Consortium
> Ret. Professor of Law, Lincoln Law School of San Jose
> 303-731-2121 | amitch...@isipp.com | @AnnePMitchell
> Facebook/AnnePMitchell  | LinkedIn/in/annemitchell
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Introductions and white listing

[Gil Bahat]

Welcome to the list Marc,

I'll vouch for Marc on being a long time in the filtering business and
being very reasonable to deal with.
For some things, I guess numbers can speak better than words so I offer
these two links:

https://www.intra2net.com/en/support/antispam/blacklist.php_dnsbl=RCVD_IN_JMF_BL.html
https://www.intra2net.com/en/support/antispam/blacklist.php_dnsbl=RCVD_IN_JMF_WHITE.html

from the independent anti-spam testing corpus at intra2net, which is (imho)
a great resource.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Thu, Sep 3, 2015 at 8:57 PM, Marc Perkel 
wrote:

> I suppose I should introduce myself as I'm new to the list.
>
> I'm Marc Perkel. My service is Junk Email Filter. The name says it all. We
> do front end spam filtering, outbound spam filtering, and email hosting.
>
> Glad to be part of this list. Thanks for including me.
>
> And - assuming people on this list all hate spam and want their good email
> delivered - email me privately and I'll get you white listed, or at least
> yellow listed. (yellow means that you send some spam but it keeps you from
> being blacklisted - yahoo, gmail, hotmail - yellow list.) Can list by host
> name (preferred). ex. *.outlook.com FCRDNS required.
>
> And - if you want - feel free to use our DNSBL/DNSWL lists to block
> spam/pass ham.
>
> http://wiki.junkemailfilter.com/index.php/Spam_DNS_Lists
>
> --
> 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
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Hotmail/Microsoft Contact Available?

[Gil Bahat]

Microsoft is also an engagement outlier for us compared to other major
providers, for the same traffic. We have not finished investigation into
the matter yet but I am really interested in your results / resolution.
On Sep 3, 2015 5:29 PM, "Brian Curry"  wrote:

> Is anyone from Microsoft/Hotmail able to help me with a delivery issue
> that has been lingering for months?
>
>
>
> Long story short, I have been going in loops with the normal Hotmail
> support process for months and cannot seem to get a useful answer. IP
> address in question has pulled way back on engagement and I have tested the
> email content outside of the normal IP address and can get it to deliver
> just fine.
>
>
>
> Any help is much appreciated, can contact me off list for me private
> details.
>
>
>
>
>
> Brian Curry
>
> Manager of Deliverability, Digital Messaging
>
> Merkle Inc.
>
> Phone: 720.836.2150
>
> bcu...@merkleinc.com
>
>
>
> This email and any attachments transmitted with it are intended for use by
> the intended recipient(s) only. If you have received this email in error,
> please notify the sender immediately and then delete it. If you are not the
> intended recipient, you must not keep, use, disclose, copy or distribute
> this email without the author’s prior permission. We take precautions to
> minimize the risk of transmitting software viruses, but we advise you to
> perform your own virus checks on any attachment to this message. We cannot
> accept liability for any loss or damage caused by software viruses. The
> information contained in this communication may be confidential and may be
> subject to the attorney-client privilege.
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Gmail's postmaster tools

[Gil Bahat]

Much appreciated, +1.

Registration:
The GWT auth system has capability for delegated access, which other
postmaster consoles (SNDS/mail.ru/yandex) don't implement. activating that
would make it very easy to share this data with our ESP. Another thing you
to consider is to connect that with Google apps for domains, for quick
signup. For us it was a swift signup.

Stream control:
One thing I note is that it will seemingly happily mix Envelope and From
senders. we have 4 major mail streams (Transactional, marketing, corporate,
support) and when I specify 'magisto.com' (from address) I will get all 4
streams. when I specify 'ntdc.magisto.com' I will get only transactional
(our transactional envelope). It would be great if we could separate the
streams somehow. they all use different 'from' senders.
It will also be good to clarify whether the IP reputation refers to our own
traffic segment within a shared IP or the reputation of the shared IP for
all senders using it.

Researching the data:
feature-wise I would rank it much better than SNDS but far behind
mail.ru/yandex.ru consoles. the feature we'd like to see the most is the
ability to partition by identifiers (list_id for yandex /
x-Postmaster-MsgType for mail.ru) or by sender, both of which exist in the
other consoles. If abuse of the data is of concern you may want to limit
'higher resolution' to accounts in good standing.

also significantly appreciated are encryption and auth stats - we've been
wanting to clear our mail streams from unencrypted senders and to deploy a
p=reject DMARC record, this helps a lot and I hope other consoles follow
suit.

All in all this makes a great addition to our toolset and we'll definitely
make use and recommend it.

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Fri, Jul 10, 2015 at 3:12 AM, Brandon Long  wrote:

> We announced our new postmaster tools today.  These are targeted at higher
> volume "good" senders, and give you a bunch of high level stats on the mail
> from your domain that we're seeing.  If you don't have access, your mail is
> either too spammy or you don't send enough of it.
>
> Unfortunately, it re-uses the webmaster tools domain ownership stuff, so
> it's not as easy as say receiving email for postmaster@ your domain...
> you need to be able to muck with DNS.  And it's a separate DNS entry for
> every user, so I don't know if you want to share a single new gmail login
> or something to avoid that or if you want to all sign up at once so you can
> make only a single DNS change with all of them...
>
> And, apparently we don't publish how much volume you need to send to
> qualify and won't see whether your domain qualifies until you verify, so
> sorry if you go through all that trouble and then don't get anything (my
> personal domain doesn't qualify, for example).
>
> Anyways, welcome feedback on the tool and what we can do to improve it,
> I'll be happy to pass it along.  Even more "Arghs" about the annoyances
> I've already outlined ;) (I gave them that feedback already, but perhaps
> more will help)
>
> blog post:
> http://gmailblog.blogspot.com/2015/07/the-mail-you-want-not-spam-you-dont.html
> tool: https://gmail.com/postmaster/
>
> Brandon
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] A strange case of schema.org block

[Gil Bahat]

Hi Everyone,

I found this little gem on my SMTP error logs:

reason: 521 A URL (schema.org) in the email resolved to a blacklisted IP:
521 The IP 216.58.208.46 is Blacklisted by dnsbl.sorbs.net. Dynamic IP
Addresses See: http://www.sorbs.net/lookup.shtml?216.58.208.46 -- .
type: blocked
email: redac...@redacted.com

a quick lookup in SORBS shows a DUHL listing.

so, that does seem braindamaged for so many reasons:

obviously, redacted.com seem to be doing the wrong thing about SORBS. DUHL
doesn't seem intended to stop HTTP hosts.
OTOH, the SORBS entry seems very odd: schema.org is hosted by google, not
really a dynamic range (but with broken PTR record?)

Name: schema.org
Address: 216.58.208.46

46.208.58.216.in-addr.arpa name = lhr08s07-in-f46.1e100.net.
46.208.58.216.in-addr.arpa name = lhr08s07-in-f14.1e100.net.

(ironically, we don't even link to schema.org, we use google's email markup
- that probably many many senders use)

if anyone from google or SORBS is reading this, a fix would be nice. we are
not impacted to any real capacity, but I'd wager it can cause some
unwarranted mail loss at times. other than that, I found this very
interesting and share-worthy.
if you are running another RBL or DNSBL, I think whitelisting schema.org
and its IP is also a prudent thing.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] ancillary email headers causing spam reports at gmail - anyone else encountered this?

[Gil Bahat]

Thinking this can be of public interest, turns out that when enabling
tracking headers, a certain class of messages also got an additional
"From:" header, making it non RFC2822 compliant. This went past the radar
and past a few controls that should have caught it (e.g. an outbound spam
filter).

I'd wager this is a rare incident type, but better error reporting with
regards or better controls at ESPs are something to consider (my own coding
mistake notwithstanding, I admit i'll take any assistance afforded at me to
save me from shooting myself at the foot, so to speak)

The core of the problem is still poor mailing practices which we're working
on rectifying. Thanks to everybody who assisted with this.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto LTd.

On Mon, Jun 1, 2015 at 9:05 PM, Gil Bahat  wrote:

> Thanks Brandon, We actually just got to that realization as well, and in
> hindsight it looks pretty trivial:
>
> We indeed separate different email product functions by different list
> identifications. when we re-activated them, we immediately 'aided' gmail
> (and others) back to discerning our misbehaving functions from our more
> well-behaving ones.
> So, this is actually very good for us, as we can now tell which functions
> are possibly less desired by our users, or causes redundant e-mails, etc.
> it actually makes a case for reactivation - there's no need to risk more
> broad blocks just to push through undesired/problematic e-mails.
>
> From a technical standpoint, I'd imagine any of these headers could
> possibly trigger it but I'd assume that list-id is a solid choice for a
> silo differentiator.
>
> I'll follow-up off-list from here.
>
> Regards,
>
> Gil Bahat,
> DevOps/Postmaster,
> Magisto Ltd.
>
> On Mon, Jun 1, 2015 at 8:54 PM, Brandon Long  wrote:
>
>> I would imagine that list-id or list-unsubscribe would allow for
>> discrimination by the type of mail sent by a sender.  Ie, a host like
>> Google Groups or Yahoo Groups has millions of different silos, and it would
>> make sense to treat those differently.
>>
>> And we definitely combine signals in multiple ways.  You've stripped any
>> identifying information from that response, so I can't investigate more to
>> know what's actually going on, but feel free to contact me off list with
>> more information and I can take a look to see if we have an issue.
>>
>> Brandon
>>
>> On Mon, Jun 1, 2015 at 7:35 AM, Gil Bahat  wrote:
>>
>>> I'll admit to not having done this yet, for three reasons:
>>>
>>> one, given that I found no other references of it here or trawling the
>>> web, it's very likely to be a 'last straw' thing and that there's a much
>>> deeper root cause which needs to be caught first.
>>> two, in relation to one, our toolset is still limited and that includes
>>> our ability to shut down specific headers easily. case in point is that
>>> just bringing those back to life took effort by itself...
>>> and last, I don't want to trouble my users unnecessarily. I don't have
>>> enough pristine gmail boxes available that haven't previously interacted
>>> with this sender so all testing would have to be done at the expense of
>>> users. I'm pretty sure going by that order would yield better results
>>> anyway.
>>>
>>> I think the right way to go about it is like a glacier - assume this
>>> message is representative of x20 more silent rejections and search for a
>>> systematic problem.
>>>
>>> (as an aside, I do have to say it's contradictory to the devops mindset
>>> of (tongue-in-cheek) 'monitoring/log entry or it didn't happen' and it's a
>>> bit jarring to try and maintain the two together).
>>>
>>> Regards,
>>>
>>> Gil Bahat,
>>> DevOps/Postmaster,
>>> Magisto Ltd.
>>>
>>>
>>>
>>> On Mon, Jun 1, 2015 at 5:08 PM, John Levine  wrote:
>>>
>>>> >We've been using these headers for over a year with the previous ESP.
>>>> it is
>>>> >nothing inherent to the headers per se, it's a correlation of these
>>>> headers
>>>> >and other factors. but one of these headers does seem to carry a
>>>> penalty or
>>>> >otherwise skews detection.
>>>>
>>>> When you did experiments removing one header at a time to see which one
>>>> is
>>>> causing trouble, what did you find out?
>>>>
>>>> R's,
>>>> John
>>>>
>>>
>>>
>>> ___
>>> mailop mailing list
>>> mailop@mailop.org
>>> http://chilli.nosignal.org/mailman/listinfo/mailop
>>>
>>>
>>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] ancillary email headers causing spam reports at gmail - anyone else encountered this?

[Gil Bahat]

Thanks Brandon, We actually just got to that realization as well, and in
hindsight it looks pretty trivial:

We indeed separate different email product functions by different list
identifications. when we re-activated them, we immediately 'aided' gmail
(and others) back to discerning our misbehaving functions from our more
well-behaving ones.
So, this is actually very good for us, as we can now tell which functions
are possibly less desired by our users, or causes redundant e-mails, etc.
it actually makes a case for reactivation - there's no need to risk more
broad blocks just to push through undesired/problematic e-mails.

>From a technical standpoint, I'd imagine any of these headers could
possibly trigger it but I'd assume that list-id is a solid choice for a
silo differentiator.

I'll follow-up off-list from here.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Mon, Jun 1, 2015 at 8:54 PM, Brandon Long  wrote:

> I would imagine that list-id or list-unsubscribe would allow for
> discrimination by the type of mail sent by a sender.  Ie, a host like
> Google Groups or Yahoo Groups has millions of different silos, and it would
> make sense to treat those differently.
>
> And we definitely combine signals in multiple ways.  You've stripped any
> identifying information from that response, so I can't investigate more to
> know what's actually going on, but feel free to contact me off list with
> more information and I can take a look to see if we have an issue.
>
> Brandon
>
> On Mon, Jun 1, 2015 at 7:35 AM, Gil Bahat  wrote:
>
>> I'll admit to not having done this yet, for three reasons:
>>
>> one, given that I found no other references of it here or trawling the
>> web, it's very likely to be a 'last straw' thing and that there's a much
>> deeper root cause which needs to be caught first.
>> two, in relation to one, our toolset is still limited and that includes
>> our ability to shut down specific headers easily. case in point is that
>> just bringing those back to life took effort by itself...
>> and last, I don't want to trouble my users unnecessarily. I don't have
>> enough pristine gmail boxes available that haven't previously interacted
>> with this sender so all testing would have to be done at the expense of
>> users. I'm pretty sure going by that order would yield better results
>> anyway.
>>
>> I think the right way to go about it is like a glacier - assume this
>> message is representative of x20 more silent rejections and search for a
>> systematic problem.
>>
>> (as an aside, I do have to say it's contradictory to the devops mindset
>> of (tongue-in-cheek) 'monitoring/log entry or it didn't happen' and it's a
>> bit jarring to try and maintain the two together).
>>
>> Regards,
>>
>> Gil Bahat,
>> DevOps/Postmaster,
>> Magisto Ltd.
>>
>>
>>
>> On Mon, Jun 1, 2015 at 5:08 PM, John Levine  wrote:
>>
>>> >We've been using these headers for over a year with the previous ESP.
>>> it is
>>> >nothing inherent to the headers per se, it's a correlation of these
>>> headers
>>> >and other factors. but one of these headers does seem to carry a
>>> penalty or
>>> >otherwise skews detection.
>>>
>>> When you did experiments removing one header at a time to see which one
>>> is
>>> causing trouble, what did you find out?
>>>
>>> R's,
>>> John
>>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> http://chilli.nosignal.org/mailman/listinfo/mailop
>>
>>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] ancillary email headers causing spam reports at gmail - anyone else encountered this?

[Gil Bahat]

I'll admit to not having done this yet, for three reasons:

one, given that I found no other references of it here or trawling the web,
it's very likely to be a 'last straw' thing and that there's a much deeper
root cause which needs to be caught first.
two, in relation to one, our toolset is still limited and that includes our
ability to shut down specific headers easily. case in point is that just
bringing those back to life took effort by itself...
and last, I don't want to trouble my users unnecessarily. I don't have
enough pristine gmail boxes available that haven't previously interacted
with this sender so all testing would have to be done at the expense of
users. I'm pretty sure going by that order would yield better results
anyway.

I think the right way to go about it is like a glacier - assume this
message is representative of x20 more silent rejections and search for a
systematic problem.

(as an aside, I do have to say it's contradictory to the devops mindset of
(tongue-in-cheek) 'monitoring/log entry or it didn't happen' and it's a bit
jarring to try and maintain the two together).

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.



On Mon, Jun 1, 2015 at 5:08 PM, John Levine  wrote:

> >We've been using these headers for over a year with the previous ESP. it
> is
> >nothing inherent to the headers per se, it's a correlation of these
> headers
> >and other factors. but one of these headers does seem to carry a penalty
> or
> >otherwise skews detection.
>
> When you did experiments removing one header at a time to see which one is
> causing trouble, what did you find out?
>
> R's,
> John
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] ancillary email headers causing spam reports at gmail - anyone else encountered this?

[Gil Bahat]

We've been using these headers for over a year with the previous ESP. it is
nothing inherent to the headers per se, it's a correlation of these headers
and other factors. but one of these headers does seem to carry a penalty or
otherwise skews detection.

and here's where catch-22 strikes: when removing postmaster IDs and
list-ids, we're denying ourselves of one of the best resources to get
feedback on our email activity (the yandex.ru and mail.ru postmaster
consoles). and since this is an ESP migration, SNDS indicators have yet to
stabilize for the IPs and a lot of our toolset has yet to be migrated or
developed...

but at least we know we have a significant problem needs pursing, so we
have that going for us which is nice. sorts of.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Sun, May 31, 2015 at 6:27 PM, Al Iverson 
wrote:

> Well, I think you're going to have to narrow it down to which headers are
> actually causing it, if that's actually the case.
>
> Almost all ESPs add a list-unsub header. We know that alone doesn't cause
> Gmail blocking.
> I also add X-Auto-Response-Suppress and auto-submitted headers to some
> automated reporting output that gets sent a few hundred times a day and I
> know that those aren't getting blocked by Gmail.
> So there's the first few to remove from your testing protocol.
>
> Regards,
> Al Iverson
>
> On Sun, May 31, 2015 at 8:44 AM, Gil Bahat  wrote:
>
>> Hi all,
>>
>> In the process of changing ESPs, we have turned off some ancillary
>> headers until the new backend code supported them.
>> The headers we used (among others) included: list-id (requested by
>> yandex.ru postoffice console, auto-submitted (suggested on this list to
>> quiesce automatic responses), X-Postmaster-Msgtype (requested by mail.ru
>> postmaster console), list-unsubscribe (recommended by gmail best practices)
>> and X-Auto-Response-Suppress (alternative standard for MS systems and
>> clients to quiesce automatic responses)
>>
>> the moment these have been re-instated, google started throwing (at least
>> part) of our emails visibly in MTA logs:
>>
>> 550 5.7.1 [XX.XX.XX.XX 12] Our system has detected that this message is
>> likely unsolicited mail. To reduce the amount of spam sent to Gmail, this
>> message has been blocked. Please visit
>> http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
>> more information.
>>
>> this is baffling. has anyone else ever encountered this situation? why
>> would adding any of these have such a dramatic impact on whether a given
>> e-mail is spam or not?
>>
>> Regards,
>>
>> Gil Bahat,
>> DevOps/Postmaster,
>> Magisto Ltd.
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> http://chilli.nosignal.org/mailman/listinfo/mailop
>>
>>
>
>
> --
> Al Iverson | Minneapolis, MN | (312) 725-0130
> aliverson.com | spamresource.com | @aliverson
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] ancillary email headers causing spam reports at gmail - anyone else encountered this?

[Gil Bahat]

Hi all,

In the process of changing ESPs, we have turned off some ancillary headers
until the new backend code supported them.
The headers we used (among others) included: list-id (requested by yandex.ru
postoffice console, auto-submitted (suggested on this list to quiesce
automatic responses), X-Postmaster-Msgtype (requested by mail.ru postmaster
console), list-unsubscribe (recommended by gmail best practices) and
X-Auto-Response-Suppress (alternative standard for MS systems and clients
to quiesce automatic responses)

the moment these have been re-instated, google started throwing (at least
part) of our emails visibly in MTA logs:

550 5.7.1 [XX.XX.XX.XX 12] Our system has detected that this message is
likely unsolicited mail. To reduce the amount of spam sent to Gmail, this
message has been blocked. Please visit
http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for more
information.

this is baffling. has anyone else ever encountered this situation? why
would adding any of these have such a dramatic impact on whether a given
e-mail is spam or not?

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Daum communications (hanmail korea) contact requested

[Gil Bahat]

FWIW I managed to get a speedy reply by appealing to them directly at
http://cs.daum.net. you will need an @daum.net or @hanmail.net account,
they are free to register although a few hurdles need to be gotten past
(e.g. a korean captcha which I fulfilled using google virtual korean
keyboard). block has been removed in less than 24 hours after approaching
them this way.

Gil

On Tue, May 26, 2015 at 10:11 AM, David Hofstee  wrote:

> Hi Gil,
>
>
>
> I’ve had a reply a few times after let’s say a month or so. After which
> they just unblock (funny when you ask for bad guys you only get unlisted:
> Happens way too often).
>
>
>
>
>
> David Hofstee
>
>
>
> Deliverability Management
>
> MailPlus B.V. Netherlands (ESP)
>
>
>
> *Van:* mailop [mailto:mailop-boun...@mailop.org] *Namens *Gil Bahat
> *Verzonden:* Friday, May 22, 2015 9:01 PM
> *Aan:* mailop@mailop.org
> *Onderwerp:* [mailop] Daum communications (hanmail korea) contact
> requested
>
>
>
> Hi,
>
>
>
> I need a contact at daum / hanmail, we 'inherited' a dedicated IP which
> they blacklisted at their service. the block message actually does mention
> an email address to appeal at, but there are no replies from it for over a
> week now... *sigh* talk about snatching defeat from the jaws of victory.
>
>
>
> Regards,
>
>
>
> Gil Bahat,
>
> Postmaster/DevOps,
>
> Magisto Ltd.
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Daum communications (hanmail korea) contact requested

[Gil Bahat]

Hi,

I need a contact at daum / hanmail, we 'inherited' a dedicated IP which
they blacklisted at their service. the block message actually does mention
an email address to appeal at, but there are no replies from it for over a
week now... *sigh* talk about snatching defeat from the jaws of victory.

Regards,

Gil Bahat,
Postmaster/DevOps,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Anyone from mailchimp here?

[Gil Bahat]

The only thing RSG would understand is if you start blacklisting their IPs
with a vocal message. IMHO, they should be getting treated worse than
Amazon (which is constantly dissed on this list). There is no pole long
enough to touch an RSG product.

On Fri, May 15, 2015 at 8:17 AM, Robert Mueller  wrote:

> Is anyone from mailchimp on this list?
>
> I've got some examples of issues with your sending IPs that I'd like to
> discuss.
>
> Please contact me off list.
>
> Thanks
>
> --
> Rob Mueller
> r...@fastmail.fm
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Anti-spam recommendations for a user-generated-content host

[Gil Bahat]

>From Magisto's perspective, having publicly announced reaching 50 million
users 2.5 months ago, such costs can rack up very, very quickly to tens of
thousands of dollars per month. This applies not just to e-hawk but also to
akismet, to email verification/validation services and to transaction fraud
services. at least the latter can be directly linked to revenue...

At minimum to make this economically viable, we will have to wrap any such
service with our own rudimentary implementation to filter out / downrank
the blatantly bad stuff.
I didn't do this research for signup fraud yet, but for e-mail address
verification there is little point in getting an inflated bill from your
vendor for doing something which you can do in-house cheaply and
efficiently, like maintain a DEA blacklist, good domain whitelist and do
some parked domain detection. And then let the vendor handle the more
complex remaining stuff.

Gil


On Sat, Feb 21, 2015 at 12:13 PM, Paul Kincaid-Smith 
wrote:

> I'm glad you found the UGC blog post useful, Gil.
>
> To make sure I understand your comment on pricing, were you referring to
> E-Hawk's pricing or the costs to integrate other "blocklists and bot
> detection mechanisms?"
>
> What orders of magnitude are you seeing for signups on your service? Seems
> like an interesting problem to solve.
>
> On Thu, Feb 19, 2015 at 2:00 AM, Gil Bahat  wrote:
>
>> Excellent stuff, comprehensive and yet very straightforward. e-hawk in
>> particular seems a great alternative to rolling something on our own and
>> starting to evaluate various blocklists and bot detection mechanisms. can
>> get very very expensive though at our signup rate.
>> I find the idea to apply akismet to outgoing UGC a great one, because
>> 'standard' outbound spam filters don't aim UGC sharing systems, rather they
>> aim at ISPs, ESPs and big webmail providers.
>>
>> Thanks a lot, extremely useful.
>>
>> Gil Bahat,
>> DevOps/Postmaster,
>> Magisto Ltd.
>>
>> On Thu, Feb 19, 2015 at 11:20 AM, Paul Kincaid-Smith 
>> wrote:
>>
>>> Hello Gil,
>>>
>>> I am the postmaster for magisto, an app centered around user generated 
>>> content
>>>> (UGC). we enjoy some popularity, and with popularity comes abuse.
>>>> There are users who utilize magisto to generate content to be used for
>>>> spamvertisement and/or other unsavory content. they will then "invite"
>>>> users to see this content, in an unsolicited fashion, using the
>>>> built-in content invite mechanism.
>>>> 
>>>> in short - recommendations are most welcome, reference to best
>>>> practices or case studies from applicable examples.
>>>>
>>>
>>> Here is a blog post that consolidates my Delivery and Compliance teams'
>>> tips for safely emailing user generated content:
>>> https://sendgrid.com/blog/how-to-safely-email-user-generated-content/
>>> I hope it's helpful to you.
>>>
>>> --Paul
>>>
>>>
>>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Anti-spam recommendations for a user-generated-content host

[Gil Bahat]

Excellent stuff, comprehensive and yet very straightforward. e-hawk in
particular seems a great alternative to rolling something on our own and
starting to evaluate various blocklists and bot detection mechanisms. can
get very very expensive though at our signup rate.
I find the idea to apply akismet to outgoing UGC a great one, because
'standard' outbound spam filters don't aim UGC sharing systems, rather they
aim at ISPs, ESPs and big webmail providers.

Thanks a lot, extremely useful.

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.

On Thu, Feb 19, 2015 at 11:20 AM, Paul Kincaid-Smith 
wrote:

> Hello Gil,
>
> I am the postmaster for magisto, an app centered around user generated content
>> (UGC). we enjoy some popularity, and with popularity comes abuse. There
>> are users who utilize magisto to generate content to be used for
>> spamvertisement and/or other unsavory content. they will then "invite"
>> users to see this content, in an unsolicited fashion, using the built-in
>> content invite mechanism.
>> 
>> in short - recommendations are most welcome, reference to best practices or
>> case studies from applicable examples.
>>
>
> Here is a blog post that consolidates my Delivery and Compliance teams'
> tips for safely emailing user generated content:
> https://sendgrid.com/blog/how-to-safely-email-user-generated-content/
> I hope it's helpful to you.
>
> --Paul
>
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Autoresponse spam - a growing phenomena

[Gil Bahat]

I don't think I have ever seen a message with the Auto-Submitted header. I
will try to run checks whether providers actually do support this, or
that's dead letter, like half of the RFCs out there...
As for outlook.com and office 365, I've seen that they actually do
implement outlook-specific features (e.g. X-MS-Exchange-Organization-PCL on
messages failing DMARC), so I am hopeful that this may get implemented.

additionally, they may have implemented it and I am not in fact seeing real
autoreply, but rather spam disguised as autoreply or autoreply from an MUA
which draws mail via POP/IMAP. it's not easy to tell the two without
conducting quite a bit of testing.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Autoresponse spam - a growing phenomena

[Gil Bahat]

Hi everyone,

I have noted our systems register a rise of auto-response/vacation spam. At
first this was present at mail.ru but I now see it in growing numbers from
yahoo and microsoft too. I wonder why outbound spam filters (which are
surely present at these providers) don't catch and stop this. I think this
could use a more systematic treatment, to rule out worm/trojan systematic
attacks, but I usually didn't get past tier-1 support.

additionally, if all providers were to respect the
non-standard-but-should-be x-auto-response-suppress , it would do well to
stop this from hitting prudent transactional senders. funny thing is, this
is a microsoft-specific (well, outlook-specific) standard and yet not
supported by office online or outlook.com. if anyone is willing to submit
it as RFC, it would be greatly appreciated.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Request for contact at honeypot project

[Gil Bahat]

Hi,

I want to install a custom honey pot at magisto and examine Http:BL for
blocking abusive accounts at magisto. However all my attempts at making
contact with the honeypot project have insofar failed. Any direct contact
details (offlist) will be much appreciated.

Also, if anyone knows of additional blocklists which can suit this usage
(blocking users/registrations), I'd appreciate a tipoff (considering
Spamhaus DROP/EDROP, too)

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] non-delivery messages sent to sender address and not bounce address, by large providers

[Gil Bahat]

Hi,

For mail sent to several large providers, we are receiving non-delivery
messages at sender address instead of bounce address. This is obviously bad
from backscatter point of view and also hampers our ability to handle them
properly (the alias is human-monitored, so automated processing has to be
very delicate. also, these are widely detected as spam or as faked NDRs).

I would have asked for contact information to resolve it, but somehow I
suspect we're neither the first nor the last to encounter this, so maybe it
has been tried before and these providers have been insistent on not
changing their conduct. If anyone has any experience or info to share,
please do.

FWIW here are the providers large enough to make this a bit of a headache,
all the smaller ones not included...

naver.com - largest portal in korea.
qq.com - tencent_qq china, arguably the largest user community in the
world...
ezweb.ne.jp - KDD japan, a popular telco.

Regards,

Gil Bahat,
DevOps/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Gmail admin help requested

[Gil Bahat]

We've had this occurrence when we promoted DMARC to p=quarantine. Some
non-compliant emails were gone entirely while others made it to the spam
folder. not sure it applies to your situation, but I figured it's worth
mentioning.

On Mon, Jan 19, 2015 at 6:56 PM, Lyle Giese  wrote:

> I have discovered that some emails are disappearing inside gmail.
>
> I have logs of one such email that disappeared.  It shows the 250 reply
> from google, but email doesn't get to inbox or spam filter.
>
> Looking for assistance from Gmail.
>
> Thanks,
> Lyle Giese
> LCR Computer Services, Inc.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] Anti-spam recommendations for a user-generated-content host

[Gil Bahat]

Aside from the inline response, I guess I could approach several of the
ISPs who bulked some of our messages and try to affirm if it's UGC spam or
not. if anyone got any contacts at laposte.net or orange.fr (offlist
please), IIRC they bulked us a bit on invites.

On Mon, Jan 19, 2015 at 10:22 PM, Jay Hennigan 
wrote:

> On 1/19/15 5:18, Gil Bahat wrote:
> >
> > I am the postmaster for magisto, an app centered around user generated
> > content (UGC). we enjoy some popularity, and with popularity comes
> > abuse. There are users who utilize magisto to generate content to be
> > used for spamvertisement and/or other unsavory content. they will then
> > "invite" users to see this content, in an unsolicited fashion, using the
> > built-in content invite mechanism.
>
> Perhaps some form of rate-limiting on the invite mechanism would help.


if we had no rate limiting, it would be spam hell (or haven, depending on
your viewpoint). but if we set it too low, we start hurting our business,
especially with content going viral. my goal is to see that even continuous
drip-spam that maxes the rate gets dealt with swiftly. I want this stuff
off my network and to make myself as least lucrative to spammers as
possible.


> > even if they incorporate it outside the invite mechanism, magisto still
> > serves as a "hosting server" for their content.
> >
> > Ideally, internal user reporting would be sufficient to combat it, but
> > in reality it isn't: both because users submit many false reports and
> > because such a system doesn't scale.
>
> How do you handle user reporting? Is there an option on the content page
> to flag it as having been spamvertized? Regarding false reports, a
> percentage to trigger review or more aggressively rating flagged content
> that has been recently uploaded might help.


There is an option to flag content for review, currently no canned reason
selection though, just a free text reason field. people report a lot of
random stuff for no obvious reasons and no text entered. the problem
becomes operator overload. being a tad paranoid, I consider the option it's
not coincidental and someone is testing us.


>
> > DMARC can't help with regards - the messages are either entirely 'valid'
> > invite messages, or otherwise do not involve our domain.
> > FBL data can help, to an extent - but is again not relevant for the
> > second use case or for users spamming a provider which has no
> > FBL offered, or gmail who provide aggregate data only.
> > Spamtrap data is generally out of reach for us - so I can't estimate its
> > suitability to hunt these down. I suspect it will help somewhat, but not
> > by much.
>
> It might be useful for the internal invite case, especially if you
> incorporate a delay of sending bulk invites until checked against
> spamtraps.


that's a very good idea. but I have found verification services costly and
only so reliable. real spamtrap data is even more expensive, assuming we
will qualify.


> > Services such as spamcop will not provide data to us, for the concern
> > that we may listwash since we are not netblock owners. but again this
> > will only give partial coverage.
>
> Perhaps work with your upstream to have such reports forwarded to you?
>

We run on amazon EC2, not a welcome host at spamcop. I inquired what would
happen if we signed up for cloudflare, and they aren't welcome on spamcop
either. maybe incapsula could work (same as cloudflare from the hosting
perspective, they hide the real origin for security purposes), but there
are some stipulations about the information not being passed to us as is or
something for fears of listwashing. Couldn't quite get a hold on what they
would and wouldn't be able to share with us.


> --
> Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
> Impulse Internet Service  -  http://www.impulse.net/
> Your local telephone and internet company - 805 884-6323 - WB6RDV
>
> ___
> mailop mailing list
> mailop@mailop.org
> http://chilli.nosignal.org/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] Anti-spam recommendations for a user-generated-content host

[Gil Bahat]

(apologies in advance if this ends up a double-post)

Hello everyone,

I am the postmaster for magisto, an app centered around user generated content
(UGC). we enjoy some popularity, and with popularity comes abuse. There are
users who utilize magisto to generate content to be used for
spamvertisement and/or other unsavory content. they will then "invite"
users to see this content, in an unsolicited fashion, using the
built-in content
invite mechanism.

even if they incorporate it outside the invite mechanism, magisto still
serves as a "hosting server" for their content.

Ideally, internal user reporting would be sufficient to combat it, but in
reality it isn't: both because users submit many false reports and because
such a system doesn't scale.

DMARC can't help with regards - the messages are either entirely 'valid'
invite messages, or otherwise do not involve our domain.
FBL data can help, to an extent - but is again not relevant for the second
use case or for users spamming a provider which has no FBL offered, or
gmail who provide aggregate data only.
Spamtrap data is generally out of reach for us - so I can't estimate its
suitability to hunt these down. I suspect it will help somewhat, but not by
much.
Services such as spamcop will not provide data to us, for the concern that
we may listwash since we are not netblock owners. but again this will only
give partial coverage.
outbound mail filters are also at a loss to detect these, as the spam part
is in the destination page and specifically is a video in the case of magisto.
they also don't apply to the second use case.

in short - recommendations are most welcome, reference to best practices or
case studies from applicable examples. it's even hard to map properly, but
I suspect it's happening already as i'm seeing a tad higher rejection rate on
invites to watch content.

Regards,

Gil Bahat,
Devops/Postmaster,
Magisto Ltd.
___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop