[mailop] Is there a MimeCast rep in the house?

[Michael Wise via mailop]

Please reply off-list, thanks!

Aloha,
Michael.
--
Michael J Wise | Microsoft | Spam Analysis | "Your Spam Specimen Has Been 
Processed." | Got the Junk Mail Reporting 
Tool ?

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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Laura Atkins]

> On Jun 9, 2016, at 2:07 PM, Bernhard Schmidt  wrote:
> 
> On 09.06.2016 18:20, Laura Atkins wrote:
>> 
>>> On Jun 9, 2016, at 9:06 AM, Bernhard Schmidt  
>>> wrote:
>>> 
>>> Header-From and Envelope-From are aligned, the sending domain does not
>>> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
>>> not rolled out for all domains yet. The hosts in question do have proper
>>> FCrDNS, i.e.
>>> 
>>> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
>>> 
>>> Anyone seeing the same? From outside it looks like Google has
>>> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
>>> authenticated" previously done by Microsoft, but without the softfail.
>> 
>> Yes. They have. They do not accept unauthenticated mail over v6. All you 
>> need to do is publish a SPF record and you should be good to go.
> 
> Adding an SPF record for some remote understaffed downstream university
> institute is not that easy if you don't know where their mail flows
> might come from. Forcing SPF on them might do more harm than good.

I didn’t notice it was a university. That I know how problematic it is to get 
control of a .edu domain and all the different campus servers and individual 
servers run by faculty and staff and such. Had I know I probably wouldn’t have 
recommended that.  

> I had experimented a bit this evening and was about to complain that an
> SPF record ending in ?all (and +all, but I expected that) did not help
> reverting to the previous behaviour, but all of the sudden all IPv6 mail
> seems to be accepted again. Even sending from hosts matching ~all or
> domains without SPF seem to be fine. They are properly tagged as
> spf=neutral or spf=softfail, but happily forwarded into the mailbox.
> 
> Not sure yet whether my testhost has ended up on a whitelist or Google
> has reverted the behaviour.

There was a report earlier that Google was experiencing authentication problems 
on the inbound and a lot of mail was failing. I’m guessing what you saw was 
related to that and it’s been fixed now. 

> For the record, I'm not against tighening the rules for email delivery.
> We have been plainly rejecting mails not only on missing PTR but also on
> mismatching FCrDNS on SMTP level for years now, both in IPv4 and IPv6,
> and have been advocating this to others. Although I'm not happy about it
> I can also get and work around the Microsoft approach of tempfailing
> messages without DKIM/SPF, since I can get the mailer to retry on IPv4
> while we sort out domain by domain. But the Google approach of
> hard-rejecting these mails places a huge burden of those who still have
> to run the classic smarthost relays for hundreds of on-campus MTAs with
> their own domains and own management, leaving them effectively no choice
> but to completely disable IPv6 outbound until all possible sender
> domains are fixed.

That may be a solution. Route the bulk of your mail through your v4 IPs and 
then only move them to v6 as they are authenticated.

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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Bernhard Schmidt]

On 09.06.2016 18:20, Laura Atkins wrote:
> 
>> On Jun 9, 2016, at 9:06 AM, Bernhard Schmidt  wrote:
>>
>> Header-From and Envelope-From are aligned, the sending domain does not
>> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
>> not rolled out for all domains yet. The hosts in question do have proper
>> FCrDNS, i.e.
>>
>> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
>>
>> Anyone seeing the same? From outside it looks like Google has
>> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
>> authenticated" previously done by Microsoft, but without the softfail.
> 
> Yes. They have. They do not accept unauthenticated mail over v6. All you need 
> to do is publish a SPF record and you should be good to go.

Adding an SPF record for some remote understaffed downstream university
institute is not that easy if you don't know where their mail flows
might come from. Forcing SPF on them might do more harm than good.

I had experimented a bit this evening and was about to complain that an
SPF record ending in ?all (and +all, but I expected that) did not help
reverting to the previous behaviour, but all of the sudden all IPv6 mail
seems to be accepted again. Even sending from hosts matching ~all or
domains without SPF seem to be fine. They are properly tagged as
spf=neutral or spf=softfail, but happily forwarded into the mailbox.

Not sure yet whether my testhost has ended up on a whitelist or Google
has reverted the behaviour.

For the record, I'm not against tighening the rules for email delivery.
We have been plainly rejecting mails not only on missing PTR but also on
mismatching FCrDNS on SMTP level for years now, both in IPv4 and IPv6,
and have been advocating this to others. Although I'm not happy about it
I can also get and work around the Microsoft approach of tempfailing
messages without DKIM/SPF, since I can get the mailer to retry on IPv4
while we sort out domain by domain. But the Google approach of
hard-rejecting these mails places a huge burden of those who still have
to run the classic smarthost relays for hundreds of on-campus MTAs with
their own domains and own management, leaving them effectively no choice
but to completely disable IPv6 outbound until all possible sender
domains are fixed.

Bernhard

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

Re: [mailop] Microsoft/Hotmail discards mails

[Rich Kulawiec]

On Thu, Jun 09, 2016 at 09:25:00AM +0100, Paul Smith wrote:
> I'd have thought that even if you do decide to just throw "extreme"
> junk away (which I think is a very bad idea, BTW), then you should
> tell the user that you've done so - either in a daily/weekly summary
> email or an online list or something. That seems to be the bare
> minimum for an MSP to do in such a case.

A better idea is to just reject it at connection time.  One of the
fundamental principles of mail system defense is that you *will*
make mistakes, so you should make them definitively, make them
consistently, make them as early as possible, and make them noisily.
For example: silently discarding an already-accepted message is horrible.
Rejecting it with a 550 and appropriate error message during the delivery
attempt is excellent.  It's better for everyone because it creates log
entries that can be found, read, and understood on both sides and thus
makes it possible to locate and correct a mistake -- if in fact it *is*
a mistake.

---rsk

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

Re: [mailop] I trust my candor is appreciated...?

[Anne Mitchell]

> If the traffic is Transactional, by all means open a ticket and push it. It 
> is always the best plan to keep Transactional traffic strictly separate from 
> all other traffic, and if there are issues, point the nature of said traffic 
> out in follow-up emails, as once validated, it will factor in the mitigation 
> decision.

Absolutely.  In fact, not only do we encourage (strongly) our email 
reputation/deliverability customers to segregate their transactional email out 
from their marketing/bulk email, but we actually have a special code in our 
zones to designate "this IP address sends only transactional emails" so that 
receivers and spam filters can take note of that (in fact I believe we still 
have a special rule in Spam Assassin for this very thing and reason).

Anne


Anne P. Mitchell, Esq.
CEO/President, 
SuretyMail Email Reputation and Inbox Deliverability Assistance 
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Don't have your own dedicated IP addresses?  
Check out SuretyMail Lite! 
Email Reputation and Deliverability for Everyone
http://www.isipp.com/suretymail-lite/


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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Franck Martin via mailop]

On Thu, Jun 9, 2016 at 11:48 AM, Michael Peddemors 
wrote:

> On 16-06-09 11:26 AM, Franck Martin via mailop wrote:
>
>> As people pointed out, an SPF record is easy to set and fast to solve
>> the issue, DKIM can come later...
>>
>
> Hehehe... 'easy' is a relative word, amazing how many poor SPF records are
> out there, and sometimes it is hard enough to get email operators to even
> have proper PTR records..
>
> There has been little pain so far, stupid things have happened and there
were barely any difference...
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Michael Peddemors]

On 16-06-09 11:26 AM, Franck Martin via mailop wrote:

As people pointed out, an SPF record is easy to set and fast to solve
the issue, DKIM can come later...


Hehehe... 'easy' is a relative word, amazing how many poor SPF records 
are out there, and sometimes it is hard enough to get email operators to 
even have proper PTR records..





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Franck Martin via mailop]

It is a M3AAWG best practice to not accept unauthenticated emails over
IPv6, Microsoft does it, we do it, Google too...
https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf

It is also likely that bad stuff (less visible for the sender) is also
happening to unauthenticated emails over IPv4. There is only 3% of "good"
emails that are unauthenticated (true it is from the long tail of sending
domains but...):
https://security.googleblog.com/2013/12/internet-wide-efforts-to-fight-email.html

As people pointed out, an SPF record is easy to set and fast to solve the
issue, DKIM can come later...

On Thu, Jun 9, 2016 at 9:38 AM, Bernhard Schmidt 
wrote:

> On 09.06.2016 18:18, Hugo Slabbert wrote:
>
> Hi,
>
> >> since around 13:00 UTC today all of the sudden we see massive rejects of
> >> mails towards Google when delivering on IPv6
> >>
> >> Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
> >> to=,
> >> relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
> >> delays=0.01/0/0.16
> >> /0.53, dsn=5.7.1, status=bounced (host
> >> gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
> >> message does not have authentication information or fails to pass
> >> 550-5.7.1 authentication checks. To best protect our users from spam,
> >> the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
> >> https://support.google.com/mail/answer/81126#authentication for m
> >> ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
> >> of DATA command))
> >>
> >> Header-From and Envelope-From are aligned, the sending domain does not
> >> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
> >> not rolled out for all domains yet. The hosts in question do have proper
> >> FCrDNS, i.e.
> >>
> >>
> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
> >>
> >>
> >> Anyone seeing the same? From outside it looks like Google has
> >> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
> >> authenticated" previously done by Microsoft, but without the softfail.
> >
> > ...hasn't this been the case for some time?  They want FCrDNS + at least
> > one of SPF or DKIM to accept delivery over v6:
> >
> > https://support.google.com/mail/answer/81126?hl=en#authentication
> >
> > Did they just defer previously?
>
> Mail was accepted just fine until three hours ago. There is a large
> difference between "The sending domain should pass either SPF check or
> DKIM check. Otherwise, mail might be marked as spam." and outright
> rejecting 100% of it.
>
> We've been working on SPF/DKIM for quite some time now. Unfortunately
> this is not that easy with hundreds of faculty-operated servers/domains,
> some of them not even on our nameservers. This has de-facto killed IPv6
> outbound completely for us. Microsoft tempfailing was annoying enough
> but manageable.
>
> Best Regards,
> Bernhard
>
> ___
> 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

[Steve Atkins]

> On Jun 9, 2016, at 11:07 AM, John Levine  wrote:
> 
>>> List-Unsubcribe: 
>>> List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023
> 
>> If there is a requirement from MUA developers for an https-based 
>> non-interactive unsubscribe - and
>> researching whether that's the case and what their actual requirements are 
>> would be the first step - then I'm
>> sure the IETF would be open to a standard to include that metadata in an 
>> email, outside the RFC 2369 set of
>> headers.
> 
> When you click the spam button in gmail, it often asks whether you
> want to unsubscribe as well as mark it as spam.  That seems like
> a pretty strong use case for this.

But also an argument that the existing List-Unsubscribe system - which is what 
Gmail use for that - is good enough for that use case.

Something better defined would be better, but List-Unsubscribe using mailto: 
URLs is working fine for non-interactive unsubscription today.

> 
>> A new RFC, or an extension of RFC 2369 to add a new List-Something header 
>> would make the whole idea cleaner
>> and more robust than imposing structure on the existing List-Unsubscribe 
>> process, and wouldn't have much
>> significant impact on rollout (as it doesn't change significantly the amount 
>> of new code needing to be
>> deployed at both ends of the protocol to support it).
> 
> That was my thought.

Yup. If this were done properly - as a well-designed protocol rather than a 
gross hack - it'd be a useful thing to work on.

> 
>> [2] I like the idea of an MUA with a "meh" button that asks list senders to 
>> send less meh mail, or
>> unsubscribe me if they can't manage that.
> 
> I doubt there are enough mailers that would interpret that reasoanbly
> to be worthwhile.  The ESPs I know don't think they send any meh mail.

User preference modeling and targeting is huge in other areas. It's what Amazon 
and Netflix are based on, for instance. I suspect that smart email marketers 
would jump at the idea (and the smart ones tend to be successful and 
influential). Whether the MUA developers would care is a whole other thing.

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

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

[John Levine]

>> List-Unsubcribe: 
>> List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023

>If there is a requirement from MUA developers for an https-based 
>non-interactive unsubscribe - and
>researching whether that's the case and what their actual requirements are 
>would be the first step - then I'm
>sure the IETF would be open to a standard to include that metadata in an 
>email, outside the RFC 2369 set of
>headers.

When you click the spam button in gmail, it often asks whether you
want to unsubscribe as well as mark it as spam.  That seems like
a pretty strong use case for this.

>A new RFC, or an extension of RFC 2369 to add a new List-Something header 
>would make the whole idea cleaner
>and more robust than imposing structure on the existing List-Unsubscribe 
>process, and wouldn't have much
>significant impact on rollout (as it doesn't change significantly the amount 
>of new code needing to be
>deployed at both ends of the protocol to support it).

That was my thought.

>[2] I like the idea of an MUA with a "meh" button that asks list senders to 
>send less meh mail, or
>unsubscribe me if they can't manage that.

I doubt there are enough mailers that would interpret that reasoanbly
to be worthwhile.  The ESPs I know don't think they send any meh mail.

R's,
John

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

Re: [mailop] Contact at Mailchimp?

[Jay Hennigan]

On 6/9/16 8:50 AM, Al Iverson wrote:

Wouldn't ab...@mailchimp.com be a better place for a non-customer to
contact them about an email issue? They've been very responsive to me
via that address.


Yes, got it resolved. This had nothing to do with abuse from Mailchimp 
but horrible behavior on the part of Symantec's spam filtering service.


Long story short, we've whitelisted mcdlv.net with Symantec. Spammers 
sending from their own domains (with valid DKIM for the spammer) but 
forging message-IDs to end in mcdlv.net were getting through due to 
whitelist. Attempts to get Symantec to fix it were futile.


Needed Mailchimp's outbound CIDRs to modify whitelist for IPs rather 
than domain so wrote to ask them.


Was quite taken aback by the extreme reluctance to respond to email by a 
company in the email business. All done.


--
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
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Contact at Mailchimp?

[Joey Rutledge]

Hi Al,

Yup, ab...@mailchimp.com and postmas...@mailchimp.com should both get a person 
and is always a good way for customers and especially non-customers to get in 
touch with us; although if it’s a customer support issue we’ll find a way to 
get them over to the right area.  We got rid of free support a while back and 
that’s why Jay mentioned the ignore-bot link response to support@.

Joey


> On Jun 9, 2016, at 11:50 AM, Al Iverson  wrote:
> 
> Wouldn't ab...@mailchimp.com be a better place for a non-customer to
> contact them about an email issue? They've been very responsive to me
> via that address.
> 
> Regards,
> Al Iverson
> 
> --
> Al Iverson
> www.aliverson.com
> (312)725-0130
> 
> 
> On Wed, Jun 8, 2016 at 7:48 PM, Joey Rutledge  wrote:
>> Hi Jay,
>> 
>> Happy to help.  I work on the delivery team at MailChimp.  Feel free to 
>> email me offlist if you’d prefer.  joeyrutle...@gmail.com
>> 
>> Joey Rutledge
>> 
>>> On Jun 8, 2016, at 7:25 PM, Jay Hennigan  wrote:
>>> 
>>> Anyone from Mailchimp on-list? support@mailchimp now auto-returns an 
>>> ignore-bot with a link that points to a webpage with no useful options.
>>> 
>>> Why are people in the email business so difficult to reach by email?
>>> 
>>> --
>>> 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
>>> 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] "One-Click" List-Unsubscribe URIs

[Shawn K. Hall]

+1. This was what I was thinking when I read it, too.

-S
 

> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of 
> John Levine
> Sent: Thursday, June 09, 2016 09:11
> To: mailop@mailop.org
> Cc: tobias.herk...@optivo.de
> Subject: Re: [mailop] "One-Click" List-Unsubscribe URIs
> 
> >It's a public document and I welcome requests with updates...
> >https://github.com/Lockhead/oneclick/blob/master/draft-herkul
> a-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
>  List-Unsubcribe: 
>  List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.
> 
> R's,
> John
> 
> ___
> 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

[Al Iverson]

On Thu, Jun 9, 2016 at 12:24 PM,   wrote:
> On Thu, 9 Jun 2016 11:53:16 -0400
> Al Iverson  wrote:
>
>> This also brings us back to the issue of what happens when security
>> devices or services click the link, instead of the subscriber. In this
>> scenario, it sounds like it would cause an unsubscribe that was not
>> actually requested by the recipient. I think that is suboptimal.
>
> No it doesn't, the solution described in the document especially solves
> this issue.

I think it is an insufficient solution that potentially allows a
security device developer or service to build one click URLs just as
easily as the ISP could. So it's got two things that I don't like.
1- You're requiring the ISP to identify and include a token in the URL
- I don't think they should have to build something.
2- What's being built is just as easily added in by any security
device who decides they know better than the subscriber and want to
cause that unsubscribe.

Cheers,
Al Iverson



--
Al Iverson
www.aliverson.com
(312)725-0130

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

Re: [mailop] Microsoft/Hotmail discards mails

[Shawn K. Hall]

> You're saying that, simply because a sender or recipient 
> MIGHT be in Germany, that my US-based mail server has to send 
> an NDR? And risk getting added to a "backscatter" RBL?

No, you also have the option of delivering it to the user in a method
that equates to delivery, such as delivering to their spam/junk folder.

-S


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

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

[Steve Atkins]

> On Jun 9, 2016, at 9:11 AM, John Levine  wrote:
> 
>> It's a public document and I welcome requests with updates...
>> https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
> List-Unsubcribe: 
> List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.

+1.

(recycling my comments from the last time this was suggested, in a different 
forum)

List-Unsubscribe: is poorly defined (at least for http links) yet widely 
supported. mailto: links are for non-interactive use, http: links are (almost 
always) for interactive use. Any attempt to change that risks causing problems 
with a deployed base - it's not a versioned nor extensible protocol. Extending 
the behaviour with hidden magic doesn't seem like a clean solution to the 
problem, even if the magic "shouldn't" cause any problems with existing code[1].

If there is a requirement from MUA developers for an https-based 
non-interactive unsubscribe - and researching whether that's the case and what 
their actual requirements are would be the first step - then I'm sure the IETF 
would be open to a standard to include that metadata in an email, outside the 
RFC 2369 set of headers.

A new RFC, or an extension of RFC 2369 to add a new List-Something header would 
make the whole idea cleaner and more robust than imposing structure on the 
existing List-Unsubscribe process, and wouldn't have much significant impact on 
rollout (as it doesn't change significantly the amount of new code needing to 
be deployed at both ends of the protocol to support it).

That also opens up the option of implementing what MUA developers and list 
operators can agree on as a useful protocol rather than a single feature wedged 
into an existing one. As I'm not a list operator or an MUA developer I don't 
have particular things I'd want there, but I can imagine "send me no more mail 
like this / remove me from this list", "send me no more mail at all / suppress 
me from all lists" and maybe even "send me less mail like this"[2] as some 
possibilities.

Cheers,
 Steve

[1] Assuming that ad-hoc clients will strip off URL fragments or that servers 
will ignore them if they don't is reasonable in a spec sense, but may be 
optimistic when it comes to deployed code.

[2] I like the idea of an MUA with a "meh" button that asks list senders to 
send less meh mail, or unsubscribe me if they can't manage that.

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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Bernhard Schmidt]

On 09.06.2016 18:18, Hugo Slabbert wrote:

Hi,

>> since around 13:00 UTC today all of the sudden we see massive rejects of
>> mails towards Google when delivering on IPv6
>>
>> Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
>> to=,
>> relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
>> delays=0.01/0/0.16
>> /0.53, dsn=5.7.1, status=bounced (host
>> gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
>> message does not have authentication information or fails to pass
>> 550-5.7.1 authentication checks. To best protect our users from spam,
>> the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
>> https://support.google.com/mail/answer/81126#authentication for m
>> ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
>> of DATA command))
>>
>> Header-From and Envelope-From are aligned, the sending domain does not
>> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
>> not rolled out for all domains yet. The hosts in question do have proper
>> FCrDNS, i.e.
>>
>> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
>>
>>
>> Anyone seeing the same? From outside it looks like Google has
>> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
>> authenticated" previously done by Microsoft, but without the softfail.
> 
> ...hasn't this been the case for some time?  They want FCrDNS + at least
> one of SPF or DKIM to accept delivery over v6:
> 
> https://support.google.com/mail/answer/81126?hl=en#authentication
> 
> Did they just defer previously?

Mail was accepted just fine until three hours ago. There is a large
difference between "The sending domain should pass either SPF check or
DKIM check. Otherwise, mail might be marked as spam." and outright
rejecting 100% of it.

We've been working on SPF/DKIM for quite some time now. Unfortunately
this is not that easy with hundreds of faculty-operated servers/domains,
some of them not even on our nameservers. This has de-facto killed IPv6
outbound completely for us. Microsoft tempfailing was annoying enough
but manageable.

Best Regards,
Bernhard

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

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

[tobias.herkula]

On 9 Jun 2016 16:11:17 -
"John Levine"  wrote:

> >It's a public document and I welcome requests with updates...
> >https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
> 
> Hmmn.  One the one hand, I'm definitely in favor of making it as easy
> as possible for people to make the mail go away.
> 
> On the other hand, this particular proposal is a horrible misuse of
> both http GET and of the list-unsubscribe header.  The http specs are
> quite clear that GET is not supposed to change the state on the web
> server.  For that you use POST or PUT.  It is also a bad idea to try
> to redefine the List-Unsubscribe header which has meant the same thing
> for 18 years.
> 
> Fortunately, this is not hard to fix.  Let's invent a new header,
> list-unsubscribe-post, which one can use in conjunction with
> list-unsubscribe, e.g.
> 
>  List-Unsubcribe: 
>  List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023
> 
> This says to do a POST to the URL in the list-unsubscribe, with the
> fields in the list-unsubscribe-post as the data to the POST.  MUAs
> that don't understand the new field can still do a GET to the URL
> which will do whatever it does, probably show you a page with a
> confirmation button that does a POST.
> 
> This should be easy to implement, since I've never seen an http
> library that could do GET that can't also do POST, and this avoids
> both the semantic problem of GET, and the unintended unsubs by
> filterware that poke all the URLs just to see what will happen.
> 
> R's,
> John
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

I'm not a friend of "new" Headers and I can't really see why this
document will change any meaning of the standard, RFC2369 already
states:

"Each field typically contains a URL (usually mailto [RFC2368])
locating the relevant information or performing the command directly."

and

"The List-Unsubscribe field describes the command (preferably using
mail) to directly unsubscribe the user (removing them from the list)."

So it doesn't change any meaning of the standard, I'm aware of the fact
that there are entities out in the net that handle this differently but
the standard is pretty clear.

The document describes how to signal this functionality to make sure
the receiver knows that this link can be used as a "oneclick" and it
also hinders "dump" clients who simple GET every link to trigger the
action.

I'm sure we should argue about the GET vs. POST thing as this is for
sure very difficult to solve, if we stick by RFC you are totally right,
POST, PUT or even DELETE are the right verbs to use. I would rule out
PUT and DELETE because not every lib implements it. On the other side,
every tracking link in commercial mails changes STATE and they are
never requested by POST...


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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Hugo Slabbert]

On Thu 2016-Jun-09 18:21:17 +0200, Sebastian Hagedorn  
wrote:

Hi,


since around 13:00 UTC today all of the sudden we see massive rejects of
mails towards Google when delivering on IPv6

Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
to=,
relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
delays=0.01/0/0.16
/0.53, dsn=5.7.1, status=bounced (host
gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
message does not have authentication information or fails to pass
550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for m
ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
of DATA command))

Header-From and Envelope-From are aligned, the sending domain does not
have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
not rolled out for all domains yet. The hosts in question do have proper
FCrDNS, i.e.

http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Af
f89.html

Anyone seeing the same? From outside it looks like Google has
implemented the "all mail delivered over IPv6 has to be DKIM/SPF
authenticated" previously done by Microsoft, but without the softfail.


FWIW: we deliver via IPv6 to Google, and we are currently not 
affected. We don't yet use DKIM, but we do have an SPF record that 
advertises both our IPv4 and our IPv6 subnets. Of course I don't know 
if that's the reason our mails are accepted.


Yes, it is.  It's right there in their policy:

https://support.google.com/mail/answer/81126?hl=en#authentication


Additional guidelines for IPv6

...

The sending domain should pass ***either*** SPF check or DKIM check.  
Otherwise, mail might be marked as spam.


(emphasis mine)



Cheers
Sebastian
--
Sebastian Hagedorn - Postmaster - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universität zu Köln / Cologne University - Tel. +49-221-470-89578


--
Hugo

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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Lyle Giese]

On 6/9/2016 11:21 AM, Sebastian Hagedorn wrote:

Hi,


since around 13:00 UTC today all of the sudden we see massive rejects of
mails towards Google when delivering on IPv6

Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
to=,
relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
delays=0.01/0/0.16
/0.53, dsn=5.7.1, status=bounced (host
gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
message does not have authentication information or fails to pass
550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for m
ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
of DATA command))

Header-From and Envelope-From are aligned, the sending domain does not
have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
not rolled out for all domains yet. The hosts in question do have proper
FCrDNS, i.e.

http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Af 


f89.html

Anyone seeing the same? From outside it looks like Google has
implemented the "all mail delivered over IPv6 has to be DKIM/SPF
authenticated" previously done by Microsoft, but without the softfail.


FWIW: we deliver via IPv6 to Google, and we are currently not 
affected. We don't yet use DKIM, but we do have an SPF record that 
advertises both our IPv4 and our IPv6 subnets. Of course I don't know 
if that's the reason our mails are accepted.


Cheers
Sebastian
--
Sebastian Hagedorn - Postmaster - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universität zu Köln / Cologne University - Tel. +49-221-470-89578
Here, we have always had proper reverse entries for IPv4 and IPv6 and 
have been delivering to gmail for a couple of years over IPv6. And yes 
today we are also effected.  Looks like publishing an SPF record is 
enough to clear this issue.


Lyle Giese
LCR Computer Services, Inc.


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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Laura Atkins]

> On Jun 9, 2016, at 9:06 AM, Bernhard Schmidt  wrote:
> 
> Header-From and Envelope-From are aligned, the sending domain does not
> have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
> not rolled out for all domains yet. The hosts in question do have proper
> FCrDNS, i.e.
> 
> http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html
> 
> Anyone seeing the same? From outside it looks like Google has
> implemented the "all mail delivered over IPv6 has to be DKIM/SPF
> authenticated" previously done by Microsoft, but without the softfail.

Yes. They have. They do not accept unauthenticated mail over v6. All you need 
to do is publish a SPF record and you should be good to go.

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

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

[tobias.herkula]

On Thu, 9 Jun 2016 11:53:16 -0400
Al Iverson  wrote:

> This also brings us back to the issue of what happens when security
> devices or services click the link, instead of the subscriber. In this
> scenario, it sounds like it would cause an unsubscribe that was not
> actually requested by the recipient. I think that is suboptimal.
> 
> Regards,
> Al Iverson
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

No it doesn't, the solution described in the document especially solves
this issue.


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

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Sebastian Hagedorn]

Hi,


since around 13:00 UTC today all of the sudden we see massive rejects of
mails towards Google when delivering on IPv6

Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
to=,
relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
delays=0.01/0/0.16
/0.53, dsn=5.7.1, status=bounced (host
gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
message does not have authentication information or fails to pass
550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for m
ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
of DATA command))

Header-From and Envelope-From are aligned, the sending domain does not
have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
not rolled out for all domains yet. The hosts in question do have proper
FCrDNS, i.e.

http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Af
f89.html

Anyone seeing the same? From outside it looks like Google has
implemented the "all mail delivered over IPv6 has to be DKIM/SPF
authenticated" previously done by Microsoft, but without the softfail.


FWIW: we deliver via IPv6 to Google, and we are currently not affected. We 
don't yet use DKIM, but we do have an SPF record that advertises both our 
IPv4 and our IPv6 subnets. Of course I don't know if that's the reason our 
mails are accepted.


Cheers
Sebastian
--
Sebastian Hagedorn - Postmaster - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universität zu Köln / Cologne University - Tel. +49-221-470-89578

pgpiY09z_WZZe.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Hugo Slabbert]

On Thu 2016-Jun-09 18:06:30 +0200, Bernhard Schmidt  
wrote:


Hi,

since around 13:00 UTC today all of the sudden we see massive rejects of
mails towards Google when delivering on IPv6

Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
to=,
relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
delays=0.01/0/0.16
/0.53, dsn=5.7.1, status=bounced (host
gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
message does not have authentication information or fails to pass
550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for m
ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
of DATA command))

Header-From and Envelope-From are aligned, the sending domain does not
have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
not rolled out for all domains yet. The hosts in question do have proper
FCrDNS, i.e.

http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html

Anyone seeing the same? From outside it looks like Google has
implemented the "all mail delivered over IPv6 has to be DKIM/SPF
authenticated" previously done by Microsoft, but without the softfail.


...hasn't this been the case for some time?  They want FCrDNS + at least
one of SPF or DKIM to accept delivery over v6:

https://support.google.com/mail/answer/81126?hl=en#authentication

Did they just defer previously?


Best Regards,
Bernhard


--
Hugo

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

[mailop] Messages over IPv6 rejected by Google for failed authentication checks

[Bernhard Schmidt]

Hi,

since around 13:00 UTC today all of the sudden we see massive rejects of
mails towards Google when delivering on IPv6

Jun  9 15:12:07 lxmhs52 postfix-postout/smtp[50664]: 3rQQgp3VQTzyWn:
to=,
relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b]:25, delay=0.7,
delays=0.01/0/0.16
/0.53, dsn=5.7.1, status=bounced (host
gmail-smtp-in.l.google.com[2a00:1450:400c:c0a::1b] said: 550-5.7.1 This
message does not have authentication information or fails to pass
550-5.7.1 authentication checks. To best protect our users from spam,
the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
https://support.google.com/mail/answer/81126#authentication for m
ore 550 5.7.1 information. d7si7802319wjc.145 - gsmtp (in reply to end
of DATA command))

Header-From and Envelope-From are aligned, the sending domain does not
have any DKIM/SPF/DMARC published. We're working on DKIM, but this is
not rolled out for all domains yet. The hosts in question do have proper
FCrDNS, i.e.

http://multirbl.valli.org/fcrdns-test/2001%3A4ca0%3A0%3A103%3A%3A81bb%3Aff89.html

Anyone seeing the same? From outside it looks like Google has
implemented the "all mail delivered over IPv6 has to be DKIM/SPF
authenticated" previously done by Microsoft, but without the softfail.

Best Regards,
Bernhard

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

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

[John Levine]

>It's a public document and I welcome requests with updates...
>https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt

Hmmn.  One the one hand, I'm definitely in favor of making it as easy
as possible for people to make the mail go away.

On the other hand, this particular proposal is a horrible misuse of
both http GET and of the list-unsubscribe header.  The http specs are
quite clear that GET is not supposed to change the state on the web
server.  For that you use POST or PUT.  It is also a bad idea to try
to redefine the List-Unsubscribe header which has meant the same thing
for 18 years.

Fortunately, this is not hard to fix.  Let's invent a new header,
list-unsubscribe-post, which one can use in conjunction with
list-unsubscribe, e.g.

 List-Unsubcribe: 
 List-Unsubscribe-Post: mailaddr=some...@receipient.de=0209023

This says to do a POST to the URL in the list-unsubscribe, with the
fields in the list-unsubscribe-post as the data to the POST.  MUAs
that don't understand the new field can still do a GET to the URL
which will do whatever it does, probably show you a page with a
confirmation button that does a POST.

This should be easy to implement, since I've never seen an http
library that could do GET that can't also do POST, and this avoids
both the semantic problem of GET, and the unintended unsubs by
filterware that poke all the URLs just to see what will happen.

R's,
John

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

Re: [mailop] I trust my candor is appreciated...?

[Kent McGovern via mailop]

It's great to see mailbox providers openly sharing information and willing
to help senders out.

Kent McGovern

On Thu, Jun 9, 2016 at 12:03 PM, Laura Atkins 
wrote:

> Thirding this. Thanks so much for sharing such insightful information with
> us.
>
> laura
>
>
> > On Jun 9, 2016, at 8:50 AM, Al Iverson 
> wrote:
> >
> > Michael, I greatly appreciate your participation and candor as well.
> >
> > Cheers,
> > Al Iverson
> >
> > On Thu, Jun 9, 2016 at 10:40 AM, G. Miliotis 
> wrote:
> >> On 9/6/2016 16:44, Michael Wise via mailop wrote:
> >>
> >>
> >> These are hard issues to discuss, and I hope the view I present of how
> >> certain issues are viewed from behind the trenches of a large scale mail
> >> service are useful.
> >>
> >> I for one appreciate the candor and have been helped by your
> participation
> >> in these discussions greatly.
> >> --GM
> >
> > ___
> > 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] Microsoft/Hotmail discards mails

[John Levine]

>> At one point, Hotmail tried to turn off the delete action for sufficiently 
>> spammy, and just delivered it
>into Junk; Customers complained. Loudly. 
>
>Is there a public place/forum/whatever where people complained loudly? I
>am just curious to see their arguments about this.

The Hotmail users should definitely demand their money back.

Oh, wait.


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

Re: [mailop] Contact at Mailchimp?

[Al Iverson]

Wouldn't ab...@mailchimp.com be a better place for a non-customer to
contact them about an email issue? They've been very responsive to me
via that address.

Regards,
Al Iverson

--
Al Iverson
www.aliverson.com
(312)725-0130


On Wed, Jun 8, 2016 at 7:48 PM, Joey Rutledge  wrote:
> Hi Jay,
>
> Happy to help.  I work on the delivery team at MailChimp.  Feel free to email 
> me offlist if you’d prefer.  joeyrutle...@gmail.com
>
> Joey Rutledge
>
>> On Jun 8, 2016, at 7:25 PM, Jay Hennigan  wrote:
>>
>> Anyone from Mailchimp on-list? support@mailchimp now auto-returns an 
>> ignore-bot with a link that points to a webpage with no useful options.
>>
>> Why are people in the email business so difficult to reach by email?
>>
>> --
>> 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
>> 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] "One-Click" List-Unsubscribe URIs

[Al Iverson]

This also brings us back to the issue of what happens when security
devices or services click the link, instead of the subscriber. In this
scenario, it sounds like it would cause an unsubscribe that was not
actually requested by the recipient. I think that is suboptimal.

Regards,
Al Iverson

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

Re: [mailop] I trust my candor is appreciated...?

[Al Iverson]

Michael, I greatly appreciate your participation and candor as well.

Cheers,
Al Iverson

--
Al Iverson
www.aliverson.com
(312)725-0130


On Thu, Jun 9, 2016 at 10:40 AM, G. Miliotis  wrote:
> On 9/6/2016 16:44, Michael Wise via mailop wrote:
>
>
> These are hard issues to discuss, and I hope the view I present of how
> certain issues are viewed from behind the trenches of a large scale mail
> service are useful.
>
> I for one appreciate the candor and have been helped by your participation
> in these discussions greatly.
> --GM
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>

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

Re: [mailop] Microsoft/Hotmail discards mails [slightly OT]

[G. Miliotis]

On 9/6/2016 17:46, Renaud Allard via mailop wrote:

Actually, many small operators also silently discard email. Whether it's
by incompetence, or voluntarily doesn't matter much. It's just less
visible than hotmail.


Undoubtedly, but they can't use the scaling-is-hard argument as a free 
pass. We should all be accountable if we break mail, big or small.


In addition, you can prectically ignore a small mail operator but not 
the big players.


--GM


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

Re: [mailop] I trust my candor is appreciated...?

[Andreas Ziegler]

I very much appreciate you, Michael, taking part in the discussions on
this list and giving us some hints on what the issues are.

Microsoft could (unfortunately) easily ignore every inquiry from small
mail providers and it won't affect them, so... thanks for not ignoring ;-)

My hint to german law wasn't meant to offend anyone and of course this
doesn't apply for every other country - i just wanted to provide
information on the local situation.

The intention of this part of the law is to ensure people can trust
communication providers like snail mail and e-mail.

Of course, some exceptions (like discarding virusses) are allowed,
although many still inform the recipient that a mail has been discarded
or quarantined because of a detected virus.

Andreas


Am 09.06.2016 um 15:44 schrieb Michael Wise via mailop:
> 
> These are hard issues to discuss, and I hope the view I present of how
> certain issues are viewed from behind the trenches of a large scale mail
> service are useful.
> 
> Sometimes, what scales and what doesn't are not obvious. But the comment
> on German law in particular is interesting, and ... Will not go un-noticed.
> 
> I am not a fan of Silent Drop, and continue to push for some other
> infrastructure and user friendly solution, but so far... It's a hard
> sell for many reasons.
> 
> Aloha,
> Michael.
> -- 
> Sent from my Windows Phone
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 

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

Re: [mailop] Microsoft/Hotmail discards mails [slightly OT]

[Renaud Allard via mailop]

On 06/09/2016 04:33 PM, G. Miliotis wrote:
> On 9/6/2016 16:13, Michael Wise via mailop wrote:
>> The discussion is on-going.
> 
> This is at least one good thing about this whole deal. I think your
> suggestion about deleted items (marked as such somehow) would be a good
> compromise.
> 

While it's better, the junk folder is still the best solution. Do you
often search in your deleted folder for something you haven't deleted?

> FWIW, personally, I find it all an interesting social mental exercise.
> Apparently it's more important for huge mail operators to continue to
> exist and grow, rather than keep mail working as everyone expects it to.
> I'm seeing big players who have cornered the mail "market" that can't
> operate properly cause of their growth and their inability to solve the
> scaling problems. I don't see why we NEED to compromise the thing we do,
> just cause of the way we currently do it. We, as a society, chose to
> support the centralization of these services directly or indirectly. So,
> now we simply don't have mail anymore. We have "mostly mail".
> 

Actually, many small operators also silently discard email. Whether it's
by incompetence, or voluntarily doesn't matter much. It's just less
visible than hotmail.



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Renaud Allard via mailop]

On 06/09/2016 03:34 PM, Michael Wise via mailop wrote:
> That's a violation of RFC 821, etc.

It might be, but it's the conservative (less scalable) approach instead
of the aggressive one.

There are RFC5321 violations everywhere like this one ;)

RFC5321
4.5.3.2.  Timeouts
4.5.3.2.7.  Server Timeout: 5 Minutes.
   An SMTP server SHOULD have a timeout of at least 5 minutes while it
   is awaiting the next command from the sender.

$ time telnet mx1.hotmail.com 25
Trying 65.55.33.119...
Connected to mx1.hotmail.com.
Escape character is '^]'.
220 COL004-MC5F4.hotmail.com Sending unsolicited commercial or bulk
e-mail to Microsoft's computer network is prohibited. Other restrictions
are found at http://privacy.microsoft.com/en-us/anti-spam.mspx. Thu, 9
Jun 2016 07:26:53 -0700
Connection closed by foreign host.
1m03.66s real 0m00.00s user 0m00.01s system


> Of course, the expectation that the email won't be discarded inside the
> system is also not countenanced.
> 
> But making a decision on the fate of an email at END OF DATA is not
> something that massive mail systems do. All the decisions on that happen
> after the connection has ended.
> 
> Wish it were otherwise, but when each edge box is expected to handle
> thousands of connections opened per second, it doesn't scale.
> 
> Aloha,
> Michael.
> -- 
> Sent from my Windows Phone
> 
> From: Renaud Allard via mailop 
> Sent: ‎6/‎9/‎2016 2:10 AM
> To: mailop@mailop.org 
> Subject: Re: [mailop] Microsoft/Hotmail discards mails
> 
> 
> 
> On 06/09/2016 10:25 AM, Paul Smith wrote:
>> The problem is there may be a few other users who get false positives in
>> that type of spam quite frequently, and suddenly they are losing
>> messages with no hope of redemption or even knowledge that it's
>> happening.
> 
> Actually, what I do is that when a mail goes to the junk folder, the
> server gives a 5XX error message to the sender at the end of DATA phase.
> So the sender, if real, knows something happened to his mail and that it
> might not be read.
> 
> 
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Ian McDonald]

Hi Michael,

Can you advise how one would “ramp up” such a new IP? The very nature of such 
transactional traffic is that it’s bursty, and may go for weeks when one may 
send a few dozen mails, then a few thousand on a specific day, then nothing 
again. Wouldn’t your systems detect that as ‘anomalous’ behaviour and do 
something about it?

Thanks

--
ian

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Michael Wise via 
mailop
Sent: 09 June 2016 14:27
To: Duncan Brannen ; mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails


Separate IPs absolutely help, at least they do now. At some point, separate 
domains will be where it's at. "Canned Responses" are mandated by the Lawyers, 
who have had to deal with ... "Issues".

I have been told that Return Path Sender Score is certainly a factor, and that 
they also have some extra services available, but exactly how they get this 
data I do not know, and can't comment on. I don't know.

The largest factor that drives good reputation is having the Recipients 
safelist the sender. Another huge factor is engaging the recipient in a 
conversation of some sort. Further down the list is making sure that your 
traffic looks as little like spam as possible. If you use tricks that spammers 
do, for instance any kind of hashbuster text, etc... The system *WILL* notice.

Past that, we're not allowed to provide information on why a particular email 
or campaign was sent to junk or silently dropped, and honestly, I have never 
been motivated to figure out the mechanics. Remember that, "Each Sender is 
Unique!", and there's millions of them, and Billions of emails an hour, let 
alone a day.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Duncan Brannen
Sent: ‎6/‎9/‎2016 1:16 AM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails

Hi,
Just to throw our tuppence worth in.  We have the same problem.  It seems 
to be noticed when we send out offers of a place of study, a noticeable 
percentage of the emails
are never received despite being accepted by Hotmail / outlook / live.com for 
delivery.  We’re signed up for JMRP / SNDS, have opened tickets but can’t get 
anything
back other than a canned response.  (unusual activity or eligible/not eligible 
for partial mitigation)

Is there a method for feeding back suggestions about this, eg a notification 
along the lines of the Junk report mechanism?  By the sounds of it, there 
really isn’t any way to find out
why emails are silently junked and asking applicants to whitelist the 
University would seem to be the only way to mitigate? Does Returnpath / Sender 
score help in any way here?

One thought is to move all of our ‘business’ (ie official comms to applicants 
and enquirers) to one IP and keep staff/student / bulk email to eg alumni to a 
different IP but if anyone
has any suggestions I’m open to them.

Cheers,
Duncan


On 09/06/2016, 03:08, "mailop on behalf of Michael Wise via mailop" 
>
 wrote:


At the request of the customer-base, traffic that is classified as sufficiently 
spammy (by various "Black Box" algorithms that I have no knowledge of the inner 
workings...) is deleted even after a successful delivery.

At one point, Hotmail tried to turn off the delete action for sufficiently 
spammy, and just delivered it into Junk; Customers complained. Loudly. So 
whether the system is correctly classifying your traffic or not, I cannot say. 
But the behavior is not unexpected in certain scenarios. Which one of them 
applies to you, I cannot say. Even if I wanted to! But I really have no idea, 
and no way to find out.

This "Delete" action is a well-known mitigation that is not unique to Hotmail.

About the only way around it would be to login to your test account, and safe 
sender the sending email address.
Among other things, that will force the system to reconsider the verdict that 
it has assigned to the IP and the traffic coming from it.

It's possible that the IPs have a left-over bad reputation from a previous 
sender, but that's difficult to tell.

Good luck.

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 Andreas Ziegler
Sent: Wednesday, June 8, 2016 6:50 PM
To: mailop@mailop.org
Subject: [mailop] Microsoft/Hotmail discards mails

Hi,

a user of my server complained, that some of his mails don't reach mail 
accounts from hotmail/live/outlook etc. that complaint is nothing new, the 
problem exists for months now.

the users mails are dkim signed, the domain has DKIM and SPF TXT DNS records, 
since 

Re: [mailop] Microsoft/Hotmail discards mails

[Dominique Rousseau]

Le Thu, Jun 09, 2016 at 02:09:31PM +, Michael Wise via mailop 
[mailop@mailop.org] a écrit:
> Unsure what you're saying. If it's the .DE extension, then by that
> logic, we, "explicitly target" a lot of users. Pretty much the whole
> world, actually.

That was the point :)

Eric (in my understanding) was implying that being a US-based company
doesn't imply having to consider foreign (in this case german) laws.
For internet services, almost anybody is able to access you service.
But registering a domaine in CC TLDs and having it configured such a way
that you get access to the service looks like an explicit move towards
wanting this country's users to use your service.
And as such, you should abide by their laws.
(and I believe MS has some offices in Germany, too)

(as a not so good example, Google had to use the "googlemail" name for
their Gmail service, for german users, due to some trademark dispute)


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop

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

Re: [mailop] Microsoft/Hotmail discards mails

[Alarig Le Lay]

On Thu Jun  9 15:59:33 2016, Dominique Rousseau wrote:
> Le Thu, Jun 09, 2016 at 01:49:26PM +, Eric Henson [ehen...@pfsweb.com] a 
> écrit:
> > You're saying that, simply because a sender or recipient MIGHT be in
> > Germany, that my US-based mail server has to send an NDR? 
> 
> I do believe that Microsoft is explicitely targetting german users :
> 
> # dig +short www.hotmail.de
> mail.live.com.
> dispatch.kahuna.glbdns2.microsoft.com.
> 157.56.122.211
> 157.56.122.210

It looks similar for the french domain, and we do not have this law:

alarig@pikachu ~ % dig www.hotmail.fr
;; ANSWER SECTION:
www.hotmail.fr. 3600IN  CNAME   mail.live.com.
mail.live.com.  3587IN  CNAME   
dispatch.kahuna.glbdns2.microsoft.com.
dispatch.kahuna.glbdns2.microsoft.com. 287 IN A 157.55.230.156
dispatch.kahuna.glbdns2.microsoft.com. 287 IN A 157.56.198.220

Plus, the MX are the same:
alarig@pikachu ~ % dig MX hotmail.de 
;; ANSWER SECTION:
hotmail.de. 86400   IN  MX  5 mx3.hotmail.com.
hotmail.de. 86400   IN  MX  5 mx1.hotmail.com.
hotmail.de. 86400   IN  MX  5 mx4.hotmail.com.
hotmail.de. 86400   IN  MX  5 mx2.hotmail.com.

alarig@pikachu ~ % dig MX hotmail.fr 
;; ANSWER SECTION:
hotmail.fr. 3600IN  MX  5 mx1.hotmail.com.
hotmail.fr. 3600IN  MX  5 mx4.hotmail.com.
hotmail.fr. 3600IN  MX  5 mx2.hotmail.com.
hotmail.fr. 3600IN  MX  5 mx3.hotmail.com.

-- 
alarig


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

Re: [mailop] Microsoft/Hotmail discards mails

[Michael Wise via mailop]

Unsure what you're saying. If it's the .DE extension, then by that logic, we, 
"explicitly target" a lot of users. Pretty much the whole world, actually.

Or perhaps your point is lost on me. :)

Aloha,
Michael.
--
Sent from my Windows Phone

From: Dominique Rousseau
Sent: ‎6/‎9/‎2016 7:04 AM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails

Le Thu, Jun 09, 2016 at 01:49:26PM +, Eric Henson [ehen...@pfsweb.com] a 
écrit:
> You're saying that, simply because a sender or recipient MIGHT be in
> Germany, that my US-based mail server has to send an NDR?

I do believe that Microsoft is explicitely targetting german users :

# dig +short 
https://na01.safelinks.protection.outlook.com/?url=www.hotmail.de=01%7c01%7cmichael.wise%40microsoft.com%7c2f4b3f5e86474db078cc08d3906f05ae%7c72f988bf86f141af91ab2d7cd011db47%7c1=l%2b1yi9pPwqN%2fU23bTejFSOV9XTpa9vGaffhio7lo%2brk%3d
mail.live.com.
dispatch.kahuna.glbdns2.microsoft.com.
157.56.122.211
157.56.122.210


--
Dominique Rousseau
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.neuronnexion.coop=01%7c01%7cmichael.wise%40microsoft.com%7c2f4b3f5e86474db078cc08d3906f05ae%7c72f988bf86f141af91ab2d7cd011db47%7c1=BeqN17SWqYmLznWiHpUmpxztkqM0Do6l8zNC3VhkZeU%3d

___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop=01%7c01%7cmichael.wise%40microsoft.com%7c2f4b3f5e86474db078cc08d3906f05ae%7c72f988bf86f141af91ab2d7cd011db47%7c1=POPVfuBLMpkkPdpWRqn7ZQXxUG3E6ZNgf%2fH62BrfAbM%3d
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] I trust my candor is appreciated...?

[Michael Wise via mailop]

If the traffic is Transactional, by all means open a ticket and push it. It is 
always the best plan to keep Transactional traffic strictly separate from all 
other traffic, and if there are issues, point the nature of said traffic out in 
follow-up emails, as once validated, it will factor in the mitigation decision.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Dave Warren
Sent: ‎6/‎9/‎2016 6:59 AM
To: mailop@mailop.org
Subject: Re: [mailop] I trust my candor is appreciated...?

On 2016-06-09 15:44, Michael Wise via mailop wrote:

These are hard issues to discuss, and I hope the view I present of how certain 
issues are viewed from behind the trenches of a large scale mail service are 
useful.

Sometimes, what scales and what doesn't are not obvious. But the comment on 
German law in particular is interesting, and ... Will not go un-noticed.

I am not a fan of Silent Drop, and continue to push for some other 
infrastructure and user friendly solution, but so far... It's a hard sell for 
many reasons.

It's a hard sell because your users blame me when they don't get a receipt, 
they don't blame you. If you could publish some sort of a "Yes, we drop your 
mail and won't tell the sender or recipient why" article, it would give senders 
a chance to point receivers toward it so that receivers could understand that 
the fault really is on their side of the line.

Either way, yes, your candor is greatly appreciated!


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


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

Re: [mailop] Microsoft/Hotmail discards mails

[Dominique Rousseau]

Le Thu, Jun 09, 2016 at 01:49:26PM +, Eric Henson [ehen...@pfsweb.com] a 
écrit:
> You're saying that, simply because a sender or recipient MIGHT be in
> Germany, that my US-based mail server has to send an NDR? 

I do believe that Microsoft is explicitely targetting german users :

# dig +short www.hotmail.de
mail.live.com.
dispatch.kahuna.glbdns2.microsoft.com.
157.56.122.211
157.56.122.210


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop

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

Re: [mailop] I trust my candor is appreciated...?

[Dave Warren]

On 2016-06-09 15:44, Michael Wise via mailop wrote:


These are hard issues to discuss, and I hope the view I present of how 
certain issues are viewed from behind the trenches of a large scale 
mail service are useful.


Sometimes, what scales and what doesn't are not obvious. But the 
comment on German law in particular is interesting, and ... Will not 
go un-noticed.


I am not a fan of Silent Drop, and continue to push for some other 
infrastructure and user friendly solution, but so far... It's a hard 
sell for many reasons.


It's a hard sell because your users blame me when they don't get a 
receipt, they don't blame you. If you could publish some sort of a "Yes, 
we drop your mail and won't tell the sender or recipient why" article, 
it would give senders a chance to point receivers toward it so that 
receivers could understand that the fault really is on their side of the 
line.


Either way, yes, your candor is greatly appreciated!

--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

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

[mailop] I trust my candor is appreciated...?

[Michael Wise via mailop]

These are hard issues to discuss, and I hope the view I present of how certain 
issues are viewed from behind the trenches of a large scale mail service are 
useful.

Sometimes, what scales and what doesn't are not obvious. But the comment on 
German law in particular is interesting, and ... Will not go un-noticed.

I am not a fan of Silent Drop, and continue to push for some other 
infrastructure and user friendly solution, but so far... It's a hard sell for 
many reasons.

Aloha,
Michael.
--
Sent from my Windows Phone
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Michael Wise via mailop]

And they WILL notice.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Eric Henson
Sent: ‎6/‎9/‎2016 3:46 AM
To: Renaud Allard
Cc: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails

You're giving spammers very valuable information on which of their emails are 
classified as spam and which aren't.


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Renaud Allard via 
mailop
Sent: Thursday, June 9, 2016 4:05 AM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails



On 06/09/2016 10:25 AM, Paul Smith wrote:
> The problem is there may be a few other users who get false positives
> in that type of spam quite frequently, and suddenly they are losing
> messages with no hope of redemption or even knowledge that it's
> happening.

Actually, what I do is that when a mail goes to the junk folder, the server 
gives a 5XX error message to the sender at the end of DATA phase.
So the sender, if real, knows something happened to his mail and that it might 
not be read.



___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop=01%7c01%7cmichael.wise%40microsoft.com%7c4584e9d4f7f64c27bb8c08d390535750%7c72f988bf86f141af91ab2d7cd011db47%7c1=yTGLpsFMPfp%2fCuyuUOi%2fl%2fVARP2eD9f3eoWhgdHMY50%3d
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Microsoft/Hotmail discards mails

[Michael Wise via mailop]

The point is lost on you.
So here it is, spelled out:

There's a huge difference to most, "Senders" between a 250 and any kind of 4xx 
or 5xx refusal. Some top tier ESPs even have real-time graphs!

Aloha,
Michael.
--
Sent from my Windows Phone

From: Renaud Allard via mailop
Sent: ‎6/‎9/‎2016 4:16 AM
To: Eric Henson
Cc: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails



On 06/09/2016 12:39 PM, Eric Henson wrote:
> You're giving spammers very valuable information on which of their emails are 
> classified as spam and which aren't.

How so? There is no difference in rejecting a spam with 5xx and
rejecting it with 5xx but still delivering it into junk folder. The only
way to not give info to spammers (if they even look at it) is to accept
and drop the mail, which is the probably worst thing you can do.

I am not sure spammers are reading the reasons for a reject, but real
people (at least mail admins) need to know why a legitimate mail has
been rejected.

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

Re: [mailop] Microsoft/Hotmail discards mails

[Duncan Brannen]

Thanks Michael,
That’s helpful and at least something I can 
give to our admissions people.

Cheers,
Duncan


From: Michael Wise 
Date: Thursday, 9 June 2016 at 14:26
To: Duncan Brannen , "mailop@mailop.org" 

Subject: RE: [mailop] Microsoft/Hotmail discards mails


Separate IPs absolutely help, at least they do now. At some point, separate 
domains will be where it's at. "Canned Responses" are mandated by the Lawyers, 
who have had to deal with ... "Issues".

I have been told that Return Path Sender Score is certainly a factor, and that 
they also have some extra services available, but exactly how they get this 
data I do not know, and can't comment on. I don't know.

The largest factor that drives good reputation is having the Recipients 
safelist the sender. Another huge factor is engaging the recipient in a 
conversation of some sort. Further down the list is making sure that your 
traffic looks as little like spam as possible. If you use tricks that spammers 
do, for instance any kind of hashbuster text, etc... The system *WILL* notice.

Past that, we're not allowed to provide information on why a particular email 
or campaign was sent to junk or silently dropped, and honestly, I have never 
been motivated to figure out the mechanics. Remember that, "Each Sender is 
Unique!", and there's millions of them, and Billions of emails an hour, let 
alone a day.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Duncan Brannen
Sent: ‎6/‎9/‎2016 1:16 AM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails

Hi,
Just to throw our tuppence worth in.  We have the same problem.  It seems 
to be noticed when we send out offers of a place of study, a noticeable 
percentage of the emails
are never received despite being accepted by Hotmail / outlook / live.com for 
delivery.  We’re signed up for JMRP / SNDS, have opened tickets but can’t get 
anything
back other than a canned response.  (unusual activity or eligible/not eligible 
for partial mitigation)

Is there a method for feeding back suggestions about this, eg a notification 
along the lines of the Junk report mechanism?  By the sounds of it, there 
really isn’t any way to find out
why emails are silently junked and asking applicants to whitelist the 
University would seem to be the only way to mitigate? Does Returnpath / Sender 
score help in any way here?

One thought is to move all of our ‘business’ (ie official comms to applicants 
and enquirers) to one IP and keep staff/student / bulk email to eg alumni to a 
different IP but if anyone
has any suggestions I’m open to them.

Cheers,
Duncan


On 09/06/2016, 03:08, "mailop on behalf of Michael Wise via mailop" 
 wrote:


At the request of the customer-base, traffic that is classified as sufficiently 
spammy (by various "Black Box" algorithms that I have no knowledge of the inner 
workings...) is deleted even after a successful delivery.

At one point, Hotmail tried to turn off the delete action for sufficiently 
spammy, and just delivered it into Junk; Customers complained. Loudly. So 
whether the system is correctly classifying your traffic or not, I cannot say. 
But the behavior is not unexpected in certain scenarios. Which one of them 
applies to you, I cannot say. Even if I wanted to! But I really have no idea, 
and no way to find out.

This "Delete" action is a well-known mitigation that is not unique to Hotmail.

About the only way around it would be to login to your test account, and safe 
sender the sending email address.
Among other things, that will force the system to reconsider the verdict that 
it has assigned to the IP and the traffic coming from it.

It's possible that the IPs have a left-over bad reputation from a previous 
sender, but that's difficult to tell.

Good luck.

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 Andreas Ziegler
Sent: Wednesday, June 8, 2016 6:50 PM
To: mailop@mailop.org
Subject: [mailop] Microsoft/Hotmail discards mails

Hi,

a user of my server complained, that some of his mails don't reach mail 
accounts from hotmail/live/outlook etc. that complaint is nothing new, the 
problem exists for months now.

the users mails are dkim signed, the domain has DKIM and SPF TXT DNS records, 
since yesterday there is also a DMARC record.

i investigated further, set up test accounts on both ends and indeed, they are 
accepting the mail with 250 but it doesn't appear in the inbox or even junk 
folder.

According to SNDS, the IP has "normal status" and no events are logged.
i reached out to them through 

Re: [mailop] Microsoft/Hotmail discards mails

[Michael Wise via mailop]

"Well Known" to people who send high volumes of mail.

HotMail has hundreds of millions of users.

Things that work when you have a thousand users are under strain when you have 
ten thousand, and fail long before a hundred thousand.

Things that work well for a hundred thousand can barely handle a million, and 
have no hope of reaching ten million.

And things that worked at ten million require significant retooling and rework 
and huge investments and ... It's enormous to get past one hundred million. And 
to push it further is huge.

There are enormous issues, especially at the edge, that require methodologies 
at scale that people who are used to running a mail server with a few thousand 
users can't even dream about, especially when the system comes under attack, or 
some sender tries to game it, which they do ... All the freaking time.

I wasn't the one who had to handle the blow-back for delivering all the traffic 
that the system considered spammiest into Junk, but I trust the people who 
turned on the feature and then turned it off. I have suggested that instead it 
be delivered into Deleted Items, from which it could still be rescued. The 
discussion is on-going.

But the bottom line is, the whole system is a huge, Machine Learning engine 
driven almost exclusively by end user feedback; a message is selected at random 
that had been sent to the user, and they are asked to classify it, Spam or Not? 
And if too many users click, "Spam" ... Fairly quickly both that traffic, and 
traffic, "Similar" (proprietary, so don't bother asking; even I don't know...) 
to it will wind up in the Junk folder, and then get silently dropped, and at 
long last, the sending IP(s) will be blocked.

If you've read this far, and don't know about SNDS and JMRP, or don't  know how 
to open a ticket with HotMail sender support, well ... I'll post more later 
today.

Aloha,
Michael.
--
Sent from my Windows Phone

From: Mark Foster
Sent: ‎6/‎8/‎2016 9:28 PM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails

As a long time hotmail.com account holder, I can tell you that I would
never request a silent-discard option.

If you are able to determine via black-box algorithms that a message is
sufficiently spammy, why not refuse after post-dot?

I'm sure Hotmail deals with spam volumes that are orders of magnitude
bigger than any other system i've ever touched or dealt with, but even
so, whether bounded by law or not, this seems to be amongst the worst
actions a mail platform administrator could take where the end users
probably have not assented to the practice (I sincerely doubt Hotmail
has communicated this approach to its _entire_ customer base).

Mark.


On 9/06/2016 2:08 p.m., Michael Wise via mailop wrote:
> At the request of the customer-base, traffic that is classified as 
> sufficiently spammy (by various "Black Box" algorithms that I have no 
> knowledge of the inner workings...) is deleted even after a successful 
> delivery.
>
> At one point, Hotmail tried to turn off the delete action for sufficiently 
> spammy, and just delivered it into Junk; Customers complained. Loudly. So 
> whether the system is correctly classifying your traffic or not, I cannot 
> say. But the behavior is not unexpected in certain scenarios. Which one of 
> them applies to you, I cannot say. Even if I wanted to! But I really have no 
> idea, and no way to find out.
>
> This "Delete" action is a well-known mitigation that is not unique to Hotmail.
>
> About the only way around it would be to login to your test account, and safe 
> sender the sending email address.
> Among other things, that will force the system to reconsider the verdict that 
> it has assigned to the IP and the traffic coming from it.
>
> It's possible that the IPs have a left-over bad reputation from a previous 
> sender, but that's difficult to tell.
>
> Good luck.
>
> Aloha,
> Michael.


___
mailop mailing list
mailop@mailop.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fchilli.nosignal.org%2fcgi-bin%2fmailman%2flistinfo%2fmailop=01%7c01%7cmichael.wise%40microsoft.com%7c5e7317a2e86d48a2505908d3901e8eb1%7c72f988bf86f141af91ab2d7cd011db47%7c1=H0Rjn3ESEERa9liKuABBXs0LSufni2I0yUzzxqF59bs%3d
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

[tobias.herkula]

On Thu, 09 Jun 2016 14:30:29 +0200
Dave Warren  wrote:

> On 2016-06-09 12:23, David Hofstee wrote:
> > Same here, auto-unsubscribe presumed. The https is a nice addition 
> > that I will pass along. I hope that all implementations can handle 
> > https. Did people verify?
> >
> > I treat it nearly as strict as a feedbackloop. All streams (of my 
> > customer X) to the recipient will cease permanently. I cannot
> > expect Gmail (or others) to differentiate between specific
> > permissions that my customer uses and filter accordingly.
> 
> As a user, I like the idea of a HTTPS page that shows all lists to
> which I was subscribed, clearly indicates that I have been removed
> from all, but also has a one-more-click to resubscribe to specific
> lists if I desire.
> 
> A bit more complex, and I think the user expectation is that you'll
> be completely unsubscribed from all marketing drivel with one click,
> but in cases where there are clearly differentiated lists, it's nice
> to expose that to the user and give them a chance to reconsider.
> 

The view here is a little bit different, I don't really care what
happens in the body of the mails my customers send out, as long as they
don't violate our content policy or the law. So Links to preference
pages and all this stuff is fine there.

The document is more suited for functionality where the function should
be integrated into the MUA, like Googles "Easy Unsubscribe", in these
cases I would expect, that the platform provider doesn't want to show
external content and still needs a way to find out if the unsubscribe
worked.

#1 You could simply state as a platform provider that you expect that
   those links are "one-click" and give a penalty to senders who don't
   comply...

#2 You could use this pattern and be sure that the links are "one-click"

The second approach, in my opinion, is the easier way to implement this
feature, if you already settled on the idea to give your users a
unsubscribe button in your MUA.

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

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

[Dave Warren]

On 2016-06-09 12:23, David Hofstee wrote:
Same here, auto-unsubscribe presumed. The https is a nice addition 
that I will pass along. I hope that all implementations can handle 
https. Did people verify?


I treat it nearly as strict as a feedbackloop. All streams (of my 
customer X) to the recipient will cease permanently. I cannot expect 
Gmail (or others) to differentiate between specific permissions that 
my customer uses and filter accordingly.


As a user, I like the idea of a HTTPS page that shows all lists to which 
I was subscribed, clearly indicates that I have been removed from all, 
but also has a one-more-click to resubscribe to specific lists if I desire.


A bit more complex, and I think the user expectation is that you'll be 
completely unsubscribed from all marketing drivel with one click, but in 
cases where there are clearly differentiated lists, it's nice to expose 
that to the user and give them a chance to reconsider.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren



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

Re: [mailop] Microsoft/Hotmail discards mails

[G. Miliotis]

On 9/6/2016 05:08, Michael Wise via mailop wrote:

At one point, Hotmail tried to turn off the delete action for sufficiently 
spammy, and just delivered it into Junk; Customers complained. Loudly. So 
whether the system is correctly classifying your traffic or not, I cannot say. 
But the behavior is not unexpected in certain scenarios. Which one of them 
applies to you, I cannot say. Even if I wanted to! But I really have no idea, 
and no way to find out.

This "Delete" action is a well-known mitigation that is not unique to Hotmail.


I directly dispute the "well-known" part.

I am curious to know whether this policy, justified or not, is clearly 
explained to users who sign up to the services that implement them 
during the sign-up process. Cause when I tell my customers,friends and 
strangers about this "well-known" "mitigation" strategy, they look at me 
like I just landed in a huge, music-playing flying saucer, without 
exception.


Somehow I think that if users were told clearly "we'll flood you with 
ads and  log/process/sell your data, cause this is our business model. 
We will also silently drop some of your mail, btw" use of these services 
would decrease. Most definitely businesses at the very least would not 
be using them.


Maybe we should push back against idiots instead of accommodating them. 
I really would like to see the complaints of the users who want their 
mail to be "mitigated" by deletion... It must make a fun evening reading 
them.


--GM

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

Re: [mailop] Microsoft/Hotmail discards mails

[Eric Henson]

You're giving spammers very valuable information on which of their emails are 
classified as spam and which aren't.


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Renaud Allard via 
mailop
Sent: Thursday, June 9, 2016 4:05 AM
To: mailop@mailop.org
Subject: Re: [mailop] Microsoft/Hotmail discards mails



On 06/09/2016 10:25 AM, Paul Smith wrote:
> The problem is there may be a few other users who get false positives 
> in that type of spam quite frequently, and suddenly they are losing 
> messages with no hope of redemption or even knowledge that it's 
> happening.

Actually, what I do is that when a mail goes to the junk folder, the server 
gives a 5XX error message to the sender at the end of DATA phase.
So the sender, if real, knows something happened to his mail and that it might 
not be read.



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

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

[David Hofstee]

Same here, auto-unsubscribe presumed. The https is a nice addition that I will 
pass along. I hope that all implementations can handle https. Did people 
verify? 

I treat it nearly as strict as a feedbackloop. All streams (of my customer X) 
to the recipient will cease permanently. I cannot expect Gmail (or others) to 
differentiate between specific permissions that my customer uses and filter 
accordingly. 

Met vriendelijke groet, 


David Hofstee 

Deliverability Management 
MailPlus B.V. Netherlands (ESP) 


Van: "Gil Bahat via mailop"  
Aan: "tobias herkula"  
Cc: mailop@mailop.org 
Verzonden: Donderdag 9 juni 2016 11:40:56 
Onderwerp: Re: [mailop] "One-Click" List-Unsubscribe URIs 

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 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, < tobias.herk...@optivo.de > 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 
___
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 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

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

[tobias.herkula]

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
INFORMATIONAL Tobias Herkula
draft-herkula-oneclick.txt   optivo GmbH
   June 2016


   Signaling "One-Click" functionality for HTTPS URIs in email headers

Status of this Memo

   This document is not an Internet Standards Track specification; it is
   for informational purposes and requests discussion and suggestions
   for improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) Tobias Herkula (2016).  All rights reserved.

Abstract

   This document describes a simplified method for signaling "One-Click"
   functionality for HTTPS URIs as they appear in email headers.  The
   need for this arises out of the fact, that third-party entities
   involved in the processing of emails sometimes unintendedly trigger
   actions that are subject to the user and shall not be triggered
   automatically without an user's intent.

1.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   a.  "One-Click":  In the context of this document, describes an HTTPS
   URI that directly triggers a change in a system that shall only
   be applied if the request to that HTTPS URI is done with an
   user's intent.

   b.  "Organizational Domain":  Is to be interpreted as described in
   [RFC7489#section-3]

   c.  "Domain Alignment":  In the context of this document, means that
   two domains share the same organizational domain.

   d.  "signal-constant": fixed string "=One-Click"

2.  Introduction

   An email header can contain HTTPS URIs for extended functionality,
   for example List-Headers [RFC2369].  In case of the List-Unsubscribe
   Header the HTTPS URI is mandated to unsubscribe the recipient of the
   email directly from the list.  This requirement is often not
   implemented because anti-spam solutions request all found external
   resources, this is considered unintended malicious behavior. In
   consequence senders implement landing pages asking to confirm the
   unsubscribe request.  This specification tries to solve one part of
   this, as it proposes a pattern to detect "One-Click" functionality.
   It defines a specific format for the fragment part of a HTTPS URI and
   a specific transformation for the receiver. A request to the
   transformed HTTPS URI from somebody who adheres to this specification
   can be distinguished from other requests and therefore handled
   independently.

3.  High-Level Goals

   o  Allow email senders to signal "One-Click" functionality for
  specific HTTPS URIs used in email headers.

   o  Allow MUA owners to implement independent user interface features
  for a better user experience.

   o  Allow MUA users to trigger intended actions in a familiar
  environment.

4.  Out of Scope

   This proposal does not solve problems associated with intended
   malicious behavior by users or robots.

5.  Implementation

5.1  Sender

   A sending entity which is responsible for the content of an email,
   that wishes to add an actionable HTTPS URI in the header of an email,
   shall add the name of the Header followed by signal-constant, as the
   URI fragment. The sending entity also needs to provide the infrastructure
   to handle GET and or POST requests to this URI in an appropriate volume.

   The "One-Click" action triggered by such URIs must complete in an appropriate
   timeframe 

Re: [mailop] Microsoft/Hotmail discards mails

[Renaud Allard via mailop]

On 06/09/2016 10:25 AM, Paul Smith wrote:
> The problem is there may be a few other users who get false positives in
> that type of spam quite frequently, and suddenly they are losing
> messages with no hope of redemption or even knowledge that it's
> happening.

Actually, what I do is that when a mail goes to the junk folder, the
server gives a 5XX error message to the sender at the end of DATA phase.
So the sender, if real, knows something happened to his mail and that it
might not be read.





smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Quick practical question on DMARC.

[Vladimir Dubrovin via mailop]

DKIM is a way to authenticate message by signing domain, it doesn't tell
you which domain should sign this message and what should you do if the
messages is not signed.  DMARC does not replace DKIM, is uses DKIM and
SPF as an authentication mechanisms. DMARC is a way to publish an
authentication policy for you domain. So it:

1. DMARC checks alignment. It means for DKIM-DMARC to pass, domain used
in DKIM signature must be aligned with domain used in RFC5322.FROM
field. So, DMARC protects you from spoofing, while DKIM doesn't. You can
sign messages with "example.org" From: with "spammer.com" DKIM, and it
is valid DKIM signature, but it does not pass DMARC checks.
2. DMARC instructs recipients what to do if messages doe not pass either
DMARC authentication (that is, it doesn't has DKIM or SPF authentication
aligned with From: header). DKIM doesn't tells you what to do if message
is not DKIM-signed or signature is invalid. DMARC does. You can specify
strict DMARC policy to reject or quarantine (put into Spam folder)
message if it fails authentication.
3. DMARC publishes reporting policies.

Eric Tykwinski пишет:
> So I’ve seen on here, people seem to be pushing for DMARC, but
> honestly what is the difference between DMARC and just using DKIM for
> end users.  IMHO, if the message is signed with DKIM, sending reports
> for DMARC matters little besides knowing that someone is spamming with
> your domain.  I’m sure this happens a lot for free domains
> like gmail.com , outlook.com ,
> et al, so is there really much of an advantage?
>
> I understand the idea of sending DMARC reports sounds great, but I
> don’t think any of our business servers support it as of yet, but I’ll
> definitely be asking vendors...
>
> Sincerely,
>
> Eric Tykwinski
> TrueNet, Inc.
> P: 610-429-8300
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


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

Re: [mailop] Microsoft/Hotmail discards mails

[Paul Smith]

On 09/06/2016 08:42, David Hofstee wrote:

I'm dazzled by users here... Isn't the junk-box supposed to hold junk? Wow.

Maybe there should be more junk-boxes for the various shades of grey :-).
I'd have thought that even if you do decide to just throw "extreme" junk 
away (which I think is a very bad idea, BTW), then you should tell the 
user that you've done so - either in a daily/weekly summary email or an 
online list or something. That seems to be the bare minimum for an MSP 
to do in such a case.


I actually understand users' preferences in this, because false 
positives get fewer the more 'spammy' a spam filter thinks a messages 
is, so when a user has seen zero false positives in 'extreme spam' for a 
few months they expect that will always be the case so don't want to see 
those messages at all.


The problem is there may be a few other users who get false positives in 
that type of spam quite frequently, and suddenly they are losing 
messages with no hope of redemption or even knowledge that it's 
happening. From the MSP's point of view, surely they should take the 
view that one lost 'good' message is far more important than someone 
having to spend a minute to look through a few more spam messages (as a 
variant of Blackstone's formulation ;-) )



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

Re: [mailop] Microsoft/Hotmail discards mails

[David Hofstee]

I'm dazzled by users here... Isn't the junk-box supposed to hold junk? Wow. 

Maybe there should be more junk-boxes for the various shades of grey :-). 

Met vriendelijke groet,


David Hofstee

Deliverability Management
MailPlus B.V. Netherlands (ESP)

- Oorspronkelijk bericht -
Van: "Renaud Allard via mailop" 
Aan: mailop@mailop.org
Verzonden: Donderdag 9 juni 2016 09:14:35
Onderwerp: Re: [mailop] Microsoft/Hotmail discards mails

Hi,

On 06/09/2016 04:08 AM, Michael Wise via mailop wrote:
> 
> At one point, Hotmail tried to turn off the delete action for sufficiently 
> spammy, and just delivered it into Junk; Customers complained. Loudly. 

Is there a public place/forum/whatever where people complained loudly? I
am just curious to see their arguments about this.

Best Regards


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

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

Re: [mailop] Microsoft/Hotmail discards mails

[Renaud Allard via mailop]

Hi,

On 06/09/2016 04:08 AM, Michael Wise via mailop wrote:
> 
> At one point, Hotmail tried to turn off the delete action for sufficiently 
> spammy, and just delivered it into Junk; Customers complained. Loudly. 

Is there a public place/forum/whatever where people complained loudly? I
am just curious to see their arguments about this.

Best Regards



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop