Re: [mailop] Microsoft Block list (S3150)

[M. Omer GOLGELI via mailop]

JMRP is not dead.I recently received an email for an IP block that 2 years ago we announced under our ASN for a client and it was never submitted to JRMP or SNDS... So at least I know it's alive. Also I have seen many datacenters complaining about Microsoft blocking their whole ASN with hundreds of prefixes without giving any reason as well. So they recently retaliated...Whatever the reason is, or whether one is MS customer or not, this is yet another example of Microsoft quality jobs for perfecting things for themselves with petty excuses while breaking it for the whole world. On Jul 2, 2020 6:36 AM, Ted Hatfield via mailop  wrote:



On Wed, 1 Jul 2020, Warren Volz via mailop wrote:



> 

> On 06/30/2020 8:10 am, Adam Moffett via mailop wrote:

>

>   JMRP may not be dead, but I have haven't received anything from it in at least 8 months.  That's just as far

>   back as my "abuse" inbox goes. I don't actually know when we last received something from JMRP.  I believe you

>   that it still works for you, but apparently it doesn't work for some of us.  I used to get them fairly

>   routinely when people sent out their soccer club announcements and church newsletters and such (I presume

>   someone felt it easier to click the "report as spam" button than to unsubscribe from the church newsletter).

>    I'm sure those folk are still sending their newsletters, and I know we still sometimes have a problem with a

>   breached email account, but I don't get the JMRP messages anymore.

>

>   Meanwhile I'm still getting the S3150.  As of today it's been 8 days.  The response to my support ticket was

>   that our IP address was not eligible for mitigation.and I'm not even sure what that means.  I reviewed

>   logs and account statistics over this time period and I'm confident there's been no further spamming activity.

>    The last trouble was the one user on 6/22 who got phished and sent up to his daily limit of 200 messages.

>

>   I'd like to remain patient, but I'm starting to feel that this response is disproportionate to the original

>   issue.

> 

> Adam,

> 

> I just want to say that I feel your pain. We had a hacked account send >1k in messages to the MSFT infrastructure before

> it was disabled. As of now, I'm going back and forth with the support team to try and get our server removed from the

> block list.

> 

> -Warren

> 

> 

>



We had the same thing happen as well.  I had to route a number of hotmail 

and affilliated domains out via a seperate server until the block was 

eventually removed.



What made the whole process so frustrating was the lack of communication 

with MSFT.  No idea when the block would be removed, no actual data from 

them showing the problem, just we can't help you and please go away now.



A lot of small providers are doing their level best to be good netizens by 

implenting new email protocols, setting up tools to process dmarc and 

feedback loops, implementing dkim, spf, and dmarc for not just their 

domain but for all of their customer domains.  If you don't get it 

completely correct and keep it that way they could give a fat finger to 

assist you.  They send your email to junk because your not large enough to 

matter and finding someone to assist you usually has to be done via the 

mailop or nanog list because their front line tech support isn't geared to 

help you.



It is just so frustrating!



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

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

Re: [mailop] Is there a contact for ono.com

[John Levine via mailop]

In article <20200715210750.gh14...@dm7.infinitemho.fi> you write:
>> Does anyone know a contact there I can reach out to? Or has anyone had
>> success sending to that domain?

I can connect to it from my server in NY but not my home ISP that uses more or 
less the same routing.

After I connect to it, after a very long wait I see no greeting.

I believe the technical term for this state is "broken".

-- 
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] Is there a contact for ono.com

[Carl Byington via mailop]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, 2020-07-16 at 00:07 +0300, Atro Tossavainen via mailop wrote:
> Since https://www.ono.com/ is equally unaccessible from my domestic
> Internet connection (also in Finland), I'd say #1 sounds more likely
> to me.

I can ping www.ono.com == 62.42.230.18, but traceroute to it dies after
de-cix.mad.vodafone.es and four 10/8 addresses. So it does not look like
routing to me.

But 62.42.230.18 won't answer on port 80, and 62.42.230.22 won't answer
on port 25.


-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCXw+xfBUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsFztQCfWswYVuQ+SxQ9DjnD3SKm/gVmsgIA
n0tPxf1Hoz3jrHZ5Fm0d65GvvnLD
=tXbk
-END PGP SIGNATURE-



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

Re: [mailop] Is there a contact for ono.com

[Luis E. Muñoz via mailop]

On 15 Jul 2020, at 14:07, Atro Tossavainen via mailop wrote:

> 2) Deliberate DROP-style firewalling of your ranges and mine too
>
> Since https://www.ono.com/ is equally unaccessible from my domestic
> Internet connection (also in Finland), I'd say #1 sounds more likely
> to me.

Add my nodes in New York, Amsterdam, Oregon and London to the blacklist.

Best regards

-lem

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

Re: [mailop] harassment/death threat detection/filtering/prosecution

[Brandon Long via mailop]

Google has attempted to make a comment moderation engine using ML,
available at
https://www.perspectiveapi.com/#/home

I don't know how well it works at the moment, it's typically been a very
hard thing to do, since
the amount of "data" in a comment tends to be small, and there is a lot of
jargon and
such in terms of context that can make different usage very complicated.

My searches to remember that came up with some other alternatives in the
same sort
of space.

As for "preferring to see them", that makes more sense when you receive very
few of them.  It's more complicated if your every post on say twitter
generates dozens
to hundreds of them.  Most of them at that point are not "real", just
offensive, and
it seems unlikely that even humans would be able to tell the difference or
deal with
them at scale.  One could imagine an automated system that collects the
information
in each and tries to group them by likely perps, using a scoring system
over time to
highlight the worse offenders.  In a shared system, that could go even
farther.

In David Brin's _Earth_, one of the protagonists had an aside where they
described
a system that would scan their large email inbox and create a sentiment
report highlighting
with examples.  I'm sure there are various systems like that probably tuned
for brands
and such on social media, and maybe even some for support desks.  This use
case
is kind of a special case of that.

