Re: [mailop] A question ... who is optinx . org ???

[Al Iverson via mailop]

The domain optinx dot org is registered with Godaddy, ownership hidden
behind domains by proxy. MX points at Godaddy's mail service. Web
service hosted in a netblock called "OLA Workplace Skills Training
Centre." in ARIN. Has a generic "unsub from our offers" page. Reverse
DNS for the /24 is mostly empty, except for a reference to
investorsecret dot net and a handful of hosts under inetmgmt dot net.
The former is parked, the latter is some generic ISP or somebody
trying to look like one -- can't tell.

"OLA Workplace Skills Training Centre" traces to 1655 Palm Beach Lakes
Blvd. Suite C-1005, West Palm Beach, FL, 33401 which appears to be
SmartAdv LLC or Intelligent Media Group or Intelligent Holdings, Inc.
which leads to this at http://www.intelligentholdings.com/company/
which says "IHI identifies profitable marketing opportunities, then
fully exploits them using a massive consumer database and
comprehensive marketing system that combines the targeting power of
the Internet with a personal touch of professional sales." Gosh, they
certainly don't say that they engage in spam-related activities.

I don't know anything about them personally but it sure seems like
senders with explicit opt-in permission generally don't need a third
party opt-out service and where I've run into it it tends to be used
with third-party/co-reg/"house list" types of mail that neither you
and I are particularly fond of, and the website of the network owner
or related entity sure uses a lot of terms that sound a bit
dog-whistle in nature to me. Not sure if it's enough to convict but it
certainly does not instill confidence of good intent.

Cheers,
Al

On Fri, Feb 7, 2020 at 7:28 PM Michael Wise via mailop
 wrote:
>
>
>
> Is their presence in an email spamsign?
>
> Just curious.
>
>
>
> Aloha,
>
> Michael.
>
> --
>
> Michael J Wise
> Microsoft Corporation| Spam Analysis
>
> "Your Spam Specimen Has Been Processed."
>
> Open a ticket for Hotmail ?
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
al iverson // wombatmail // chicago
http://www.aliverson.com
http://www.spamresource.com

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

[mailop] A question ... who is optinx . org ???

[Michael Wise via mailop]

Is their presence in an email spamsign?
Just curious.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for Hotmail ?

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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Brandon Long via mailop]

On Fri, Feb 7, 2020 at 7:37 AM Ralf Hildebrandt via mailop <
mailop@mailop.org> wrote:

> > They answer to mails from noreply-Addresses.
>
> Exactly.
>
> > > MLMs don't use "noreply" address as well - they use their own
> list-specific
> > > "bounce" address as envelope-from.
> >
> > Yes, but Exchange/Outlook will not reply to the Envelope sender, but to
> > the From: as Ralf stated.
>
> I've been through this many times: I set up a mailinglist on mailman
> (VERP enabled), fill in all the addresses and then send my
> announcement to the list. I explicitly specify a reply-to: header
> which is not being stripped by the list.
>
> Then, shit happens.
>
> * I get autoreplies to my address (expected, since it's in the From:
> header)
> * I get autoreplies to the envelope sender address (I only see them
> because I check the mailman logs)
> * I get real human replies to my address (why? I explicitly specified a
> reply-to: header?!)
> * I get real human replies to my address and the reply-to: address
> * I get crazy NDRs to my address
>
> So I guess that's why people just give up and use a "noreply"
> address in the From:, because they cannot be bothered with the shit
> mentioned above.
>

If you send out a billion messages, you will get millions of real human
replies that have nothing
to do with the contents of the email notification and are often not
actionable at all.

Reading and responding to those costs real money in terms of customer
support.

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

Re: [mailop] why does this list break DKIM?

[Brandon Long via mailop]

Mailing lists which don't break DKIM are the exception, not the norm.

For better or worse, users expect their mailing lists to add subject
prefixes and footers.

Rejecting messages with broken DKIM is explicitly against the DKIM RFC.

https://tools.ietf.org/html/rfc6376#section-6.1

> "Survivability of signatures after transit is not guaranteed, and
> signatures can fail to verify through no fault of the Signer.  Therefore, a
> Verifier SHOULD NOT treat a message that has one or more bad signatures and
> no good signatures differently from a message with no signature at all."


Brandon

On Fri, Feb 7, 2020 at 3:05 PM Aragon Gouveia via mailop 
wrote:

> Hello,
>
> Does anyone know why this list breaks DKIM verification?  In particular
> it looks like it's altering From, Reply-To, and Cc headers, and failing
> to perform any kind of resigning too.
>
> I'm new here.  I run a small mail system with users who subscribe to
> this list, and they're complaining about not receiving posts.  At a
> glance this list's (mis)configuration seems very surprising considering
> the subject matter here.  Can anyone fix this?
>
>
> Regards,
> Aragon
>
> ___
> 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] mailbox auth for system integration

[Brandon Long via mailop]

On Fri, Feb 7, 2020 at 4:07 PM Philip Paeps via mailop 
wrote:

> On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote:
>
> On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:
>
> On 2020/02/07 13:41, Philip Paeps via mailop wrote:
>
> I think the only viable solution will be to set up forwarders
>
> Or pass it through a proxy which knows how to authenticate. I'm not
> aware of any that have been written yet but it shouldn't be too complex.
>
> I just spent an instructive half hour in a web browser trying to jump
> through the hoops to set this up. Before you can create a "token", you need
> to create a "credential". In order to create that you need a "project". And
> then you need a "application consent screen".
>
> All of this to fetch email unattended.
>
> This is the very definition of "user hostile".
>
> And reportedly, the "tokens" can expire. So supposedly, this needs to be
> done regularly?
>
> Furthermore: this only fixes *retrieving* email (and then only IMAP,
> because it doesn't seem to work for POP3). Presumably similar hoops need to
> be jumped to send email through smtp.gmail.com. What fun!
>
Note you should be able to use the same project and client id/secret for
smtp and pop/imap.  You might be able to use the same token if you ask for
the scopes for both.

I know it's annoying.  See the previous long thread on why passwords are
bad, as for restricting access to your mailbox, there was the excitement
from 2018: https://www.androidauthority.com/gmail-snooping-882270/ which
lead to Google being a lot more paranoid about third party access
https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems
 .

The hoops you're jumping through aren't for users, they're for
developers... and they're only the first steps, you then need to get
approval

from Google to expand beyond 100 users.  Many open source projects have
decided to punt on that, and so they require their users to get their own
client tokens.  I understand, I made the same choice when I added oauth
support to mutt last year.

For users just using the most popular mail apps, using oauth instead of
password auth is at least as easy.

We worked hard to make sure Gmail supported open standards for access by
third parties, and not locking our services down or locking people in...
and then others took advantage of our users, and that's why we can't have
nice things.  Access is still possible, the process is still mostly
standards based (automated discovery of oauth endpoints and client
registration is the missing part)... but there are a lot more hoops.

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

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

On 2020-02-07 15:51:22 (-0800), Philip Paeps wrote:

On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:

On 2020/02/07 13:41, Philip Paeps via mailop wrote:

I think the only viable solution will be to set up forwarders


Or pass it through a proxy which knows how to authenticate. I'm not
aware of any that have been written yet but it shouldn't be too 
complex.


I just spent an instructive half hour in a web browser trying to jump 
through the hoops to set this up.  Before you can create a "token", 
you need to create a "credential".  In order to create that you need a 
"project".  And then you need a "application consent screen".


All of this to fetch email unattended.

This is the very definition of "user hostile".

And reportedly, the "tokens" can expire.  So supposedly, this needs to 
be done regularly?


Furthermore: this only fixes _retrieving_ email (and then only IMAP, 
because it doesn't seem to work for POP3).  Presumably similar hoops 
need to be jumped to send email through smtp.gmail.com.  What fun!


Progress is hard.  I am getting old.  I should invest in a good lawn 
chair.  And a lawn! :-)


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:

On 2020/02/07 13:41, Philip Paeps via mailop wrote:

I think the only viable solution will be to set up forwarders


Or pass it through a proxy which knows how to authenticate. I'm not
aware of any that have been written yet but it shouldn't be too 
complex.


I just spent an instructive half hour in a web browser trying to jump 
through the hoops to set this up.  Before you can create a "token", you 
need to create a "credential".  In order to create that you need a 
"project".  And then you need a "application consent screen".


All of this to fetch email unattended.

This is the very definition of "user hostile".

And reportedly, the "tokens" can expire.  So supposedly, this needs to 
be done regularly?


Interesting times.

"Dear customer: if you want me to be able to read your email after 
Google turns off passwords next year, you will have to arrange to 
forward my email to philip+customern...@trouble.is.  Thank you."


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

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

Re: [mailop] mailbox auth for system integration

[Stuart Henderson via mailop]

On 2020/02/07 14:36, Philip Paeps via mailop wrote:
> On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:
> > On 2020/02/07 13:41, Philip Paeps via mailop wrote:
> > > I think the only viable solution will be to set up forwarders
> > 
> > Or pass it through a proxy which knows how to authenticate. I'm not
> > aware of any that have been written yet but it shouldn't be too complex.
> 
> It sounds like we have about one year for that to happen before people lose
> access to their email.

I don't think that will be a problem.

> > > Unless fetchmail starts supporting Oauth, I will lose access to
> > > certain customer mailboxes when Google decides to stop accepting
> > > "app passwords".
> > 
> > Do you need to use fetchmail? getmail has supported that for some time.
> > (fetchmail development code supports oauth2, but it isn't in a release
> > yet).
> 
> I'm not married to fetchmail.  I had never heard of getmail.  If it supports
> oauth completely unattended, that would solve my use case.  I'll look into
> it more closely.  Thanks for the pointer.
> 
> As far as I understand it though, oauth requires a human operator and a
> webbrowser to generate the tokens.  I wonder how getmail satisfies that
> requirement.

Only when initially granting permissions for a client to access (or if
permissions were revoked and you need to grant them again). Otherwise it's
automatic, you definitely don't need a human operator for each login.


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

[mailop] why does this list break DKIM?

[Aragon Gouveia via mailop]

Hello,

Does anyone know why this list breaks DKIM verification?  In particular 
it looks like it's altering From, Reply-To, and Cc headers, and failing 
to perform any kind of resigning too.


I'm new here.  I run a small mail system with users who subscribe to 
this list, and they're complaining about not receiving posts.  At a 
glance this list's (mis)configuration seems very surprising considering 
the subject matter here.  Can anyone fix this?



Regards,
Aragon

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

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

On 2020-02-07 14:32:50 (-0800), Stuart Henderson wrote:

On 2020/02/07 13:41, Philip Paeps via mailop wrote:

I think the only viable solution will be to set up forwarders


Or pass it through a proxy which knows how to authenticate. I'm not 
aware of any that have been written yet but it shouldn't be too 
complex.


It sounds like we have about one year for that to happen before people 
lose access to their email.


Unless fetchmail starts supporting Oauth, I will lose access to 
certain customer mailboxes when Google decides to stop accepting "app 
passwords".


Do you need to use fetchmail? getmail has supported that for some 
time.  (fetchmail development code supports oauth2, but it isn't in a 
release yet).


I'm not married to fetchmail.  I had never heard of getmail.  If it 
supports oauth completely unattended, that would solve my use case.  
I'll look into it more closely.  Thanks for the pointer.


As far as I understand it though, oauth requires a human operator and a 
webbrowser to generate the tokens.  I wonder how getmail satisfies that 
requirement.


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

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

Re: [mailop] mailbox auth for system integration

[Stuart Henderson via mailop]

On 2020/02/07 13:41, Philip Paeps via mailop wrote:
> I think the only viable solution will be to set up forwarders

Or pass it through a proxy which knows how to authenticate. I'm not
aware of any that have been written yet but it shouldn't be too complex.

> Unless fetchmail starts supporting Oauth, I will lose access to certain
> customer mailboxes when Google decides to stop accepting "app passwords".

Do you need to use fetchmail? getmail has supported that for some time.
(fetchmail development code supports oauth2, but it isn't in a release yet).


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

Re: [mailop] mailbox auth for system integration

[Philip Paeps via mailop]

On 2020-02-07 12:51:24 (-0800), Jesse Thompson via mailop wrote:
Microsoft O365 and Google G Suite are both retiring basic 
authentication for client access to mailboxes.  As a result, ALL 
clients will need to support OAuth on a very short timeline.


End-user MUAs aside, I'm worried about systems that rely on a mailbox 
for integration (RT, and the like).  I suspect that there is a long 
tail of those systems that are critical to line-of-business operations 
which don't switch to OAuth in time (for a variety of reasons).


I was holding on to "app passwords" as the last bastion for these 
systems to integrate.


It's unclear if Microsoft will continue to support app passwords with 
their Azure AD MFA product, which only works for organizations who 
don't federate authentication to a local IdP anyway.  Google plans to 
stop creation of App Specific passwords in June 15th, 2020 and 
grandfathering in the rest until February 2021.


Thoughts?


I think the only viable solution will be to set up forwarders to forward 
the email out of Microsoft/Google to a mailbox that does support working 
authentication for systems that don't come with web browsers and human 
operators.


Unless fetchmail starts supporting Oauth, I will lose access to certain 
customer mailboxes when Google decides to stop accepting "app 
passwords".  Unless those customers can forward my email elsewhere, I 
guess I'll have to find some new customers?  Thanks Google!  (Microsoft 
is probably also part of the larger problem but I don't have any 
customers insisting I have a mailbox in their domain.)


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

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

[mailop] mailbox auth for system integration

[Jesse Thompson via mailop]

Microsoft O365 and Google G Suite are both retiring basic authentication for 
client access to mailboxes.  As a result, ALL clients will need to support 
OAuth on a very short timeline.

End-user MUAs aside, I'm worried about systems that rely on a mailbox for 
integration (RT, and the like).  I suspect that there is a long tail of those 
systems that are critical to line-of-business operations which don't switch to 
OAuth in time (for a variety of reasons).

I was holding on to "app passwords" as the last bastion for these systems to 
integrate.

It's unclear if Microsoft will continue to support app passwords with their 
Azure AD MFA product, which only works for organizations who don't federate 
authentication to a local IdP anyway.  Google plans to stop creation of App 
Specific passwords in June 15th, 2020 and grandfathering in the rest until 
February 2021.

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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[John Levine via mailop]

In article ,
Philip Paeps via mailop  wrote:
>On 2020-02-07 08:34:13 (-0800), Jaroslaw Rafa via mailop wrote:
>> It would be best if autoresponders simply didn't reply to messages 
>> from mailing lists.
>
>That windmill is not going to budge no matter how much you try to tilt it...

People who write mail software have known at least since the 1980s
that an autoresponder should only respond if the recipient's address
is on the To: or maybe the Cc: line.  I have a procmail man page from
about 1991 with an autoresponder recipe that makes that check.

Unfortunately, none of those people appear ever to have worked in Redmond WA.



-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Philip Paeps via mailop]

On 2020-02-07 08:34:13 (-0800), Jaroslaw Rafa via mailop wrote:
It would be best if autoresponders simply didn't reply to messages 
from mailing lists.


That windmill is not going to budge no matter how much you try to tilt 
it...


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises

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

[mailop] Contact at orbitallcorp.com.br?

[Scott Southard via mailop]

We're having issues at orbitallcorp.com.br and have reached out to
postmas...@orbitallcorp.com.br without hearing back.

Anyone have a contact I could chat with?
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Alessandro Vesely via mailop]

On Fri 07/Feb/2020 16:34:38 +0100 Ralf Hildebrandt via mailop wrote:
> Then, shit happens.
> 
> * I get autoreplies to my address (expected, since it's in the From: header)
> * I get autoreplies to the envelope sender address (I only see them because I 
> check the mailman logs)
> * I get real human replies to my address (why? I explicitly specified a 
> reply-to: header?!)
> * I get real human replies to my address and the reply-to: address
> * I get crazy NDRs to my address
> 
> So I guess that's why people just give up and use a "noreply"
> address in the From:, because they cannot be bothered with the shit
> mentioned above.


Hmm.. I doubt noreply is effective with MLM lists.  If you want replies, you
better use a functioning email address.  Still need to shovel out shit, though.

What I'd like is a 'noautoreply' tool.  MS' X-Auto-Response-Suppress: doesn't
seem to work...


Best
Ale
-- 


















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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Jaroslaw Rafa via mailop]

Dnia  7.02.2020 o godz. 16:34:38 Ralf Hildebrandt via mailop pisze:
> Then, shit happens.
> 
> * I get autoreplies to my address (expected, since it's in the From: header)
> * I get autoreplies to the envelope sender address (I only see them because I 
> check the mailman logs)
> * I get real human replies to my address (why? I explicitly specified a 
> reply-to: header?!)
> * I get real human replies to my address and the reply-to: address
> * I get crazy NDRs to my address
> 
> So I guess that's why people just give up and use a "noreply"
> address in the From:, because they cannot be bothered with the shit
> mentioned above.

Well, while I understand that one is not interested in autoreplies, why
getting real human replies to your message should bother anyone?

If you don't expect to get any replies, don't send the message in the first
place. Period. If you are sending anything, you *should* expect replies.

Using a "noreply" address is just that - stating "I'm not interested in
replies". But again - if you aren't interested in replies, don't send.

I understand that you may want all replies directed to a reply-to address
instead your "From" address. But there are MUAs that simply don't pay
attention to "Reply-To:" header and always reply to "From:" address.
Besides these broken MUAs, there is also a whole lot of MUAs that give the
user a choice to reply either to "Reply-To:" or to "From:" address - and the
user just clicks a wrong option.

That's something that just can't be avoided. But anyway, if someone is
sending away anything, he/she *should* expect at least real human replies
(and some of them may be misdirected, that's just the way it is. 
Redirecting the message to a correct recipient takes a fraction of second if
you are using a good MUA).

Autoreplies are another thing and we should think of some smart method
to filter them out. If most of them are from Exchange/Outlook maybe there is
something similar in headers that can be used for that purpose.

It would be best if autoresponders simply didn't reply to messages from
mailing lists. The good old "vacation" program does something like this - it
replies only when the recipient's address is explicitly listed in the "To:"
or "Cc:" header. As mailing list messages typically have the list address in
the "To:" field, vacation won't reply to them. There are also typical list
headers (like "List-Unsubscribe:") and autoresponder can be programmed to
ignore messages with these headers present. It's just lazyness or
incompetence of people programming the autoresponders.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

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

Re: [mailop] [EXTERNAL] Uptick in live.com blocks from AWS 1/20

[Abuse via mailop]

Hello Michael,

What I understand is that this Boilerplate language is totally unhelpful. 
Whether it's spoken by robots or live humans is exactly the same...

In the end, our IPs remain RED, our customers are furious, Microsoft doesn't 
care, and we still don't know what to do.
Frustration, especially as these same IPs have good reputation anywhere else, 
and be sure we work hard to reach such a result!

I don't blame you personally, Michael, thank you for representing Microsoft 
here. So, have a good weekend.
As for me, I'm going to hope for a miracle now.

Franck
OXEMIS.


De : mailop [mailto:mailop-boun...@mailop.org] De la part de Michael Wise via 
mailop
Envoyé : jeudi 6 février 2020 21:07
À : mailop@mailop.org
Objet : Re: [mailop] [EXTERNAL] Uptick in live.com blocks from AWS 1/20


Heh.

A perfect example of the Turing Test, but not in the way most people think of 
it…

  https://www.imdb.com/title/tt2084970/

You really were talking to a live human after step 2, but understand that they 
are *REQUIRED* by our Legal Department, in order to comply with many, many laws 
in many, many jurisdictions, to reply *ONLY* and pretty much always with 
Boilerplate, and to follow strict policy on mitigation. And that’s all I can 
say on that matter.

https://talosintelligence.com/reputation_center/lookup?search=217.182.111.1

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for Hotmail ?

From: Abuse 
Sent: Thursday, February 6, 2020 9:06 AM
To: mailop@mailop.org
Cc: Michael Wise 
Subject: RE: [mailop] [EXTERNAL] Uptick in live.com blocks from AWS 1/20

Hello everybody,

All right Michael, we all know that everything must go thru the Support Funnel, 
but what if :

- The first response is from a robot
- The second response is from a robot
- The third response is from a robot
- The fourth response is from a robot
- The fifth response is from a robot
- The sixth response is from a robot
- The seventh response never comes
?

You will find below a link to a sample exchange I am talking about.
I've blurred certain portions of text to preserve the identity of my clients, 
thank you for your understanding.
https://oxemis.net/OXEMIS/41D9F75AC4ED4895A7673B48A43CB6D8.php

All that wasted time could be summed up in one sentence: "you're blocked but 
you don't need to know why. Just accept it".

Franck
OXEMIS.


De : mailop [mailto:mailop-boun...@mailop.org] De la part de Michael Wise via 
mailop
Envoyé : mardi 4 février 2020 00:40
À : rps462; mailop@mailop.org
Objet : Re: [mailop] [EXTERNAL] Uptick in live.com blocks from AWS 1/20


This form … is the one.
There is a 24 hr SLA, but from time to time, it seems that tickets can get lost.

The first response will be from a robot giving you the SRX # which you *NEED* 
in order to know that a case has been opened, and that should come relatively 
quickly.
The second response will also be from the robot, announcing the automated 
mitigation, if any.

If that mitigation is not to your liking, then *RESPOND* to that email and 
state your case.

We’ve been told that *EVERYTHING* must go thru the Support Funnel … Full Stop.

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Open a ticket for 
Hotmail
 ?

From: mailop mailto:mailop-boun...@mailop.org>> On 
Behalf Of rps462 via mailop
Sent: Thursday, January 30, 2020 6:50 AM
To: mailop@mailop.org
Subject: [EXTERNAL] [mailop] Uptick in live.com blocks from AWS 1/20

"Please contact your Internet service provider since part of their network is 
on our blocklist (S3140). You can also refer your provider to 
http://mail.live.com/mail/troubleshooting.aspx#errors."

I have an ISP based out of AWS that has been getting this error since 1/20. No 
way to make a remediation request from that url, but I eventually found a form 
on 

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Ralf Hildebrandt via mailop]

> They answer to mails from noreply-Addresses.

Exactly.
 
> > MLMs don't use "noreply" address as well - they use their own list-specific
> > "bounce" address as envelope-from.
> 
> Yes, but Exchange/Outlook will not reply to the Envelope sender, but to
> the From: as Ralf stated.

I've been through this many times: I set up a mailinglist on mailman
(VERP enabled), fill in all the addresses and then send my
announcement to the list. I explicitly specify a reply-to: header
which is not being stripped by the list.

Then, shit happens.

* I get autoreplies to my address (expected, since it's in the From: header)
* I get autoreplies to the envelope sender address (I only see them because I 
check the mailman logs)
* I get real human replies to my address (why? I explicitly specified a 
reply-to: header?!)
* I get real human replies to my address and the reply-to: address
* I get crazy NDRs to my address

So I guess that's why people just give up and use a "noreply"
address in the From:, because they cannot be bothered with the shit
mentioned above.

--
Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netzwerk

Campus Benjamin Franklin (CBF)
Haus I | 1. OG | Raum 105
Hindenburgdamm 30 | D-12203 Berlin

Tel. +49 30 450 570 155
ralf.hildebra...@charite.de
https://www.charite.de

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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Thomas Walter via mailop]

On 07.02.20 14:53, Jaroslaw Rafa via mailop wrote:
>> If you're using a MLM, the "real" bounces go to the bounce processor
>> of the MLM. But stuff like Exchange/Outlook will autoreply to the
>> "From:"-Header address.
> 
> I don't understand - what does "noreply" address have to do with
> autoresponders?
> Autoresponders don't send mail from a "noreply" address. They almost always
> send mail from the address of the actual recipient of the message.

They answer to mails from noreply-Addresses.

> MLMs don't use "noreply" address as well - they use their own list-specific
> "bounce" address as envelope-from.

Yes, but Exchange/Outlook will not reply to the Envelope sender, but to
the From: as Ralf stated.

Regards,
Thomas Walter

-- 
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/

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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Jaroslaw Rafa via mailop]

Dnia  7.02.2020 o godz. 14:14:14 Ralf Hildebrandt via mailop pisze:
> > > why is it that everyone is still using noreply addresses to send 
> > > notifications
> > > and other one-way messages?
> 
> Autoresponders. (out of office mostly).
> 
> If you're using a MLM, the "real" bounces go to the bounce processor
> of the MLM. But stuff like Exchange/Outlook will autoreply to the
> "From:"-Header address.

I don't understand - what does "noreply" address have to do with
autoresponders?
Autoresponders don't send mail from a "noreply" address. They almost always
send mail from the address of the actual recipient of the message.

MLMs don't use "noreply" address as well - they use their own list-specific
"bounce" address as envelope-from.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

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

Re: [mailop] [ext] Re: Business justification to use noreply sender addresses?

[Ralf Hildebrandt via mailop]

> > why is it that everyone is still using noreply addresses to send 
> > notifications
> > and other one-way messages?

Autoresponders. (out of office mostly).

If you're using a MLM, the "real" bounces go to the bounce processor
of the MLM. But stuff like Exchange/Outlook will autoreply to the
"From:"-Header address.

Ralf Hildebrandt
Charité - Universitätsmedizin Berlin
Geschäftsbereich IT | Abteilung Netzwerk

Campus Benjamin Franklin (CBF)
Haus I | 1. OG | Raum 105
Hindenburgdamm 30 | D-12203 Berlin

Tel. +49 30 450 570 155
ralf.hildebra...@charite.de
https://www.charite.de

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

Re: [mailop] Business justification to use noreply sender addresses?

[Alessandro Vesely via mailop]

On Thu 06/Feb/2020 19:37:39 +0100 Patrick Ben Koetter via mailop wrote:
> 
> why is it that everyone is still using noreply addresses to send notifications
> and other one-way messages?
> 
> [...]
> 
> - It allows to apply a DKIM signature thus allowing to align with DMARC
>   policy.


DKIM has no business with the envelope-from.


Best
Ale
-- 












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