Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

[Stefan Bauer via mailop]

I did in my first mail.



https://nopaste.linux-dev.org/?1321451



Stefan





-Ursprüngliche Nachricht-
Von: Luis E. Muñoz via mailop 
Gesendet: Freitag 10 Juli 2020 02:49
An: mailop 
Betreff: Re: [mailop] Post-processing Journal-Mails coming from O365, 
forwardedMail





On 8 Jul 2020, at 22:36, Stefan Bauer via mailop wrote:

> there is a feature in O365 that forwards mails (in/out/both..) to an 
> archive-mailbox for long-term archiving.
>
> We grab this mails via pop. However our available mail-readers 
> (Thunderbird, Kopano) show the original mail as attachment.
>
> This is the „envelope wrapper“ format. It contains the _final_ 
> recipient(s) of the email (eg after aliasing, distribution list 
> expansion etc), and contains the original email - headers and body - 
> unchanged. The advantage is that the archiving process does not need 
> to do any of the logic Exchange does (no further LDAP lookups etc).

Can someone donate a test message through pastebin? I would like to take 
a look at one directly.

Best regards

-lem

___
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] Intermittent slow email delivery

[Ángel via mailop]

On 2020-07-09 at 12:46 -0700, Job Cacka wrote:
> If you work with one of these relays and can shed light on the delay I
> would love to know how to get it fixed.


You have no logs, and provide little to no detail. You tried to contact
with those organizations, but you were fruitless. It's almost impossible
to figure out what happens to people on this mailing list.

I would suggest a couple of strategies:

First, you disclose the actual domain and provide a couple of test
mailboxes, so that people here that may be willing to have a look to
*your* problem can at least check if from their side the dns is ok, if
your primary MX is broken, if their clients provide the same abnormal
behavior when mailing those mails, etc.


Second option. You involve your customer on this investigation.

- The email issue caused a damage to your customer.
- Your customer is not using "gmail", but a business version of it.
- From your point of view, it is gmail's fault, since it didn't deliver
the email to you until 19 hours later (although we can guess that the
real problem will be somewhere in your setup, since it's not just gmail
failing to properly deliver on time).
- Thus you get your customer to open a ticket with gmail on why they
took 19 hours to deliver their email. This is the same question you
wanted gmail to answer you, but asked by a paying gmail customer that
suffered its consequences.
I expect that Google will be able to provide ample justification on
*why* their systems were unable to deliver it earlier (e.g. they tried
to connect from a dozen ip address, but were unable since -after you
investigate- your firewall was any dropping packets from most of their
outgoing servers).

Once you get the actual view of the delay from their side, you should be
able to progress towards fixing it.

Best regards




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

Re: [mailop] Is DNS-over-HTTPS bad? Sure.

[Noel Butler via mailop]

On 08/07/2020 18:57, Laura Atkins via mailop wrote:

> I expect that most of the telcos are unlikely to have any instrumentation for 
> tracking users beyond what is needed to ensure the service works. The 
> companies that are offering DoH as a service and have gone so far as to talk 
> about what they're doing with the data likely have a lot more instrumentation 
> and the ability to track users than the telcos do.

Exactly!   

In fact, if "free uncounted traffic usage" to select sites/networks
(mirrors, MS, netflix) was not thing, netflow wouldn't be either. 
-- 
Kind Regards, 

Noel Butler 

This Email, including attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate any part of
this message without the authors express written authority to do so. If
you are not the intended recipient, please notify the sender then delete
all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is DNS-over-HTTPS bad? Sure.

[Noel Butler via mailop]

On 07/07/2020 22:18, Stuart Henderson via mailop wrote:

> Looking at netflow data, it's at least aggregated with other devices
> behind the same NAT IP, and a lot of it is just "tcp 443 to cloudflare"
> or whatever which tells a lot less than DNS query data.

But if you are the ISP, NAT doesnt matter - unless your one of the
unlucky souls forced to run CGNAT that is 

-- 
Kind Regards, 

Noel Butler 

This Email, including attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate any part of
this message without the authors express written authority to do so. If
you are not the intended recipient, please notify the sender then delete
all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

[Luis E. Muñoz via mailop]

On 8 Jul 2020, at 22:36, Stefan Bauer via mailop wrote:

there is a feature in O365 that forwards mails (in/out/both..) to an 
archive-mailbox for long-term archiving.


We grab this mails via pop. However our available mail-readers 
(Thunderbird, Kopano) show the original mail as attachment.


This is the „envelope wrapper“ format. It contains the _final_ 
recipient(s) of the email (eg after aliasing, distribution list 
expansion etc), and contains the original email - headers and body - 
unchanged. The advantage is that the archiving process does not need 
to do any of the logic Exchange does (no further LDAP lookups etc).


Can someone donate a test message through pastebin? I would like to take 
a look at one directly.


Best regards

-lem

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

Re: [mailop] Does anyone have experience with Gmail lockouts?

[Brian Toresdahl via mailop]

I had some PM experience with this in my last job (email automation for B2B
sales, via user's email account).

2 things seemed to help here:
1. Short term, consider upgrading to a plan that gets them support. They're
going to have a rough time reversing the lockouts otherwise.
2. Long term, consider reducing the volume of unwanted mail. This will
reduce the likelihood of Gmail lockouts occuring again. Reduce the unwanted
email with better research into the right contacts, improve the value prop
of their content, or (ideally) do both. Or change nothing in their strategy
at all and just send less email. Doing the same thing, at the same volumes,
won't make the lockout problem go away (not even paying for support).

B2B mailing is an odd niche to consult for deliverability, since
documentation is almost non-existent, and feedback loops don't exist. But
lucrative if you can solve it, good luck!

On Thu, Jul 9, 2020 at 3:17 PM Michael Peddemors via mailop <
mailop@mailop.org> wrote:

> Gmail finally locking down on spamming from Gsuite?
> Will wonders never cease...
>
> ;)
>
> (Hey, actually the spam folder DOES seem to have less the last few days)
>
> On 2020-07-09 2:57 p.m., Nathan She via mailop wrote:
> > Hey everyone,
> >
> > A client of ours is seeing their sales reps and account managers locked
> > out of their G-suite accounts. Upon trying to log in, they get the
> > message “It looks like this account was used in a way that violated
> > Google’s policies.”
> >
> > They are on the basic G-suite plan which doesn't allow for specific
> > support from Gmail.
> >
> > Has anyone experienced this before or have any insights on this issue?
> >
> > Best Regards,
> > Nathan
> >
> > --
> > *Nathan She*, Manager, Deliverability Strategy, Inbox Pros, a Trendline
> > Company
> > *O* +1 (470) 369-6713  | *C* +1 (470) 494-1800
> > 
> >
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> >
>
>
>
> --
> "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
>


-- 

Brian Toresdahl

Product Management

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

Re: [mailop] Does anyone have experience with Gmail lockouts?

[Michael Peddemors via mailop]

Gmail finally locking down on spamming from Gsuite?
Will wonders never cease...

;)

(Hey, actually the spam folder DOES seem to have less the last few days)

On 2020-07-09 2:57 p.m., Nathan She via mailop wrote:

Hey everyone,

A client of ours is seeing their sales reps and account managers locked 
out of their G-suite accounts. Upon trying to log in, they get the 
message “It looks like this account was used in a way that violated 
Google’s policies.”


They are on the basic G-suite plan which doesn't allow for specific 
support from Gmail.


Has anyone experienced this before or have any insights on this issue?

Best Regards,
Nathan

--
*Nathan She*, Manager, Deliverability Strategy, Inbox Pros, a Trendline 
Company
*O* +1 (470) 369-6713  | *C* +1 (470) 494-1800 



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





--
"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

[mailop] Does anyone have experience with Gmail lockouts?

[Nathan She via mailop]

Hey everyone,

A client of ours is seeing their sales reps and account managers locked out
of their G-suite accounts. Upon trying to log in, they get the message “It
looks like this account was used in a way that violated Google’s policies.”

They are on the basic G-suite plan which doesn't allow for specific support
from Gmail.

Has anyone experienced this before or have any insights on this issue?

Best Regards,
Nathan

-- 
*Nathan She*, Manager, Deliverability Strategy, Inbox Pros, a Trendline
Company
*O* +1 (470) 369-6713 <+14703696713> | *C* +1 (470) 494-1800 <+14704941800>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Intermittent slow email delivery

[Job Cacka via mailop]

For the last several weeks I have been tracking slow email from several
sources. When it is easiest to see is when an outside source will send an
email to two or more of our employees at the same time. One email copy to
one person will show up right away and the other might be several hours
later. Often we have had one employee reply all to the message and the
other employee will notice they didn’t get that part of the email thread as
the Reply All is received before the original.

Looking at the logs on our end show nothing. No attempt for that message at
the time it was originally sent. Investigating email headers when it
finally arrives reveals the message’s path and it sat for a long time at
the senders’ last email server in the list. These servers usually are some
third party relay and have included google.com, outlook.com, iphmx.com,
cudaops.com, mimecast.com and probably more that I haven’t found yet.

If you work with one of these relays and can shed light on the delay I
would love to know how to get it fixed.

If you have examples of this you have been tracking in the last month and a
half or so I would like to hear about what you have discovered. I have
asked several of the other sending organizations for email logs and error
messages but have not had any usable response.

I did look at the possibility of incoming greylisting. Our Barracuda does
not support it and it is not enabled. Also, if this was the issue the
Barracuda should make some log entry that the email was delayed. We created
a support ticket with Barracuda and came up with no log entries prior to
when it was received. It was like it sat in a queue for many hours. I also
took the time to ensure these senders were in our whitelist and that did
not help either.

Because it is intermittent and eventually arrives I think I can rule out
most routing issues and I did double check DNS but see no changes there.


Yesterday:

One of our customers sent us an email asking us to cancel a delivery about
8am yesterday. We received the email 19 hours later and they got the
product they didn't need about 3 hours after the email left the client's
system.
The customer uses Gmail to provide backend email services.
See attached screenshot of header analysis.

Thanks in advance,

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

Re: [mailop] Report as spam and mail forwarders: best practices?

[Brandon Long via mailop]

On Tue, Jul 7, 2020 at 9:55 PM Grant Taylor via mailop 
wrote:

> On 7/7/20 5:07 PM, Brandon Long via mailop wrote:
> > At least at Gmail, we usually recommend that you don't use SRS,
> > that you leave the original envelope from intact.
> >
> > https://support.google.com/mail/answer/175365?hl=en
>
> I have always questioned the veracity of that recommendation.
>
> > This helps us to know the email was forwarded and limits the bad
> > reputation effects of forwarding spam.
>
> I believe that Google is quite capable and that they could undo SRS
> rewriting to deduce the original SMTP envelope recipient.
>

SRS isn't a thing, though.  It was a one-off proposal, it's not a
standard.  In terms of
VERPs in use on the internet, it's not even that popular compared to the
proprietary ones
used by large providers.

With SRS you're saying you want the mail to auth as you but not be from
you?  What are
you asking?

There may be an opportunity to abuse this, but I suspect some relatively
> simple tests could reduce the risk.  Namely, do an MX and SPF lookup on
> the unrewritten recipient, and then see if the source makes sense.
>

There's no authentication there for the original address, we won't do
anything
with it.  Even if we trusted the forwarder to honestly rewrite, there's no
indication
the original was authenticated.  That's the point of ARC, for the relay to
tell us
what the original auth was and separately determine whether we should
believe them.

> but if you're having spam reputation issues from your forwarding,
> > then perhaps that's the wrong choice.  And maybe the right answer
> > also depends on where you're forwarding to.
> >
> > One would also hope that in the future using ARC would be an even
> > better way to denote forwarding, but we're a ways from that being a
> > solution right now.  In my perfect world, mailbox providers like Gmail
> > would allow end users to specify forwarding information similar to
> > what we have for "inbound relays" for GSuite, but the feature never
> > made it above the line for implementation.
>
> I question if we will ever get to a point that ARC will be viable for
> small / individual server operators.  :-(
>

I mean, right now there's probably a floor for volume for DKIM/SPF
reputation
for us, so yes, ARC will likely suffer from the same issue.   Any level
would work
 for whitelisting on a per receiver basis, of course.  If you only send a
couple
messages a day, there's just no statistical signal.

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

Re: [mailop] [EXTERNAL] Re: Post-processing Journal-Mails coming from O365, forwardedMail

[Michael Wise via mailop]

Journal-Mails ...

Look for the X-Forefront-Antispam-Report header.

If it's NOT present, or does not have the tokens of SFV:SPM or SFV:NSPM, you've 
configured it wrong.



Just something I've heard.

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



-Original Message-
From: mailop  On Behalf Of Jaroslaw Rafa via mailop
Sent: Thursday, July 9, 2020 2:26 AM
To: mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] Post-processing Journal-Mails coming from 
O365, forwardedMail



Dnia  9.07.2020 o godz. 11:22:21 Jaroslaw Rafa pisze:

> Dnia  9.07.2020 o godz. 05:36:41 Stefan Bauer via mailop pisze:

> >

> > Are there any tools available to just have the attachment that is

> > the real and original mail?

>

> Try looking at "munpack":

> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinu

> x.die.net%2Fman%2F1%2Fmunpackdata=02%7C01%7Cmichael.wise%40micros

> oft.com%7C4900a46c56184a66097d08d823ea9eb5%7C72f988bf86f141af91ab2d7cd

> 011db47%7C0%7C0%7C637298837886048501sdata=WEkEZ9AMZSRb5RCmRVXEpL0

> Gyh9q1x4GgG3FoK70UG0%3Dreserved=0

> or "mu extract":

> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmanpa

> ges.ubuntu.com%2Fmanpages%2Ffocal%2Fman1%2Fmu-extract.1.htmldata=

> 02%7C01%7Cmichael.wise%40microsoft.com%7C4900a46c56184a66097d08d823ea9

> eb5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637298837886048501

> p;sdata=2%2BHnBmyAMCH3PspoYOcQ0mr1IK%2F%2FCcVgkxBpaYf1JsE%3Dreser

> ved=0



There's even more...

ripmime: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinux.die.net%2Fman%2F1%2Fripmimedata=02%7C01%7Cmichael.wise%40microsoft.com%7C4900a46c56184a66097d08d823ea9eb5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637298837886048501sdata=rUM2BoKV5zz5gZNHzAeUKQSth9JfkI7GwQBqN7d%2BuO4%3Dreserved=0

metamail: 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.netadmintools.com%2Fhtml%2F1metamail.man.htmldata=02%7C01%7Cmichael.wise%40microsoft.com%7C4900a46c56184a66097d08d823ea9eb5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637298837886048501sdata=ZSvKFXtmxI0LORHIEap38rYzikZNBBbnWeMVXSg%2BNg4%3Dreserved=0



You can try which one suits you best.

--

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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7C4900a46c56184a66097d08d823ea9eb5%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637298837886048501sdata=MOGYS1Y8miZPgPhIxNtHrdBYij6D2qTVZOlSr3I70OM%3Dreserved=0
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Post-processing Journal-Mails coming from O365, forwardedMail

[Jaroslaw Rafa via mailop]

Dnia  9.07.2020 o godz. 11:22:21 Jaroslaw Rafa pisze:
> Dnia  9.07.2020 o godz. 05:36:41 Stefan Bauer via mailop pisze:
> > 
> > Are there any tools available to just have the attachment that is the real
> > and original mail?
> 
> Try looking at "munpack": https://linux.die.net/man/1/munpack
> or "mu extract":
> http://manpages.ubuntu.com/manpages/focal/man1/mu-extract.1.html

There's even more...
ripmime: https://linux.die.net/man/1/ripmime
metamail: https://www.netadmintools.com/html/1metamail.man.html

You can try which one suits you best.
-- 
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] Post-processing Journal-Mails coming from O365, forwardedMail

[Jaroslaw Rafa via mailop]

Dnia  9.07.2020 o godz. 05:36:41 Stefan Bauer via mailop pisze:
> 
> Are there any tools available to just have the attachment that is the real
> and original mail?

Try looking at "munpack": https://linux.die.net/man/1/munpack
or "mu extract":
http://manpages.ubuntu.com/manpages/focal/man1/mu-extract.1.html
-- 
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] Digital Ocean Broken Bot attack, just in case it's you and not me..

[Benoit Panizzon via mailop]

> >Range,  192.241.227.0/24  
> 
> One connect each on Thu, Sat, Sun, and Mon.  Did EHLO after banner, then
> closed the connection.  

116 connections between 27. June and 1. July to my spamtrap / honeypot,
mostly sending "EHLO zg-0626-127" and then disconnecting.

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

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