Another alternative for such a system of detection is to have other people
help
go through the detritus for them, to relieve some of the dread that must
come with
constantly being bombarded with the cesspool.

Anyways, I don't doubt that such crap isn't limited to social media, and
that
some makes its way to email... but I don't think there's been much work on
it
at that level.

Brandon

On Wed, Jul 15, 2020 at 2:15 PM Chris via mailop  wrote:

> On 2020-07-15 16:09, Jaroslaw Rafa via mailop wrote:
> > Dnia 15.07.2020 o godz. 12:59:39 Grant Taylor via mailop pisze:
> >> On 7/12/20 11:28 AM, Paul Ebersman via mailop wrote:
> >>> But in these tense times, lots of PoC/non-white/non-cis get hate
> >>> emails, death threats, etc.
>
> >> Death threats seem like the warrant more effort to stop than spam.
>
> > If someone would send death threats to me, I'd rather would like to
> receive
> > them, so that I can know whether I'm actually in danger and optionally
> > report to the police or whatever...
> >
>
> Which is what I was about to say too.  In fact, by being really good at
> blocking harrassment/death threats, you become partly liable if
> something does happen.  Because you hid the threat from the victim, and
> potentially increased their risk of harm from something they didn't know
> about.
>
> I had to deal with some of these in a large corporate environment.  Each
> time our "reaction" to the threatening (or sometimes just crackpot)
> emails was carefully considered between me (filter options) and
> Corporate Security before deployment.  Eg:
>
> - Do we reject/bounce, or silently ignore?  Usually the latter.
> - Do we forward captures to CorpSec, not the user?
> - Law enforcement?  Legal C?
>
> Etc.
>
> These also have to be carefully differentiated from some of the
> wide-spread stuff like the "I have a contract on you, pay me, and I
> won't kill you" extortion soan/scams.  Those should just be nuked.
>
> I would generally not recommend  filtering on "threatening content"
> per-se, but on spam, however you usually do it - like DNSBLs or
> spamassassin or whatever...  Then make it a point of user education to
> tell people what to do if they get threatening email that gets past the
> general spam filtering.  Which may be LE, may be your own corporate, may
> be custom filtering, etc.  This approach will generally tend to weed out
> the normal broadcast bullshit, and leave behind the stuff the victim/you
> really need to know about.
>
> ___
> 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] harassment/death threat detection/filtering/prosecution

[Chris via mailop]

On 2020-07-15 16:09, Jaroslaw Rafa via mailop wrote:

Dnia 15.07.2020 o godz. 12:59:39 Grant Taylor via mailop pisze:

On 7/12/20 11:28 AM, Paul Ebersman via mailop wrote:

But in these tense times, lots of PoC/non-white/non-cis get hate
emails, death threats, etc.



Death threats seem like the warrant more effort to stop than spam.



If someone would send death threats to me, I'd rather would like to receive
them, so that I can know whether I'm actually in danger and optionally
report to the police or whatever...



Which is what I was about to say too.  In fact, by being really good at 
blocking harrassment/death threats, you become partly liable if 
something does happen.  Because you hid the threat from the victim, and 
potentially increased their risk of harm from something they didn't know 
about.


I had to deal with some of these in a large corporate environment.  Each 
time our "reaction" to the threatening (or sometimes just crackpot) 
emails was carefully considered between me (filter options) and 
Corporate Security before deployment.  Eg:


- Do we reject/bounce, or silently ignore?  Usually the latter.
- Do we forward captures to CorpSec, not the user?
- Law enforcement?  Legal C?

Etc.

These also have to be carefully differentiated from some of the 
wide-spread stuff like the "I have a contract on you, pay me, and I 
won't kill you" extortion soan/scams.  Those should just be nuked.


I would generally not recommend  filtering on "threatening content" 
per-se, but on spam, however you usually do it - like DNSBLs or 
spamassassin or whatever...  Then make it a point of user education to 
tell people what to do if they get threatening email that gets past the 
general spam filtering.  Which may be LE, may be your own corporate, may 
be custom filtering, etc.  This approach will generally tend to weed out 
the normal broadcast bullshit, and leave behind the stuff the victim/you 
really need to know about.


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

Re: [mailop] Is there a contact for ono.com

[Atro Tossavainen via mailop]

On Wed, Jul 15, 2020 at 04:49:49PM -0400, Oreva Akpolo via mailop wrote:
> We've been experiencing connection issues sending to ono.com. Specifically,
> all mails to that domain are deferring with the following response:
> 
> connect to mx.ono.com[62.42.230.22]:25: Connection timed out

Hey Oreva,

I made a small very unscientific test.

I can't connect to it from my shell box in Finland.

I can't connect to it from another shell box in another EU country.

I have access to a little VPS somewhere in America that has no problem
connecting to it, just right now, however.

> Does anyone know a contact there I can reach out to? Or has anyone had
> success sending to that domain?

It sounds like one of two things to me.

1) A routing problem.

2) Deliberate DROP-style firewalling of your ranges and mine too

Since https://www.ono.com/ is equally unaccessible from my domestic
Internet connection (also in Finland), I'd say #1 sounds more likely
to me.

-- 
Atro Tossavainen, Chairman of the Board
Infinite Mho Oy, Helsinki, Finland
tel. +358-44-5000 600, http://www.infinitemho.fi/

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

[mailop] Is there a contact for ono.com

[Oreva Akpolo via mailop]

We've been experiencing connection issues sending to ono.com. Specifically,
all mails to that domain are deferring with the following response:

connect to mx.ono.com[62.42.230.22]:25: Connection timed out

Does anyone know a contact there I can reach out to? Or has anyone had
success sending to that domain?

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

Re: [mailop] harassment/death threat detection/filtering/prosecution

[Jaroslaw Rafa via mailop]

Dnia 15.07.2020 o godz. 12:59:39 Grant Taylor via mailop pisze:
> On 7/12/20 11:28 AM, Paul Ebersman via mailop wrote:
> >But in these tense times, lots of PoC/non-white/non-cis get hate
> >emails, death threats, etc.
> 
> Death threats seem like the warrant more effort to stop than spam.

If someone would send death threats to me, I'd rather would like to receive
them, so that I can know whether I'm actually in danger and optionally
report to the police or whatever...
-- 
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] harassment/death threat detection/filtering/prosecution

[Grant Taylor via mailop]

On 7/12/20 11:28 AM, Paul Ebersman via mailop wrote:
But in these tense times, lots of PoC/non-white/non-cis get hate 
emails, death threats, etc.


Death threats seem like the warrant more effort to stop than spam.

Is there software out there like spamassassin et al for detecting these 
kinds of threats? Does anyone have pointers on web pages/instructions 
for how to configure common mail readers/services so users can 
self-filter?


I would think that it should be possible to re-use the typical tools but 
to have them look for different words / phrases.


Custom SpamAssassin rules come to mind.

Finally, I know that there are avenues for tracking illegal activity 
and ways to work with FBI, Interpol, etc. Any of these teams specialize 
in or at least familiar with how to prosecute hate crimes perpetrated 
via email threats?


I have no idea how to go about doing this.  But I would encourage 
exactly this.


Perhaps an official police report in your jurisdiction and / or the 
jurisdiction of the business entity that sent the message to you / your 
customer, followed up by a (canned) cease and desist letter from an 
attorney.


It's probably a loosing battle.  But I feel like hate based threats are 
a windmill that's worth tilting at.


Dare I say it, perhaps it's time for a new Real-time Block List of 
sources of threats / hate, be it IP and / or domain name and / or content.




--
Grant. . . .
unix || die



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

Re: [mailop] Rolling DKIM Key Disclosure

[Brandon Long via mailop]

On Wed, Jul 15, 2020 at 11:31 AM John Levine via mailop 
wrote:

> In article <021c736c-4194-4339-9d22-72f7b0707...@as397444.net> you write:
> >Ah, I didn’t know l= existed, thanks for that! Do most hosts treat l=0 as
> DKIM-valid the same way as l=, or are they likely to
> >ignore the DKIM signatures?
>
> It varies buy my impression is that there isn't a lot of mail with l=0
> signatures that the recipients actively want to receive.
>

I'd say since most people don't send mail with that, most spam filters are
ignorant of the distinction as of yet.  If any large enough domain
started doing that, or especially if multiple of them did, then the
spammers would find them and re-use the headers for a DKIM replay-like
attack.
If that attack was successful, then spam filters would be changed to likely
discount the l=0 signatures in much the same way that they discount 512
bit dkim keys or overly wide SPF records.  It's possible the existing rules
dealing with the replay attacks would be successful against these attacks,
in which case nothing will change... or will only at some providers,
depending on how well they survived.

Which is to say, you can get away with things up to a point, but hacks are
hacks and can fail at inopportune times.

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

Re: [mailop] DKIM ECC, Rolling DKIM Key Disclosure

[Phil Pennock via mailop]

On 2020-07-15 at 11:54 -0400, John Levine wrote:
> In article <20200713214707.ga26...@fullerene.field.pennock-tech.net> you 
> write:
> >Exim has implemented a=ed25519-sha256 for some time, and verifies it.
> >By mail volume that's not a lot, but by independent installs it counts a
> >bit more.  Support was added in Exim 4.91, released in April 2018 and
> >does require a modern GnuTLS or OpenSSL.  That last requirement cuts
> >back the percentage of sites which might be able to verify.  :-D
> 
> Do you know what DKIM library it uses? I use the popular opendkim
> which unfortunately hasn't been updated in 2015.

With my @exim.org hat on (so, er, "yes"): originally pdkim but the code
was done as an import (contributed by the PDKIM author) and has been
independently developed, so the Ed25519 support is AFAIK Exim-only.

pdkim/README:
-8< cut here >8-
PDKIM - a RFC4871 (DKIM) implementation
http://duncanthrax.net/pdkim/
Copyright (C) 2009  Tom Kistner 

No longer includes code from the PolarSSL project.
Copyright (C) 2016 Jeremy Harris 

This copy of PDKIM is included with Exim. For a standalone distribution,
visit http://duncanthrax.net/pdkim/.
-8< cut here >8-

The Ed25519 support was written by Jeremy Harris, both the OpenSSL and
GnuTLS implementations.  PDKIM uses PolarSSL.

Both pdkim and Exim are GPLv2+.

That README should probably get an updated year range since Jeremy's put
a lot of work into it.

-Phil

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

Re: [mailop] Rolling DKIM Key Disclosure

[John Levine via mailop]

In article <021c736c-4194-4339-9d22-72f7b0707...@as397444.net> you write:
>Ah, I didn’t know l= existed, thanks for that! Do most hosts treat l=0 as 
>DKIM-valid the same way as l=, or are they likely to
>ignore the DKIM signatures?

It varies buy my impression is that there isn't a lot of mail with l=0
signatures that the recipients actively want to receive.

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

[Job Cacka via mailop]

Well, it is good to know the cause of the problem.

The reposting wasn't random. I am new to the list and had difficulty
sending my first few emails, so I thought I had done something wrong again
the first two times. When those two hadn't processed but others were
hitting the archive my initial assumption was it was from my end and
actually spent 45 minutes looking through my sent items in gmail. That was
when I began wondering if there was a problem with gmail.

Incidentally, the last was also sent to mailop-ow...@mailop.org because
that was what was listed on the web page. For future reference who is on
the admin team?

Thanks,
 Job

On Wed, Jul 15, 2020 at 8:14 AM Graeme Fowler via mailop 
wrote:

> [admin hat on]
>
> On 15 Jul 2020, at 15:55, Job Cacka via mailop  wrote:
> > Sorry for spamming the list guys.
> > Take a look at the header information.
> > The four copies were sent over a couple of days and you got them when?
> >
> > Mon Jul 13 16:58:47 BST 2020
> > Mon Jul 13 19:08:50 BST 2020
> > Mon Jul 13 23:36:35 BST 2020
> > Tue Jul 14 19:02:47 BST 2020
> >
> > If you only received them on Wednesday then why?
> >
> > I sent these to the list using a gmail account. I believe gmail has an
> intermittent  issue.
>
> The mailop list server had an issue which was resolved this morning.
>
> Instead of randomly reposting in the hope you can force one through, if
> messages aren't appearing then maybe you should try contacting the admin
> team - like someone else did, so the issue was fixed.
>
> As was never actually uttered in the Star Wars canon: "patience, young
> padawan"...
>
> Graeme
> ___
> 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] Rolling DKIM Key Disclosure

[Matt Corallo via mailop]

Ah, I didn’t know l= existed, thanks for that! Do most hosts treat l=0 as 
DKIM-valid the same way as l=, or are they likely to ignore the DKIM signatures?

Matt

> On Jul 15, 2020, at 07:20, Ángel via mailop  wrote:
> 
> On 2020-07-11 at 15:27 -0400, Matt Corallo via mailop wrote:
>> "Sorry, I think what you're looking for isnt useful, you're misinformed" 
>> isn't exactly a useful response when someone,
>> especially a customer, asks for something, sadly.
> 
> 
> Your customer should detail their threat model, so that they can be
> given a solution suited to their needs. You don't implement the same
> solution to "protect your files" if your threat is the cat walking over
> the keyboard or spies from a foreign country.
> 
> 
> I would suggest DKIM-signing the headers but not the email body (i.e.
> use l=0), perhaps not even including the Subject.
> 
> This, way your customer could send an email saying:
>> We have agreed that it's dangerous to the Don and our Family to let
>> Sollozzo live. Will you help us to kill him?
> 
> and then argue that the email really said:
>> We are very worried about a possible confrontation and only want the
>> peace between all parties.
> 
> 
> the origin and recipients of the email will appear on many email logs,
> so it'd probably be pointless to hide them. You could go as far as to
> only sign the Message-Id if you wanted, though.
> 
> 
> Anyway, it's likely than 5 minutes after that, the other party replied
> saying "We won't interfere with that" and quoting your full email.
> DKIM-signed by Office 365.
> 
> 
> Regards
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

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

Re: [mailop] Intermittent slow email delivery

[Graeme Fowler via mailop]

[admin hat on]

On 15 Jul 2020, at 15:55, Job Cacka via mailop  wrote:
> Sorry for spamming the list guys.
> Take a look at the header information. 
> The four copies were sent over a couple of days and you got them when? 
> 
> Mon Jul 13 16:58:47 BST 2020 
> Mon Jul 13 19:08:50 BST 2020 
> Mon Jul 13 23:36:35 BST 2020 
> Tue Jul 14 19:02:47 BST 2020
> 
> If you only received them on Wednesday then why?
> 
> I sent these to the list using a gmail account. I believe gmail has an 
> intermittent  issue. 

The mailop list server had an issue which was resolved this morning.

Instead of randomly reposting in the hope you can force one through, if 
messages aren't appearing then maybe you should try contacting the admin team - 
like someone else did, so the issue was fixed.

As was never actually uttered in the Star Wars canon: "patience, young 
padawan"...

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

Re: [mailop] Intermittent slow email delivery

[Job Cacka via mailop]

Sorry for spamming the list guys.
Take a look at the header information.
The four copies were sent over a couple of days and you got them when?

*Mon Jul 13 16:58:47 BST 2020*
*Mon Jul 13 19:08:50 BST 2020*
*Mon Jul 13 23:36:35 BST 2020*
*Tue Jul 14 19:02:47 BST 2020*

If you only received them on Wednesday then why?

I sent these to the list using a gmail account. I believe gmail has an
intermittent  issue.

Thanks,
 Job


On Wed, Jul 15, 2020 at 3:13 AM Laura Atkins 
wrote:

> Hi, Job,
>
> I’ve seen 4 copies of this message this morning. Things are working here.
>
> laura
>
>
>
> On 13 Jul 2020, at 23:36, Job Cacka via mailop  wrote:
>
>
> I am re-submitting thr because it doesn't seem to be showing in the
> newsgroup.
>
> So I spoke a bit too soon on the firewall.This morning I had time to look
> at it from a physical and configuration sense.  It is a pfSense firewall
> that has multiple WAN ports enabled for multiple ISP. The path from the WAN
> that contains the MX IPs does not load balance or failover to the other WAN
> port. At one time this was setup but was turned off for some reason.
>
> So NAT/PAT points it to the barracuda. Which in turn passes it to the
> proper email server based upon domain or IP address.
>
> To avoid outbound sending confusion from multiple gateways there is an
> Outbound NAT but that shouldn't affect the incoming email as those
> connections are from a different source.
>
> In light of this configuration would it still make sense to have multiple
> MX records? One for each WAN/ISP?
>
> I am considering trying to capture and inspect port 25 as it crosses from
> the firewall to the barracuda to see if that will shed light on the
> situation.
>
> Thanks,
>  Job
>
>
> On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus  wrote:
>
>> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop 
>> wrote:
>> >
>> > There is PAT firewall that load balances multiple networks.
>>
>> Maybe one of those destination networks is unreachable, while others
>> are reachable, so when the load-balancing decision points to the
>> unreachable network, the TCP session will not establish? Have you
>> verified connectivity of each and every backend server from your
>> load-balancers perspective?
>>
>> Using multiple MX records, one for each destination mailserver would
>> be the better setup, as opposed to load-balancing incoming port 25
>> traffic (probably without appropriate health-checking and logging) of
>> a single MX record.
>>
>>
>> cheers,
>> lukas
>>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] MailGun, having a breakout..

[Michael Peddemors via mailop]

This mornings reports show that while the SendGrid problem is still 
ongoing, seems like MailGun is starting to see abuse problems as well.


Interestingly, we also see that they have decided to start using some 
Amazon IP space for this as well, unfortunate that they don't have an 
SWIP for those IP(s), harder to see if someone is just forging their 
names..


100.26.68.15 54   guardpost-n06.use1.mailgun.co

The following IP(s) had a high number of reporting ISP(s) detect abusive 
behavior...


18.211.55.180 51   guardpost-n04.use1.mailgun.co
18.211.62.95  50   guardpost-n12.use1.mailgun.co
34.213.218.18331   guardpost-n04.usw2.mailgun.co
35.163.207.19126   guardpost-n12.usw2.mailgun.co
35.164.102.25 31   guardpost-n11.usw2.mailgun.co
35.166.73.8   26   guardpost-n10.usw2.mailgun.co
50.112.75.112 30   guardpost-n07.usw2.mailgun.co
52.13.166.19  27   guardpost-n06.usw2.mailgun.co
52.22.203.228 47   guardpost-n05.use1.mailgun.co
54.189.218.55 33   guardpost-n05.usw2.mailgun.co
54.197.154.120 6   guardpost-n11.use1.mailgun.co
54.200.7.151  31   guardpost-n08.usw2.mailgun.co
54.244.205.25330   guardpost-n09.usw2.mailgun.co
100.26.68.15  54   guardpost-n06.use1.mailgun.co

--
"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] Rolling DKIM Key Disclosure

[Ángel via mailop]

On 2020-07-11 at 15:27 -0400, Matt Corallo via mailop wrote:
> "Sorry, I think what you're looking for isnt useful, you're misinformed" 
> isn't exactly a useful response when someone,
> especially a customer, asks for something, sadly.


Your customer should detail their threat model, so that they can be
given a solution suited to their needs. You don't implement the same
solution to "protect your files" if your threat is the cat walking over
the keyboard or spies from a foreign country.


I would suggest DKIM-signing the headers but not the email body (i.e.
use l=0), perhaps not even including the Subject.

This, way your customer could send an email saying:
> We have agreed that it's dangerous to the Don and our Family to let
> Sollozzo live. Will you help us to kill him?

and then argue that the email really said:
> We are very worried about a possible confrontation and only want the
> peace between all parties.


the origin and recipients of the email will appear on many email logs,
so it'd probably be pointless to hide them. You could go as far as to
only sign the Message-Id if you wanted, though.


Anyway, it's likely than 5 minutes after that, the other party replied
saying "We won't interfere with that" and quoting your full email.
DKIM-signed by Office 365.


Regards



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

[mailop] Palo Alto Network

[Chris Truitt via mailop]

Does any one have a contact with Palo Alto Network?
I need to escalate an inquiry.

Thank you,

Chris Truitt

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

Re: [mailop] Intermittent slow email delivery

[Jaroslaw Rafa via mailop]

Dnia 14.07.2020 o godz. 11:02:47 Job Cacka via mailop pisze:
> Perhaps this original message is still stuck in some queue? I wrote it
> yesterday and it never made it through to the list. At least it isn't in
> the archive so try again.

I got all (is that all?) four copies you sent.
-- 
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] harassment/death threat detection/filtering/prosecution

[Laura Atkins via mailop]

It’s both a tricky and a ongoing problem. Many of the folks doing the harassing 
have access to a host of tools that make it difficult, if not impossible, to 
block them. Blocking by content is fraught with false positives and often the 
targets are activists who have legitimate reasons to be discussing hate mail 
and sensitive topics. Much like some anti-spam lists have discovered filters 
will often block discussions of spam samples. 

I think it’s a valuable topic to discuss. One thing I would suggest is reaching 
out to the groups who are actively working in the anti-harassment space. They 
probably have been through many of the early iterations of “how do we protect 
people who come to us for help.” While I don’t have a lot of experience here, 
the first person I’d talk to is Jayne Hitchcock and then chase down the places 
she recommended. There are also a number of women’s groups who work directly 
with victims of harassment, that have visible contact information. I’m less 
familiar with the anti-racist and anti-anti-semitic groups but I know they have 
presences online, too. Even a few 30 minute phone calls will give you a crash 
course in what they’ve already tried and help create a much better policy. 

laura 

> On 15 Jul 2020, at 10:38, Hans-Martin Mosner via mailop  
> wrote:
> 
> This is a tricky problem. I would guess that some traditional spam-rejection 
> mechanisms might be applicable, but there are grey areas:
> Rejection of mails from anonymous origins may help, but on one hand there are 
> some (sent via hacked ordinary mailboxes) which can't technically be 
> distinguished from non-anonymous communication, and on the other hand people 
> who are under threat of harassment might want to use anonymizing services 
> themselves to communicate.
> Content filtering requires training samples, and there is probably not enough 
> data to train a Bayesian filter as in SpamAssassin or more modern sentiment 
> analysis neural networks. The false positive and false negative rates might 
> be unacceptably high, requiring manual checks.
> In addition, these tools are not helping in identifying perpetrators. I would 
> suspect that they will in most cases use techniques which make them 
> untraceable. Given that trust in LEAs is damaged after the many racist police 
> incidents in the USA or the recent hatemail incidents based on information 
> retrieved through police computer systems in Germany, I would also suspect 
> that some victims would be reluctant to hope that police authorities will 
> track down perpetrators.
> 
> Some groups on both ends of the political spectrum therefore prefer to track 
> down and attack peeceived "enemies" themselves. This is obviously not a 
> solution, even when it's well-intentioned.
> 
> Cheers,
> Hans-Martin
> 
> Am 15. Juli 2020 10:40:05 vorm. schrieb Paul Ebersman via mailop 
> :
> 
>> We have all sorts of tools for detecting, filtering, documenting spam
>> and processes for trying to get spammers off the net (and occasionally
>> even prosecuted).
>> 
>> But in these tense times, lots of PoC/non-white/non-cis get hate emails,
>> death threats, etc.
>> 
>> Is there software out there like spamassassin et al for detecting these
>> kinds of threats? Does anyone have pointers on web pages/instructions
>> for how to configure common mail readers/services so users can
>> self-filter?
>> 
>> Finally, I know that there are avenues for tracking illegal activity and
>> ways to work with FBI, Interpol, etc. Any of these teams specialize in
>> or at least familiar with how to prosecute hate crimes perpetrated via
>> email threats?
>> 
>> 
>> ___
>> 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

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [mailop] Intermittent slow email delivery

[Laura Atkins via mailop]

Hi, Job,

I’ve seen 4 copies of this message this morning. Things are working here.

laura 



> On 13 Jul 2020, at 23:36, Job Cacka via mailop  wrote:
> 
> 
> I am re-submitting thr because it doesn't seem to be showing in the 
> newsgroup. 
> 
> So I spoke a bit too soon on the firewall.This morning I had time to look at 
> it from a physical and configuration sense.  It is a pfSense firewall that 
> has multiple WAN ports enabled for multiple ISP. The path from the WAN that 
> contains the MX IPs does not load balance or failover to the other WAN port. 
> At one time this was setup but was turned off for some reason.
> 
> So NAT/PAT points it to the barracuda. Which in turn passes it to the proper 
> email server based upon domain or IP address.
> 
> To avoid outbound sending confusion from multiple gateways there is an 
> Outbound NAT but that shouldn't affect the incoming email as those 
> connections are from a different source. 
> 
> In light of this configuration would it still make sense to have multiple MX 
> records? One for each WAN/ISP?
> 
> I am considering trying to capture and inspect port 25 as it crosses from the 
> firewall to the barracuda to see if that will shed light on the situation. 
> 
> Thanks,
>  Job
> 
> 
> On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus  > wrote:
> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop  > wrote:
> >
> > There is PAT firewall that load balances multiple networks.
> 
> Maybe one of those destination networks is unreachable, while others
> are reachable, so when the load-balancing decision points to the
> unreachable network, the TCP session will not establish? Have you
> verified connectivity of each and every backend server from your
> load-balancers perspective?
> 
> Using multiple MX records, one for each destination mailserver would
> be the better setup, as opposed to load-balancing incoming port 25
> traffic (probably without appropriate health-checking and logging) of
> a single MX record.
> 
> 
> cheers,
> lukas
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

[mailop] Fwd: Intermittent slow email delivery

[Job Cacka via mailop]

I am re-submitting thr because it doesn't seem to be showing in the
newsgroup.

So I spoke a bit too soon on the firewall.This morning I had time to look
at it from a physical and configuration sense.  It is a pfSense firewall
that has multiple WAN ports enabled for multiple ISP. The path from the WAN
that contains the MX IPs does not load balance or failover to the other WAN
port. At one time this was setup but was turned off for some reason.

So NAT/PAT points it to the barracuda. Which in turn passes it to the
proper email server based upon domain or IP address.

To avoid outbound sending confusion from multiple gateways there is an
Outbound NAT but that shouldn't affect the incoming email as those
connections are from a different source.

In light of this configuration would it still make sense to have multiple
MX records? One for each WAN/ISP?

I am considering trying to capture and inspect port 25 as it crosses from
the firewall to the barracuda to see if that will shed light on the
situation.

Thanks,
 Job


On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus  wrote:

> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop 
> wrote:
> >
> > There is PAT firewall that load balances multiple networks.
>
> Maybe one of those destination networks is unreachable, while others
> are reachable, so when the load-balancing decision points to the
> unreachable network, the TCP session will not establish? Have you
> verified connectivity of each and every backend server from your
> load-balancers perspective?
>
> Using multiple MX records, one for each destination mailserver would
> be the better setup, as opposed to load-balancing incoming port 25
> traffic (probably without appropriate health-checking and logging) of
> a single MX record.
>
>
> cheers,
> lukas
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Intermittent slow email delivery

[Job Cacka via mailop]

Perhaps this original message is still stuck in some queue? I wrote it
yesterday and it never made it through to the list. At least it isn't in
the archive so try again.

So I spoke a bit too soon on the firewall last week. Monday morning I had
time to look at it from a physical and configuration sense.  It is a
pfSense firewall that has multiple WAN ports enabled for multiple ISP. The
path from the WAN that contains the MX IPs does not load balance or
failover to the other WAN port. At one time this was setup but was turned
off because some prtotocols don't failover well.

So NAT/PAT points it to the barracuda. Which in turn passes it to the
proper email server based upon domain or IP address.

To avoid outbound sending confusion from multiple gateways there is an
Outbound NAT but that shouldn't affect the incoming email as those
connections are from a different source.

In light of this configuration would it still make sense to have multiple
MX records? One for each WAN/ISP?

I am considering trying to capture and inspect port 25 as it crosses from
the firewall to the barracuda to see if that will shed light on the
situation.

Also, I am curious if these failed attempts could be related to DNS issues.
All my checks on DNS this far have been ok. And little to nothing has
changed in that regard in the last 7 or 8 weeks.
Historically we don't use or support TLS and perhaps that is the cause. I
know in the last 4-5 years this climate has dramatically changed.

Thanks,
 Job



On Fri, Jul 10, 2020 at 5:24 PM Ángel via mailop  wrote:

> On 2020-07-10 at 14:36 -0700, Job Cacka wrote:
> > There is PAT firewall that load balances multiple networks.
> > A Barracuda spam filter
> > And then the MX server.
> >
> >
> > It was working well until about 6-8 weeks ago when we began to notice
> > the intermittent issue.
> >
> >
> > Thanks,
> > Job
>
> I would have a look at that firewall. Is is possible that it may be
> trying to load balance with a missing host?
>
> I see that 50% of the connection attempts, the SYN receives RST,ACK
> while the other 50% the expected SYN,ACK.¹
>
> For the record, the TTL of the SYN,ACK is two units bigger than the one
> of the RST,ACK ones.
>
>
> Best regards
>
>
>
> ¹ not the *same* ones, but of a block of 16, as produced by
> tcptraceroute, I'm seeing a consistent split of 8/8
>
>
> ___
> 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

[Job Cacka via mailop]

Probably because of the reply all gmail requires. It wasn't hitting
mailop@mailop.org.

On Mon, Jul 13, 2020 at 11:15 AM Luis E. Muñoz  wrote:

>
>
> On 13 Jul 2020, at 11:08, Job Cacka wrote:
>
> > This didn't go through two hours ago from my gmail account.
>
> I saw it two hours ago.
>
> Best regards
>
> -lem
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Intermittent slow email delivery

[Job Cacka via mailop]

This didn't go through two hours ago from my gmail account.

So I spoke a bit too soon on the firewall.This morning I had time to look
at it from a physical and configuration sense.  It is a pfSense firewall
that has multiple WAN ports enabled for multiple ISP. The path from the WAN
that contains the MX IPs does not load balance or failover to the other WAN
port. At one time this was setup but was turned off for some reason.

So NAT/PAT points it to the barracuda. Which in turn passes it to the
proper email server based upon domain or IP address.

To avoid outbound sending confusion from multiple gateways there is an
Outbound NAT but that shouldn't affect the incoming email as those
connections are from a different source.

In light of this configuration would it still make sense to have multiple
MX records? One for each WAN/ISP?

I am considering trying to capture and inspect port 25 as it crosses from
the firewall to the barracuda to see if that will shed light on the
situation.

Thanks,
 Job

On Mon, Jul 13, 2020 at 8:58 AM Job Cacka  wrote:

> So I spoke a bit too soon on the firewall.This morning I had time to look
> at it from a physical and configuration sense.  It is a pfSense firewall
> that has multiple WAN ports enabled for multiple ISP. The path from the WAN
> that contains the MX IPs does not load balance or failover to the other WAN
> port. At one time this was setup but was turned off for some reason.
>
> So NAT/PAT points it to the barracuda. Which in turn passes it to the
> proper email server based upon domain or IP address.
>
> To avoid outbound sending confusion from multiple gateways there is an
> Outbound NAT but that shouldn't affect the incoming email as those
> connections are from a different source.
>
> In light of this configuration would it still make sense to have multiple
> MX records? One for each WAN/ISP?
>
> I am considering trying to capture and inspect port 25 as it crosses from
> the firewall to the barracuda to see if that will shed light on the
> situation.
>
> Thanks,
>  Job
>
>
>
>
>
> On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus  wrote:
>
>> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop 
>> wrote:
>> >
>> > There is PAT firewall that load balances multiple networks.
>>
>> Maybe one of those destination networks is unreachable, while others
>> are reachable, so when the load-balancing decision points to the
>> unreachable network, the TCP session will not establish? Have you
>> verified connectivity of each and every backend server from your
>> load-balancers perspective?
>>
>> Using multiple MX records, one for each destination mailserver would
>> be the better setup, as opposed to load-balancing incoming port 25
>> traffic (probably without appropriate health-checking and logging) of
>> a single MX record.
>>
>>
>> cheers,
>> lukas
>>
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Rolling DKIM Key Disclosure

[Phil Pennock via mailop]

On 2020-07-10 at 17:59 -0700, Brandon Long via mailop wrote:
> Anyways, ecc has been added to DKIM, but I'm not sure how widely deployed
> verifying it is.
> https://tools.ietf.org/html/rfc8463

Exim has implemented a=ed25519-sha256 for some time, and verifies it.
By mail volume that's not a lot, but by independent installs it counts a
bit more.  Support was added in Exim 4.91, released in April 2018 and
does require a modern GnuTLS or OpenSSL.  That last requirement cuts
back the percentage of sites which might be able to verify.  :-D

My domain dual-signs.  There were a couple of glitches at first with
this hurting deliverability, but if (fallible) memory serves the only
offender I really noticed was Gmail and that one was quickly fixed after
I raised the issue.  For the most part, receivers now just ignore the
second signature when they don't understand it.

The first three lines of an AR header added by Google, for instance:

  Authentication-Results: mx.google.com;
   dkim=pass header.i=@spodhuis.org header.s=d202005 header.b=GJ0knaFX;
   dkim=neutral (no key) header.i=@spodhuis.org;

In that, the "no key" is for selector `d202005e2`.

At present, support is not widespread enough that you can realistically
just use Ed25519 keys and expect it to work.

On 2020-07-11 at 15:02 -0400, John Levine via mailop wrote:
> For one thing, while it was kind of cute that we could still check the
> DKIM signatures on old DNC mail (I did)
[...]
> The other is that nobody I know found the DKIM validation to be more
> than a curiosity. People believed the messages were real because they
> knew who used the account and they were otherwise plausible.

I had a couple of people come to me and ask; one of them said something
along the lines of "They're saying these are faked, but they're
DKIM-signed, which is supposed to prevent that isn't it?  Can you check
to see if they really are fake?"

They were _inclined_ to believe the mails were legitimate but were
_insulted_ by the lies claiming that they were faked.  I believe that
they ended up voting third party (in their state it didn't make much
difference).  There's a difference between "what people will believe
about the origins" and "how people assess your behavior when you're
caught out and then start lying".

I can understand why folks might want their mails to be validated as
legitimately theirs for authenticity near delivery time while still not
wanting them to suddenly be elevated from "ephemeral" to "provable"
communications.  Even if in my judgemental moments I do raise an
eyebrow.

I've had cause to integrate DKIM signing from various providers into
$employer domains and the best ones have said "set up three CNAMEs
from your domain to these names under our control; that way, we can
rotate keys freely and you never need to care about our rotation
schedules".  They either pre-set the names, or let you choose freely and
just tell them your selector names.

The worst (of those that implement DKIM at all, so it's "worst of a good
bunch") are those which have you set up one selector, with a fixed
unchangeable name, whether CNAME or direct TXT.  Those are the ones who
will never be able to sanely rotate and will be facing an expensive
up-hill battle trying to get _all_ their customers to add extra names so
that they can one day stop signing with the older key.  Or, they will
just change the key behind the selector and risk breakage during the
cache invalidation and mail queue overlap periods.

Enough of the providers use fixed predictable names that my dns-email
script for doing domain integrity checks can derive a bunch from the SPF
records.  Which is helpful for me and potentially useful for those with
databases of domains who want to use DNS queries to do third-party
auditing of market penetration to verify SEC statements about market
penetration, so I guess a win for legitimate ESPs too.  :)

-Phil

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

Re: [mailop] Rolling DKIM Key Disclosure

[Matt Corallo via mailop]

I agree! But, sadly, Rackspace doesn't seem to care much, presumably because 
most mails get through thanks to DKIM, and
its always the sender that complains their emails aren't getting through, not 
the forwarder :(

Matt

On 7/12/20 4:29 AM, Laura Atkins wrote:
> 
> 
>> On 11 Jul 2020, at 18:18, Matt Corallo via mailop > > wrote:
>>
>> Right, maybe I’ve missed something - in my (albeit limited) experience, mail 
>> that gets forwarded a few times by
>> various filters (most recent issue I’ve seen is someone trying to forward 
>> Rackspace -> Gmail -> ZenDesk, which,
>> somewhere along the way didn’t make it), and without anything tying the 
>> sending domain to the sending IP, things look
>> slighting more spammy to filters and you’re more likely to get dropped. Is 
>> there some other fix for cases like the above?
> 
> Folks forwarding mail around like that should be ensuring that their 
> forwarding system isn’t dropping mail legitimately
> forwarded. 
> 
> laura 
> 
> -- 
> Having an Email Crisis?  We can help! 800 823-9674 
> 
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com 
> (650) 437-0741
> 
> Email Delivery Blog: https://wordtothewise.com/blog
> 
> 
> 
> 
> 
> 
> 

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

[mailop] Mailinblue

[Lili Crowley via mailop]

Can someone from Mailinblue contact me off list?

Thanks!
Lili


Lili Crowley
Postmaster
Verizon Media
___
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]

Just keep in mind, Journaling is PRE-FILTERED mail.

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

From: mailop  On Behalf Of Faisal Misle via mailop
Sent: Tuesday, July 7, 2020 6:36 AM
To: Stefan Bauer ; mailop 
Subject: [EXTERNAL] Re: [mailop] Post-processing Journal-Mails coming from 
O365, forwardedMail

Have you tried journal rules?

https://docs.microsoft.com/en-us/exchange/security-and-compliance/journaling/configure-journaling

Best,
Faisal Misle
MCSA: Office 365

PGP Key: 
C8FD029B


On Tue, Jul 7, 2020 at 6:20 AM, Stefan Bauer via mailop 
mailto:mailop@mailop.org>> wrote:

Hi,

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 makes it very hard for handling/searching/reading of these mails.

Are there any tools available to just have the attachment that is the real and 
original mail?

example-mail can be found here:

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

I tried ripmime, but that removes relevant header-parts.

Thank you.

Stefan


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

[mailop] harassment/death threat detection/filtering/prosecution

[Paul Ebersman via mailop]

We have all sorts of tools for detecting, filtering, documenting spam
and processes for trying to get spammers off the net (and occasionally
even prosecuted).

But in these tense times, lots of PoC/non-white/non-cis get hate emails,
death threats, etc.

Is there software out there like spamassassin et al for detecting these
kinds of threats? Does anyone have pointers on web pages/instructions
for how to configure common mail readers/services so users can
self-filter?

Finally, I know that there are avenues for tracking illegal activity and
ways to work with FBI, Interpol, etc. Any of these teams specialize in
or at least familiar with how to prosecute hate crimes perpetrated via
email threats?


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

[mailop] Test email.

[Simon Lyall via mailop]

Just testing.

--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar


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

Re: [mailop] Rolling DKIM Key Disclosure

[Laura Atkins via mailop]

> On 11 Jul 2020, at 18:18, Matt Corallo via mailop  wrote:
> 
> Right, maybe I’ve missed something - in my (albeit limited) experience, mail 
> that gets forwarded a few times by various filters (most recent issue I’ve 
> seen is someone trying to forward Rackspace -> Gmail -> ZenDesk, which, 
> somewhere along the way didn’t make it), and without anything tying the 
> sending domain to the sending IP, things look slighting more spammy to 
> filters and you’re more likely to get dropped. Is there some other fix for 
> cases like the above?

Folks forwarding mail around like that should be ensuring that their forwarding 
system isn’t dropping mail legitimately forwarded. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







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

Re: [mailop] Intermittent slow email delivery

[Job Cacka via mailop]

So I spoke a bit too soon on the firewall.This morning I had time to look
at it from a physical and configuration sense.  It is a pfSense firewall
that has multiple WAN ports enabled for multiple ISP. The path from the WAN
that contains the MX IPs does not load balance or failover to the other WAN
port. At one time this was setup but was turned off for some reason.

So NAT/PAT points it to the barracuda. Which in turn passes it to the
proper email server based upon domain or IP address.

To avoid outbound sending confusion from multiple gateways there is an
Outbound NAT but that shouldn't affect the incoming email as those
connections are from a different source.

In light of this configuration would it still make sense to have multiple
MX records? One for each WAN/ISP?

I am considering trying to capture and inspect port 25 as it crosses from
the firewall to the barracuda to see if that will shed light on the
situation.

Thanks,
 Job





On Fri, Jul 10, 2020 at 3:56 PM Lukas Tribus  wrote:

> On Fri, 10 Jul 2020 at 23:36, Job Cacka via mailop 
> wrote:
> >
> > There is PAT firewall that load balances multiple networks.
>
> Maybe one of those destination networks is unreachable, while others
> are reachable, so when the load-balancing decision points to the
> unreachable network, the TCP session will not establish? Have you
> verified connectivity of each and every backend server from your
> load-balancers perspective?
>
> Using multiple MX records, one for each destination mailserver would
> be the better setup, as opposed to load-balancing incoming port 25
> traffic (probably without appropriate health-checking and logging) of
> a single MX record.
>
>
> cheers,
> lukas
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop