Re: [mailop] Yahoo DMARC changes

2016-03-29 Thread Brett Schenker 
Dealing mainly with political campaigns and nonprofits I have a lot of them
sending from freemail, so do see this issue a lot. A lot of folks are just
low understanding when it comes to tech and email, volunteers for example,
so just don't know. I've been fighting to get us to just stop sending from
all freemail to "solve the problem." Pop up a warning telling them they
can't do it, and that's that. They're supposed to be professional
organizations and campaigns, they should be sending from their own domain.

Where a technical issue is being run in to is functions like "tell your
friends" where people do use their own personal addresses. That we're
working through solutions now.

On Tue, Mar 29, 2016 at 12:04 PM, Steve Atkins  wrote:

>
> > On Mar 29, 2016, at 8:17 AM, Laura Atkins 
> wrote:
> >
> >
> >> On Mar 28, 2016, at 8:20 PM, Vick Khera  wrote:
> >>
> >> On Wed, Mar 23, 2016 at 11:15 AM, Steve Atkins 
> wrote:
> >>
> >> > On Mar 22, 2016, at 9:35 PM,  
> wrote:
> >> >
> >> > Are you taking that approach because the workaround is less than
> ideal?  Otherwise the current “workaround” could be the new standard.
> >>
> >> The workaround is terrible and breaks basic email functionality.
> >>
> >> What's so terrible about setting the visible From address to something
> you control, and setting reply-to to the original address? I thought that
> was the acceptable workaround, at least as discussed at sessions at M3AAWG.
> >
> > Filters. - Hard to selectively filter particular mailing list users.
> >
> > Searches - nearly impossible to search for mail from a particular user.
> >
> > Reply-To - many lists want to set reply-to: list rather than reply to
> author.
>
> Also, email headers have well-defined meanings.
>
> The From: header specifies the author of the message, the email address of
> the person responsible for writing the message.
> The Sender: header specifies the email address of the agent responsible
> for sending the message, when that's different to the author.
> The Reply-To: header specifies the email address to which replies should
> be sent, when that's different to the author.
>
> They have different meanings, and they're all useful, and used.
>
> The problem with DMARC is that it insists that the From: field contain an
> email address in a domain from which it was sent. If that's not naturally
> the case - mailing lists and ESPs are two examples of that - then you
> cannot comply with both RFC 5322 originator field semantics and DMARC
> requirements.
>
> All the hacks that mailing list operators have put in place to allow
> people to use their mailing lists contrary to the DMARC-published
> requirements of the domain owner are based on violating the RFC 5322
> semantics.
>
> You need to put an email address in the From: field that's in the same
> domain as the mailing list manager - the email address that should be in
> the Sender: field has to go in the From: field. That destroys any record of
> who the author of the email is. That breaks quite a lot of functionality -
> filtering and searching, as laura mentioned, but even more obviously any
> ability to easily reply to just the author.
>
> To work around that last problem a list operator may put the real authors
> address in the reply-to field. That destroys any explicit reply-to that the
> author may have set. That in turn breaks other expectations. If a user
> wants to subscribe to a mailing list with one address, but wants individual
> replies to go to another one they can say "From: li...@blighty.com;
> Reply-To: st...@blighty.com" - this sort of DMARC mitigation breaks that.
>
> Also, many lists already set the Reply-To to the list submission address -
> so they can't put the author address in that field, leaving them with no
> choice other than to change (long established) expectations of how the
> mailing list works, or to have the author email address appear nowhere in
> the mail where it can be used mechanically by any variant of a reply
> command.
>
> All of these break user expectations for how email should work - all
> users, not just those at domains that are publishing DMARC p=reject
> records. Mailing list operators can make operational changes to mitigate
> the inconvenience for different classes of user, but they can't fix it
> entirely.
>
> There is *no way* to fix this without fundamental changes to either RFC
> 5322 or DMARC as they are inherently incompatible.
>
> ARC will make those fundamental changes to DMARC, but only for one
> specific use case - traditional email discussion lists. It'll be an
> improvement (though not a total fix) for that case, but it makes no
> improvement for other use cases (of which ESPs catering to smaller users
> are one major one, but there are others).
>
> Cheers,
>   Steve
>
>
> ___
> mailop mailing list
>

Re: [mailop] Yahoo DMARC changes

2016-03-29 Thread Steve Atkins 

> On Mar 29, 2016, at 8:17 AM, Laura Atkins  wrote:
> 
> 
>> On Mar 28, 2016, at 8:20 PM, Vick Khera  wrote:
>> 
>> On Wed, Mar 23, 2016 at 11:15 AM, Steve Atkins  wrote:
>> 
>> > On Mar 22, 2016, at 9:35 PM,   wrote:
>> >
>> > Are you taking that approach because the workaround is less than ideal?  
>> > Otherwise the current “workaround” could be the new standard.
>> 
>> The workaround is terrible and breaks basic email functionality.
>> 
>> What's so terrible about setting the visible From address to something you 
>> control, and setting reply-to to the original address? I thought that was 
>> the acceptable workaround, at least as discussed at sessions at M3AAWG.
> 
> Filters. - Hard to selectively filter particular mailing list users. 
> 
> Searches - nearly impossible to search for mail from a particular user. 
> 
> Reply-To - many lists want to set reply-to: list rather than reply to author. 

Also, email headers have well-defined meanings.

The From: header specifies the author of the message, the email address of the 
person responsible for writing the message.
The Sender: header specifies the email address of the agent responsible for 
sending the message, when that's different to the author.
The Reply-To: header specifies the email address to which replies should be 
sent, when that's different to the author.

They have different meanings, and they're all useful, and used.

The problem with DMARC is that it insists that the From: field contain an email 
address in a domain from which it was sent. If that's not naturally the case - 
mailing lists and ESPs are two examples of that - then you cannot comply with 
both RFC 5322 originator field semantics and DMARC requirements.

All the hacks that mailing list operators have put in place to allow people to 
use their mailing lists contrary to the DMARC-published requirements of the 
domain owner are based on violating the RFC 5322 semantics.

You need to put an email address in the From: field that's in the same domain 
as the mailing list manager - the email address that should be in the Sender: 
field has to go in the From: field. That destroys any record of who the author 
of the email is. That breaks quite a lot of functionality - filtering and 
searching, as laura mentioned, but even more obviously any ability to easily 
reply to just the author.

To work around that last problem a list operator may put the real authors 
address in the reply-to field. That destroys any explicit reply-to that the 
author may have set. That in turn breaks other expectations. If a user wants to 
subscribe to a mailing list with one address, but wants individual replies to 
go to another one they can say "From: li...@blighty.com; Reply-To: 
st...@blighty.com" - this sort of DMARC mitigation breaks that.

Also, many lists already set the Reply-To to the list submission address - so 
they can't put the author address in that field, leaving them with no choice 
other than to change (long established) expectations of how the mailing list 
works, or to have the author email address appear nowhere in the mail where it 
can be used mechanically by any variant of a reply command.

All of these break user expectations for how email should work - all users, not 
just those at domains that are publishing DMARC p=reject records. Mailing list 
operators can make operational changes to mitigate the inconvenience for 
different classes of user, but they can't fix it entirely.

There is *no way* to fix this without fundamental changes to either RFC 5322 or 
DMARC as they are inherently incompatible.

ARC will make those fundamental changes to DMARC, but only for one specific use 
case - traditional email discussion lists. It'll be an improvement (though not 
a total fix) for that case, but it makes no improvement for other use cases (of 
which ESPs catering to smaller users are one major one, but there are others).

Cheers,
  Steve


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

Re: [mailop] Yahoo DMARC changes

2016-03-29 Thread Laura Atkins 

> On Mar 28, 2016, at 8:20 PM, Vick Khera  wrote:
> 
> On Wed, Mar 23, 2016 at 11:15 AM, Steve Atkins  > wrote:
> 
> > On Mar 22, 2016, at 9:35 PM, > 
> > > wrote:
> >
> > Are you taking that approach because the workaround is less than ideal?  
> > Otherwise the current “workaround” could be the new standard.
> 
> The workaround is terrible and breaks basic email functionality.
> 
> What's so terrible about setting the visible From address to something you 
> control, and setting reply-to to the original address? I thought that was the 
> acceptable workaround, at least as discussed at sessions at M3AAWG.

Filters. - Hard to selectively filter particular mailing list users. 

Searches - nearly impossible to search for mail from a particular user. 

Reply-To - many lists want to set reply-to: list rather than reply to author. 

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] Yahoo DMARC changes

2016-03-28 Thread Vick Khera 
On Wed, Mar 23, 2016 at 11:15 AM, Steve Atkins <st...@blighty.com> wrote:

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

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


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

Re: [mailop] Yahoo DMARC changes

2016-03-28 Thread Vick Khera 
On Tue, Mar 22, 2016 at 10:36 PM, Luke Martinez 
wrote:

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

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

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


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

Re: [mailop] Yahoo DMARC changes - Proxying SMTP auth for freemail users

2016-03-25 Thread Bill Campbell 
On Thu, Mar 24, 2016, Jay Hennigan wrote:
...
> The end result will be that the freemail account user will get locked  
> out or the account will be shut down. User will then blame the ESP for  
> disrupting his "business" email address.

I can't see this without thinking of one of my favorite Dilbert
cartoons.  "But your e-mail address reveals your newbie identity.
You're probably a goat herder or a cartoonist".  At the time I
think Scott Adams address as .

Bill
-- 
INTERNET:   b...@celestial.com  Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/  PO Box 820; 6641 E. Mercer Way
Voice:  (206) 236-1676  Mercer Island, WA 98040-0820
Fax:(206) 232-9186  Skype: jwccsllc (206) 855-5792

If you want government to intervene domestically, you're a liberal.  If you
want government to intervene overseas, you're a conservative.  If you want
government to intervene everywhere, you're a moderate.  If you don't want
government to intervene anywhere, you're an extremist -- Joseph Sobran

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

Re: [mailop] Yahoo DMARC changes

2016-03-24 Thread Franck Martin via mailop 
SMTP AUTH With or without OAUTH  (aka Submission) is the same functionally.
The difference is with OAUTH2 you don't have to share your password with
the ESP.

On Thu, Mar 24, 2016 at 7:09 AM, Suresh Ramasubramanian  wrote:

> If you are confident that all your customers doing this are low volume and
> legit, and none of them will ever be compromised, be my guest
>
> --srs
>
> > On 24-Mar-2016, at 7:27 PM, G. Miliotis 
> wrote:
> >
> > Now if you are suggesting that they will see multiple different logins
> on their SMTP from the same IP address, yes they will. If they consider
> this an attempt at spamming, i.e. I've harvested logins via phishing and am
> sending spam, maybe they should improve their filters.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes - Proxying SMTP auth for freemail users

2016-03-24 Thread G. Miliotis 

On 24/3/2016 18:17, Jay Hennigan wrote:
Once third-party mailers begin using the credentials of specific 
freemail accounts to send bulk mail that generates a non-trivial 
number of complaints and/or bounces, the battle has escalated.
I am only just recently mulling this over so I haven't really thought 
through the consequences of a mass adoption of this.


My first thoughts on the scenario you describe is that freemail 
providers can have a policy that outside mail sending access is NOT for 
bulk mail sending, via capping rates per IP/account/etc., using paypal 
features, etc. It will basically come down to the same basic problem 
they have now: identifying bulk email senders. They'll just have extra 
data points with their authenticated user to make that decision plus 
more ways to mitigate.


--GM

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

Re: [mailop] Yahoo DMARC changes - Proxying SMTP auth for freemail users

2016-03-24 Thread Michael Peddemors 

On 16-03-24 10:16 AM, Michael Wise wrote:

A question ...

Outside of the spam case, how typical is it for someone to send from one 
Freemail provider with a Reply-To: pointing to *ANOTHER* Freemail provider?

Just wondering.

Aloha,
Michael.



A lot in the spam box :)  It is actually one of our filtering rules to 
watch for this, (fairly low score by itself)..


And even worse, even in the Return-Path.

This is why I chuckle a little at Yahoo's new policy..

(redacted headers from a real spam)

Return-Path: 
Received: from ns502-vm11.bullet.mail.kks.yahoo.co.jp (HELO 
ns502-vm11.bullet.mail.kks.yahoo.co.jp) (183.79.57.66)

From: Serena Benson 
Reply-To: Serena Benson 

It would be helpful if Yahoo simply prevented anyone from sending out 
their email servers with a @gmail.com return path.




--
"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] Yahoo DMARC changes - Proxying SMTP auth for freemail users

2016-03-24 Thread Suresh Ramasubramanian 
There is of course the other part that various freemails just might not 
appreciate their customers sharing passwords  with a third party, like say an 
esp

--srs

On 24-Mar-2016, at 8:13 PM, G. Miliotis  wrote:

>> On 24-Mar-2016, at 7:27 PM, G. Miliotis  wrote:
>> 
>> Now if you are suggesting that they will see multiple different logins on 
>> their SMTP from the same IP address, yes they will. If they consider this an 
>> attempt at spamming, i.e. I've harvested logins via phishing and am sending 
>> spam, maybe they should improve their filters.
> 
>> On 24/3/2016 16:09, Suresh Ramasubramanian wrote:
>> If you are confident that all your customers doing this are low volume and 
>> legit, and none of them will ever be compromised, be my guest
>> 
>> --srs
> 
> A customer's account being compromised and sending spam will blacklist you 
> even via normal email operations, so I don't see any increased risk there. 
> We're supposed to have egress filtering anyway, right? Just set lower rate 
> limits for freemail accounts.
> 
> Lets compare a common scenario to this as a mental exercise. One of my 
> "normal" non-freemail customers gets compromised and starts sending spam to 
> freemail.com. Freemail.com bans my IP via their incoming filters, starts 
> 5xx'ing me. I see this, locate the customer, fix the problem and begin the 
> process of contacting freemail.com to get unbanned. How can I positively 
> PROVE to them that the compromise has gone away? They'll just have to take my 
> word for it. Probability of unban: zero, until enough time has passed for 
> filters to get wise to the fix. Which could be forever if you're a low volume 
> sender anyway (true story).
> 
> Conversely, in the case that a specific SMTP AUTH user sending from my server 
> getting compromised, they will ban me again, 5xx starts. I will notice 
> immediately and fix the problem with the client. Then, when I go to 
> freemail.com to get unbanned they will know the specific customer involved. 
> They will have a measure of how valid my claims that the issue is fixed are. 
> They have logs to check the account credentials were changed, they have a 
> contact and hey, it's a CUSTOMER or theirs telling them I've fixed it. Much 
> easier to believe. Much easier to unblock. At least in a reasonable world.
> 
> In addition, they can take escalating measures against this particular user 
> (rather than against all my customers) in the first place by disabling SMTP 
> auth for the account instead of outright banning the whole IP address. Then 
> the rest of THEIR CUSTOMERS using my server would not be impacted. For 
> example, Yahoo! does something similar by rate-limiting IPs rather than 
> outright banning them when their customers complain. So I just turn off 
> sending to Yahoo for 4 hours while I fix the customer and we're back in 
> business automagically. I may get 4 hours of queues and impact all Yahoo! 
> recipients, but at least I don't need to prove I'm not an elephant to a 
> support person that only has two buttons: "eject" and "patronize".
> 
> Sorry, this got rather long.
> 
> --GM

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

Re: [mailop] Yahoo DMARC changes

2016-03-24 Thread Suresh Ramasubramanian 
At least in india most of those have moved to whatsapp 

--srs

> On 24-Mar-2016, at 6:50 PM, Tara Natanson  wrote:
> 
> but for everyone of those theres the local PTA and the Brownie troop, or 
> soccer club.  The person setting up a mailling list isn't given an address at 
> the brownies domain or the local schools domain.  So there really are a LOT 
> of folks sending from @freewebmail domains still. 

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

Re: [mailop] Yahoo DMARC changes

2016-03-24 Thread Al Iverson 
On Thu, Mar 24, 2016 at 1:03 AM, Dave Warren  wrote:
> On 2016-03-23 16:32, Franck Martin via mailop wrote:
>>
>> In fact, these providers offer OAUTH2 to allow you to send as using their
>> infrastructure, and if you have bigger needs, many domains are going cheap
>> at the moment...
>>
>> Not ideal, but some options...
>>
>
> Are there really that many customers using freemail domains, yet paying for
> ESP services? For realsies?

Yes, at the SMB level. My friend's dive bar uses a Gmail address.
People whose "Tiny Letter" emails I've signed up for always seem to be
using webmail addresses. Even my other friend's jazz club, who does
have a domain for the website, it was a question of, do we pay to make
that domain available for email, or do we just use a free Gmail
account. They went the Gmail account route.

>And if so, wouldn't this be an obvious upsell
> opportunity or partnership to get these customers using their own domain?

And then somebody has to manage and map that domain. And then you have
the difficulty of making money off of that at the SMB level.

At the enterprise level, bigger customer level, sure, it makes total sense.

Even as a small business person myself in the past, I'd never
personally rely on a webmail domain for business. They could go under
or I could lose access to my mailbox. But you and I are smarter than
the average bear.

I think some ESPs offer use of a domain or subdomain by clients too
small / not smart enough to have their own domain. I expect that to
type of thing to become more common.

That's half of the ESP equation. The other half is reply forwarding.
Many ESPs have reply filtering and forwarding. Handling opt-outs
automatically, eating junk, and forwarding on legitimate replies.
Those forwarded replies are an issue in the new world order of DMARC.
Where I work, we have a setting that will rewrite the from address to
work around that, in a way similar to what mailing lists have been
doing. I'm in "wait in see" mode as far as whether or not I'd want to
utilize ARC to address that instead.

Regards,
Al
--
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] Yahoo DMARC changes

2016-03-24 Thread G. Miliotis 

On 24/3/2016 15:38, Steve Atkins wrote:

They do. And there are already quite a few dedicated B2B spammers taking 
advantage of that. Most of the deluge of spam from gmail appears to be from 
this sort of spammer at the moment. If gmail becomes concerned about that then 
the ability to plug into an individuals gmail account is likely to go away.

Cheers,
   Steve
If this happened they'd be losing those who don't want to use the web 
interface for mail.
Maybe this issue could be fixed by allowing users to set up IPs or 
ranges that they explicitly allow SMTP auth connections from and block 
everyone else, per user. Of course that would actually drive people to 
upgrade their mail away from freemail providers, which I doubt they'd 
want to do.


Solve the problem vs lose ad revenue, hm


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

Re: [mailop] Yahoo DMARC changes

2016-03-24 Thread G. Miliotis 

>On 24-Mar-2016, at 6:33 PM, G. Miliotis  wrote:
>
>In fact, as someone mentioned, we're currently looking into setting up our 
outgoing SMTP servers to send via each client's freemail account via SMTP auth. So 
that would cover the DMARC issue, too. Provided they don't block us, of course.


On 24/3/2016 15:27, Suresh Ramasubramanian wrote:

You will light up their filters like a Christmas tree

--srs

Why would using valid authentication credentials to send mail 
originating from the actual owners of the account in question be against 
any policy? Isn't this why they provide access to send via SMTP in the 
first place?


Now if you are suggesting that they will see multiple different logins 
on their SMTP from the same IP address, yes they will. If they consider 
this an attempt at spamming, i.e. I've harvested logins via phishing and 
am sending spam, maybe they should improve their filters. The senders 
won't spamming, they will be sending extremely low volumes of mail and 
they will only be sending to the freemail provider's domains. They are 
easy to filter out, at least in my opinion.


Now if the freemail providers (in this case MS) can't be bothered with 
this edge case they're forcing us into, *shrug*. At least I will have 
tried my best for my customers.


--GM



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

Re: [mailop] Yahoo DMARC changes

2016-03-24 Thread Suresh Ramasubramanian 
You will light up their filters like a Christmas tree

--srs

> On 24-Mar-2016, at 6:33 PM, G. Miliotis  wrote:
> 
> In fact, as someone mentioned, we're currently looking into setting up our 
> outgoing SMTP servers to send via each client's freemail account via SMTP 
> auth. So that would cover the DMARC issue, too. Provided they don't block us, 
> of course.

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

Re: [mailop] Yahoo DMARC changes

2016-03-24 Thread G. Miliotis 

On 24/3/2016 07:03, Dave Warren wrote:
Are there really that many customers using freemail domains, yet 
paying for ESP services? For realsies? And if so, wouldn't this be an 
obvious upsell opportunity or partnership to get these customers using 
their own domain? 
As a small ESP, my servers keep getting blocked by MS for no reason, so 
I actually have to recommend my customers keep their "old" hotmail/msn 
address so they can send to MS domains while I play hide-n-seek getting 
new IPs to send from/wait for delisting. So there's a real-life 
situation of freemail+paid ESP services.


In fact, as someone mentioned, we're currently looking into setting up 
our outgoing SMTP servers to send via each client's freemail account via 
SMTP auth. So that would cover the DMARC issue, too. Provided they don't 
block us, of course.


Another case is some customers want their managed mail services on their 
"proper" domain but want to keep their freemail accounts because they've 
given out business cards etc so during a transition period, which could 
be years, they keep both.


--GM



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

Re: [mailop] Yahoo DMARC changes

2016-03-23 Thread Franck Martin via mailop 
In fact, these providers offer OAUTH2 to allow you to send as using their
infrastructure, and if you have bigger needs, many domains are going cheap
at the moment...

Not ideal, but some options...

On Wed, Mar 23, 2016 at 3:45 PM, Steve Atkins  wrote:

>
> > On Mar 23, 2016, at 3:16 PM, Joel Beckham  wrote:
> >
> >
> > It's likely that ARC will become the new - much better - workaround
> eventually, modulo the inevitable deployment issues. http://arc-spec.org
> >
> > I thought that ARC doesn't help with the ESP use case, or am I missing
> something there?
>
> Probably not, no. The long term answer there is probably much the same as
> the short term one - declining to send mail "from" users of those consumer
> ISPs who've published p=reject records, and encouraging them to get an
> email address elsewhere (whether that be an email address controlled by the
> ESP or one from a more appropriate mailbox provider).
>
> Cheers,
>   Steve
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes

2016-03-23 Thread Joel Beckham 
>
> It's likely that ARC will become the new - much better - workaround
> eventually, modulo the inevitable deployment issues. http://arc-spec.org
> 
>

I thought that ARC doesn't help with the ESP use case, or am I missing
something there?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Yahoo DMARC changes

2016-03-23 Thread Steve Atkins 

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

The workaround is terrible and breaks basic email functionality.

It's likely that ARC will become the new - much better - workaround eventually, 
modulo the inevitable deployment issues. http://arc-spec.org

Cheers,
  Steve

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


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

Re: [mailop] Yahoo DMARC changes

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

On Tue, Mar 22, 2016 at 7:54 PM, Vick Khera  wrote:

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


-- 

Luke Martinez
SendGrid Deliverability Consultant
520.400.5693
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop