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

[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 - Proxying SMTP auth for freemail users

[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

[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

[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