[mailop] [ADMIN] Re: Cloud hosts for responsible mail servers?

[Graeme Fowler via mailop]

Following on from Bill’s comment I would strongly advise the following:

* If someone asks a question on the list and you do not know the answer, DO NOT 
turn to *any* generative AI instance, ask the question, and post the output as 
an answer - attributed or otherwise.

On another forum in which I have an interest we’ve already seen LLMs spit out 
regurgitated material from forum posts (which were not correct) as answers to 
prompts, which members have then posted as answers. They were wrong in the 
first place, and the more they get crunched up by the LLMs which are harvesting 
the entire content of the web, the more wrong they become.

Mailop has a pretty long history of subject matter experts being just that - 
experts, offering their time and knowledge to improve mail interoperability. 
Please let’s keep it that way and not pollute it with the hallucinations of 
expensive energy-hungry silicon!

Graeme (wearing list admin hat)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Domains discrimination

[Graeme Fowler via mailop]

On 10 Jul 2024, at 19:44, Jeff Pang via mailop  wrote:
> 
> Is there domain name discrimination in the email industry? For example, com, 
> net, and org are considered to have higher reputations, while info, xyz, and 
> top are considered to have lower ratings. The latter do attract a lot of spam 
> because they are cheaper in the first year. Will this lower the ratings of 
> these domain names?

My first thought was, rather uncharitably, “you’re new here, aren't you?”.

But then I stopped to think about that; if you don’t know, you don’t know. And 
our (collective) job is to make sure you do, so…

When ICANN decided to loosen the belts on non-country code TLDs, the spam 
business licked their lips and said “have at it, boys”. They mechanised 
registrations and spewed forth spam like there was literally no tomorrow, to 
the extent that TLDs like .xyz/.top (much less .info, which preceded them) were 
blocked within a few hours or days of going live by a very large number of mail 
operators.

At $WORKPLACE I think I’ve only had two FPs for those TLDs since they were 
launched.

So it’s not the pricing, per se, it’s the governance. If people want to live on 
the edge of the Wild West they can, just don’t assume my (or other) users wish 
to also.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] Re: AT Block

[Graeme Fowler via mailop]

On 5 July 2024 23:23:08 Jeff Pang via mailop  wrote:

No. TNL(t-online) is even worse.
BTW, you may contact Lili directly who is on this list.


Please don't do this again. It's one thing for a representative of an 
organisation to invite contact off list; it's something else entirely for a 
third party to make that invitation.


Thanks

Graeme (wearing list admin hat)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to ensure ownership from a Microsoft email?

[Graeme Fowler via mailop]

On 5 Jun 2024, at 13:56, Cyril - ImprovMX via mailop  wrote:
> @Graeme, I'd join @John on this; if Microsoft can validate a domain DNS, they 
> should make it mandatory to sign using the domain name and not some 
> unverifiable *.onmicrosoft.com.
> Nowadays even more when you want to have domain alignment with DMARC.

Microsoft 365’s Exchange Online component - with which I have a 
sometimes-hate/sometimes-marginally-less-hate relationship through work - is an 
immensely flexible, configurable beast with a zillion different options. The 
primary issue for me isn’t the spam side of it, it’s the fact that any vaguely 
IT literate person can create a tenancy and then try to set it up following a 
zillion different “best” practice guides on the web.

There’s only a single instance where adding a custom domain, doing the DNS 
validation, and then being forced automatically into using DKIM on that domain 
would work, and that’s where every single moving part of the email domain is 
within the tenancy. If any part of it is an externality such as an external 
filtering system, or an archiving system, or some form of governance system 
then it all falls apart very quickly.

As we all know, SMTP ain’t actually simple at all. Sigh.

Graeme

PS I’m definitely on the hate side today, having discovered that to actually 
_use_ MS’s implementation of DKIM, I may well have to shell out a 6 figure GBP 
sum. If anyone can demonstrate to me that outbound DKIM signing in Exchange 
Online Protection is possible, and working, without any additional Defender for 
M365 licenses then the beers are on me. So far all my research points to it 
being a paid-for feature!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to ensure ownership from a Microsoft email?

[Graeme Fowler via mailop]

On 5 June 2024 08:57:38 Cyril - ImprovMX via mailop  wrote:
All of this because Microsoft is unable to properly sign an email with the 
sender's domain to prove ownership...


All of that because the tenant administrator hasn't set up the Exchange 
Online service to sign outbound with their own domain, so it gets the 
default DKIM signature of the tenancy domain (the onmicrosoft bit).


In order to use a domain as an outbound sending domain, the domain owner 
has to validate it in their DNS - so they've done that.


The tools are there, they just have to be used properly.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Someone at Google (GSuite) with a clue?

[Graeme Fowler via mailop]

You said:

then there's a bounce


and then:

GMail is accepting our messages, then silently junking them.


So... Which of these is correct? They can't both be.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] bigpond.com IB302 sender domain rejected

[Graeme Fowler via mailop]

[Admin note]

I've said it before and no doubt I'll say it again, but please please 
PLEASE don't obfuscate or mask the domains you're trying to find support for.


Including all the actual unobfuscated FQDNs may turn up assistance from 
quarters you don't expect.


Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debt Collection Client Email Servers

[Graeme Fowler via mailop]

On 25 Mar 2024, at 16:53, Jaroslaw Rafa via mailop  wrote:
> 
> Does USA have a government-certfied platform for electronic delivery of
> documents (like many European countries have) where every person can create
> a "trusted account" ("trusted" means the identity of the person is confirmed
> in some way based on some documents the person provides) and then have such
> legal communications delivered to their "trusted account" and not via
> e-mail?

Bearing in mind that the USA is a federal country comprised of 50 different 
smaller countries, each of which are made up of a bunch of even smaller 
countries still (almost ad infinitum) - nope. As a Brit, my mind is regularly 
bamboozled by the forest of responsible authorities that the US has, down to 
small town level.

I’m entirely with everyone that thinks email isn’t the right route for these 
communications though!

Graeme (slightly tongue-in-cheek)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [spamhaus] de-listing requests successful, but only for a couple of days.

[Graeme Fowler via mailop]

On 14 Mar 2024, at 16:53, Michael Grimm via mailop  wrote:
> I am getting listed almost on a daily basis on two IPv6 addresses of mine 
> which happen to be part of OVH's address space (yes, I know).

…you do. So to:

> Is there a way to make that de-listing more persistent?

Yes. The following text is fairly instructive:

In the last month we have observed 76 listings.
2001:41d0:701:1000::/64 has been detected 76 times in the last month. It has 
been removed 7 times.

In the last month we have observed 63 listings.
2001:41d0:20a:800::/64 has been detected 63 times in the last month. It has 
been removed 4 times.

As you can see, it’s the entire /64 getting listed in both cases. They’re 
unsavoury neighbourhoods by the look of things.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Graeme Fowler via mailop]

On 8 March 2024 17:04:36 Stefano Bagnara via mailop  wrote:

I just got an answer from them that the issue is fixed.
Thanks to everyone!


Thank you to you for doing the right thing.

I know everyone wants to smack down on OVH but ascribing actions such as 
those mentioned in this thread to an actor who may not be represented here 
is... unhelpful.


It does the posters, and ultimately the list, very few favours.

I also know that nature abhors a vacuum and we all want to get an 
explanation but my engineer's hat says "find the issue or report it to 
someone who can, and either fix it or get them to" rather than "speculate 
wildly based on your specific prejudices".


IOW: facts please, not speculation.

Thanks!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Office365: only accepts messages from people in its organization or on its allowed senders list

[Graeme Fowler via mailop]

On 20 Feb 2024, at 11:40, Andre van Eyssen via mailop  wrote:
> The second word is the key. Pretty standard -- this is a group distribution 
> list that explodes to a larger set of recipients and you can't use it because 
> you're not on the whitelist.

So whilst the distribution group configuration is deliberate (and very common 
in large corporate Exchange environments), there’s a basic operational mistake 
by the sender - they’ve either managed to do the rare trick of sending From: 
the DG’s email address, or they’ve set the Reply-To: header to reply to the DG. 
(it could also be done by an outbound transport rule, I know).

As the list is restricted, that’s pretty poor business practice - “We expect 
you to reply to this message, but you can’t, and here’s why!”

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] Why is mail forwarding such a mess?

[Graeme Fowler via mailop]

Note: not specifically in response to the message I'm replying to!

Having just read the last 30 or so messages in this thread, I'm afraid it's 
all starting to feel very very circular.


1. Forwarding is a basic feature of MUAs and mail systems, whether by user 
choice, rules, or "forward all" regardless of platform or mechanism. That's 
been reality since (arbitrary year) 1997.
2. It can cause both technical and user-side problems due to authentication 
chains being broken.

3. SPF, DKIM, DMARC & ARC all exist.
4. None of them - or even all of them together! - aren't the singular 
answer to 2.

5. See 1.

I'm pretty sure we could all add a couple of extra dimensions (or even 
additional cryptographic DNS signing/non-refutation/non-repudiation 
protocols) for extra clarity, but points 1 and 5 are fixed and fairly 
indisputable.


Unless there's anything that's really clearly new and helpful to the 
discussion, let's just agree:


Forwarding is problematic, and it isn't 1997 any more.

(Also: the corporate/institutional risks of automatic forwarding and data 
breaches aren't as well understood by end users as we may wish them to be)


Cheers!

Graeme

[PS up to two miles on foot now before my leg muscles cry STOP!]

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Graeme Fowler via mailop]

On 9 February 2024 17:17:47 Scott Mutter via mailop  wrote:

This is why we can't have nice things.


I disagree. The continual chase of money over everything - ethics, morals, 
decency included - is why we can't have nice things.


It's one thing for someone to run a technical operation to provide people 
who can't with a service while providing a small number of other people 
with a living.


It's something else entirely for someone without ethics, morals or decency 
to realise that there are catastrophically large holes in a bunch of 
internet protocols that can be abused to make extremely large sums of cash, 
whether very very quickly or over a much longer period.


The trust model that the Internet was built on was wrecked the moment 
serious money was available to people, legitimately or otherwise.


Apologies if that all sounds a bit conspiratorial but so far as I'm aware 
that's the sad reality we live in!


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] zen.spamhaus.org

[Graeme Fowler via mailop]

On 6 February 2024 20:51:59 Odhiambo Washington via mailop 
 wrote:
Today morning I woke up to all emails being rejected as I was using 
zen.spamhaus.org in my dnslists.

Almost all incoming emails - even from gmail.com - were being rejected.

Did I maybe miss something


Are you checking the return codes from the lookup for validity, or just 
rejecting on a return code existing?


If you're using public resolvers, or your own resolvers are over the query 
threshold that's documented by SH, you'll need to register. Their docs are 
very clear and helpful.


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] Re: Extortion spam from OVH-hosted *.sbs domains

[Graeme Fowler via mailop]

On 26 Jan 2024, at 10:28, Jaroslaw Rafa via mailop  wrote:
> But even people who have extensive theoretical knowledge often fail to
> actually apply it when it comes to practice.

This has absolutely nothing at all to do with email or interoperating email 
systems. Please desist.

More generally, and I’m disappointed to have to type this *again*: if your post 
is not actually adding value to a discussion, don’t post it. If your post is 
aimed at a list member, rather than what they wrote, don’t post it. If you do, 
you can expect at the very least to be put on moderation.

Thanks!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus contact?

[Graeme Fowler via mailop]

On 19 January 2024 06:13:20 hg user via mailop  wrote:

Since most RBLs exchange data


Small pedantic point: DNSBLs, not RBLs.

Trend Micro would still assert that the term RBL is their trademark (so far 
as I know), plus a non-small percentage of known DNS block lists could not 
be even marginally described as "real time".


Graeme (wearing massive floppy felt pedant hat with huge gold tassels 
attached to make the point) :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [ADMIN] BIMI, Logos etc

[Graeme Fowler via mailop]

On 14 January 2024 15:55:43 Graeme Fowler via mailop  wrote:
Unless anyone has anything new, valid, on-point and worthy of further 
discussion, I'd suggest that we're done here.


I'm no longer suggesting. Just stop rehashing the thread. It's dead. It's 
not pining for the fjords.


Thanks

Graeme, preparing the mod- and ban- hammers for those who appear desperate 
to trash the utility of the list.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Graeme Fowler via mailop]

You can, yes. But would anyone trust it?

I wouldn't.

Graeme

On 14 January 2024 17:49:36 Russell Clemings via mailop  
wrote:
But 
https://learn.microsoft.com/en-us/microsoft-365/admin/setup/domains-faq?view=o365-worldwide 
says:


"You can keep using the initial onmicrosoft.com domain even after you add 
your domain. It still works for email and other services, so it's your choice."


... or am I misunderstanding?

I'm tempted to block *. onmicrosoft.com completely but I'm very afraid.

On Sun, Jan 14, 2024 at 5:15 AM Graeme Fowler via mailop 
 wrote:


On 13 January 2024 14:07:46 "L. Mark Stone via mailop"  
wrote:
Is there a list of "legitimate" subdomains of onmicrosoft.com somewhere 
that we can leverage?


Wearing my "I have to administer a Microsoft 365 tenancy" hat - no.

However, your mention of best practice is bang on. The subdomains of 
onmicrosoft.com are tenant boundaries and not intended to be used for 
email. Domains should be added, verified and configured properly for 
outbound mail.


I would personally say that you will lose practically no real email by 
rejecting those subdomains completely - and if you get complaints from 
actual M365 tenant customers, point them at the docs.


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


--
===
Russell Clemings

===___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] BIMI, Logos etc

[Graeme Fowler via mailop]

Afternoon folks

Sadly we've how reached the point of silliness in the various sub-threads 
of the recent original BIMI thread.


Unless anyone has anything new, valid, on-point and worthy of further 
discussion, I'd suggest that we're done here.


Please think several times as to whether anything you may want to post in 
reply is adding anything or simply continuing an off topic pointless 
discussion.


Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Graeme Fowler via mailop]

On 13 January 2024 14:07:46 "L. Mark Stone via mailop"  
wrote:
Is there a list of "legitimate" subdomains of onmicrosoft.com somewhere 
that we can leverage?


Wearing my "I have to administer a Microsoft 365 tenancy" hat - no.

However, your mention of best practice is bang on. The subdomains of 
onmicrosoft.com are tenant boundaries and not intended to be used for 
email. Domains should be added, verified and configured properly for 
outbound mail.


I would personally say that you will lose practically no real email by 
rejecting those subdomains completely - and if you get complaints from 
actual M365 tenant customers, point them at the docs.


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] Re: BIMI boycott?

[Graeme Fowler via mailop]

I'm back, and I want people to play nicely.


Whilst differences of opinion are fine, this thread (as it did in 2020) is 
rapidly veering very close the line of acceptability.



Remember, please, that whilst we have a mix of members from single users 
running their own system, thru enthusiasts running small systems for a few 
people, companies with a few thousand customers, academic institutions with 
tens or hundreds of thousands, the 500lb gorillas with millions or billions 
- we also have members whose job it is to SEND email rather than ensure 
their users receive it.


You may not like this. You may think they're the reason for all your ills.

Articulate it nicely, or... *plonk*

Thanks! And a Hippy New Year to you all :)

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] "451 Requested action aborted: local error in processing" when submitting email to ionos email services.

[Graeme Fowler via mailop]

Looks like dns.hiskp.uni-bonn.de isn't reachable or responding, which could 
explain the intermittent nature.



Graeme

On 12 December 2023 07:57:48 Michael Lang via mailop  wrote:


Hi everybody,

for approximately one year, we are receiving regular complaints from
remote contacts having problems to ship email from a service like
gmx.de, gmx.net, 1und1.de and similar in fact services hosted by ionos
to our email domain (@hiskp.uni-bonn.de, MX=mx8.hiskp.uni-bonn.de).
During submission of ionos customers to one of the ionos servers people
eventually receive an error of type:

451 Requested action aborted: local error in processing

We tried to track this error on our own and found out that this warning
randomly appears and if a resubmit is tried a few seconds later,
submission via ionos services works flawlessly. Guessing that this might
be caused by the MX entry for our destination getting lost in the cache
of ionos submission servers due to a to short TTL, we tried changing
that in our DNS, but this did not change the scenario.

We furthermore observed that mail systems obviously receiving heavier
load than we do seem not to have this problem or it occurs very rarely.
Anyway that is for now a wild guess from us.
To us this appears as if the timeout checking DNS for the MX + A / 
records is too short, independant ot the TTL and it furthermore appears
to be load dependant on the ionos servers.
The same phaenomenon we regularly observe when mail from our site is
shipped to ionos servers. Here emails regularly get deferred for several
seconds with the same 451 error but are successfully acepted with code
250 a few seconds later.

As access to intermediate and top layer domain servers is obviously
beyond our administrational range, does anybody have an idea why this
occurs really? Is there maybe a contact at ionos to subscribe our email
service for flawless transport, such as e.g. at t-online.de?  Is this
problem known to anybody else and what did you do to fight it?

With kind regards

   Michael


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] I'm going for a lie down

[Graeme Fowler via mailop]

Hi folks

Apologies for not mentioning this any earlier, but at 0700 tomorrow I’m 
reporting to hospital to have my right hip replaced. I’m going to be largely 
incommunicado for a while. Be nice to each other, behave, try the veal, tip 
your waitress etc :)

Dont’ give Simon or Patrick a hard time in terms of moderation, please.

Tata for now, see you on the other side!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Charter/Spectrum/Roadrunner contact

[Graeme Fowler via mailop]

On 29 Nov 2023, at 13:33, Syed Alam via mailop  wrote:
> https://www.spectrum.net/support/internet/understanding-email-error-codes for 
> more information. AUP#In-1310"



> Is there anyone from #charter #Spectrum to assist us with what we are doing 
> wrong?

Did you follow the link and look up the very, very clear information contained 
within it?

Graeme

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] Re: Bounces

[Graeme Fowler via mailop]

On 16 Nov 2023, at 15:37, Carsten Schiefner via mailop  
wrote:
> One could possibly argue in addition that sending the same email three times 
> - where the tiny differences only come clear after close inspection - might 
> not help lifting some initial hesitancy.
> 
> Even more so when in combination with the above, they are sent to a random 
> set of list related addresses such as -request, -bounce and -owner. And when 
> in one instance the list address is specified twice.
> 
> That leaves impressions with regard to the general tone of the always 
> identical email text.

Agreed in every sense; however do note that I emailed the OP privately with a 
"please don't do this again or you'll be unsubscribed" message.

Regards

Graeme [wearing admin hat]
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [mod note] Re: Success MiTM attack

[Graeme Fowler via mailop]

Evening all

(Slavko, this is not aimed at you, it’s just the point in the thread I arrived 
at)

As several people in thread have noted, much of this discussion is not on topic 
for mailop.

Point of note: if you start typing something akin to “this is probably 
off-topic”, hit the escape key and delete the draft (other ways of not posting 
are available).

Cheers!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [STATE of the UNION] Tails from the trenches of the spam auditing team..

[Graeme Fowler via mailop]

On 24 August 2023 11:12:07 Jaroslaw Rafa via mailop  wrote:



If it is just a random netblock of some ISP that just happens to contain
some spamming IPs (even a lot of them) inside - no, never block the netblock
as a whole.


In all the years I've been running mail systems (which to my great 
astonishment is now greater than 25!) I've used a variety of netblock sizes 
and occasionally entire AS numbers in outright blocks.


In that whole time I've had precisely 1 report of a sender that was 
affected who had legitimate business with my employer.


One.

Your network, your rules; likewise for me, right?

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 not rejecting emails when instructed so by SPF recored?

[Graeme Fowler via mailop]

[moderator note]

SPF asserts senders (by definition)
NullMX asserts receivers (also by definition)

Interpretation aside, the fact they are (mis?)understood to be the same 
thing is a clear conflation. It may be language based, it may not, but 
please stop splitting this specific hair.


Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] UCEPROTECT L2 fact

[Graeme Fowler via mailop]

On 22 May 2023 21:50:54 Graeme Fowler via mailop  wrote:

Moderation note:

We have a permanent hold



Amusingly I got bitten by my own hold rule :)

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] UCEPROTECT L2 fact

[Graeme Fowler via mailop]

Moderation note:

We have a permanent hold on any messages that mention this DNSBL, for 
reasons which are reasonably well known but just in case you're new here:


Whilst not exactly "the list of which nobody should speak", over the years 
the tone of threads discussing them has often fallen well below the 
standards expected of professional mail system operators. The archives 
contain most of it.
The industry knows that the way this DNSBL operates is controversial, but 
as with the Internet in general - their product, their rules.


The hold will stay in place so that each and every mention is scrutinised 
before release.


Stay calm, be nice to each other, tip your waitress, try the veal etc etc

Yours in mailopping

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tightening of delivery rules for Exchange Online

[Graeme Fowler via mailop]

On 29 March 2023 13:53:59 "Gellner, Oliver via mailop"  
wrote:

I'm not sure what is meant by EOL


In this context, Exchange Online.

I understand the "eventually", but for now it's only applying to their 
closest customers.


At work I already have some small scoring rules in place that identify 
emails with received headers that hint at decade+ out of date MTA installs 
but take no action on them. They're just one more indicator of the 
trustworthyness of the source of the email.


If an organisation is still using something like Exchange 5.5, then the 
likelihood of the emails coming through it being malware is pretty high.


On the one hand, we as an industry curse and spit at MS for a number of 
things. Let's not do that when they're doing something which is actually 
fairly useful!


Graeme

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tightening of delivery rules for Exchange Online

[Graeme Fowler via mailop]

On 29 March 2023 13:53:59 "Gellner, Oliver via mailop"  
wrote:

I'm not sure what is meant by EOL


In this context, Exchange Online.

I understand the "eventually", but for now it's only applying to their 
closest customers.


At work I already have some small scoring rules in place that identify 
emails with received headers that hint at decade+ out of date MTA installs 
but take no action on them. They're just one more indicator of the 
trustworthyness of the source of the email.


If an organisation is still using something like Exchange 5.5, then the 
likelihood of the emails coming through it being malware is pretty high.


On the one hand, we as an industry curse and spit at MS for a number of 
things. Let's not do that when they're doing something which is actually 
fairly useful!


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tightening of delivery rules for Exchange Online

[Graeme Fowler via mailop]

On 28 March 2023 16:32:42 Tobias Fiebig via mailop  wrote:

https://techcommunity.microsoft.com/t5/exchange-team-blog/throttling-and-blocking-email-from-persistently-vulnerable/ba-p/3762078


This only affects Exchange Online customers with a hybrid setup, i.e. one 
where they have an on-premises Exchange server tied into their EOL environment.


At $dayjob, that's our current setup. Exim talks to and from the outside 
world, delivers to local Exchange, delivers to EOL (and the same IV 
reverse). We are however in the process currently of removing the local 
Exchange servers from the path. Ultimately the Exim end will disappear 
too... which means I'll be doing something new!


MS know what version and update level the local servers have because 
they're in an Exchange Organisation with EOL so share data each way.


So there's nothing nefarious here, just MS enforcing zero trust and best 
practice on their customers.


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [External] Re: verizon email-to-text gateway mail deferred evening and night

[Graeme Fowler via mailop]

Hi folks

Happy New Year to everyone!

That said: can we, possibly, drag this thread back onto a mail-related topic? 
If anyone from Verizon can answer the OP's question and/or points, that'd be 
grand. If not, please let this one lie.

Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Cloudflare abuse form

[Graeme Fowler via mailop]

Hi folks

Could someone from Cloudflare please contact me off-list? I'm trying to report 
a malware dropper (Emotet or Qakbot) that's on a customer site hosted by you 
and I can't paste the source of the email that was sent to us into your 
evidence box. Tried to put it in the Comments field but that tells me it's too 
big.

That's a mite frustrating!

Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone know about this list washing organization from yesterday?

[Graeme Fowler via mailop]

On 8 December 2022 17:17:45 Hans-Martin Mosner via mailop 
 wrote:
... Also known as M247 (don't know which company is a customer/subsidiary 
of which, don't care much either).


I know it's probably not cogent to the issue, but their head office and 
first DC was situated on the site of a former chemical plant that I worked 
on prior to & during my university years.


There is no way on this planet you'd get me working on that site now. I 
know what we handled and what ended up being spilled!


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Graeme Fowler via mailop]

All

soft_bounce is now set to 'no'.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [Admin] Changes to list behaviour, members spam filters etc

[Graeme Fowler via mailop]

Morning

Just to be clear: we will only be changing the soft_bounce setting at this time.

Even if all the suggestions being made were implemented, some list subscribers 
would *still* have problems receiving list mail and would reject it. It is 
incumbent on all members of the list to ensure that messages can be delivered, 
and if they can’t - then they’ll be unsubscribed by mailman’s automated bounce 
management.

Cheers all, happy Tuesday (or Monday, or Wednesday in whichever TZ you are)!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [Admin] Changes to list behaviour, members' spam filters etc

[Graeme Fowler via mailop]

Hello folks

A list member contacted us this morning to say that they'd observed a large 
number of messages from mx.mailop.org  being rejected by 
their anti-spam/malware system. This has raised a couple of points that I need 
to make:

1. The list frequently discusses spam, malware, scams and such like; as a 
result, a significant number of messages can and will continue to contain 
domains, hostnames, email addresses, technicques used by scammers/spammers and 
all manner of key words or terms that are only too likely to trip filters.
Whilst not demanding that list members add the list and/or server to any form 
of pass-list they may be running, it's possibly a good idea especially if you 
have the ability do this per-recipient.

2. I've spotted this morning that we still have postfix's 'soft_bounce' option 
set to 'yes'. This is an option which is used when testing and even has the 
comment:

# NOTE: This is good for test runs, but bad in production

just above it in the default config. It means that 5xx responses are treated 
'softly', so messages retry. As a result of this, I will be changing that 
option to 'no' in the near future.

THIS WILL CHANGE AUTOMATED SUBSCRIBER MANAGEMENT <--- note well!

mailman *will* disable, and subsequently unsubscribe, users with too many 
permanent errors. It will take time, as it's setup fairly leniently, and you'll 
receive automatic warnings if this happens once a week for 3 weeks before being 
automatically unsubscribed.

I will let everyone know when I've committed this change, probably later this 
week.

Regards

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus DNS issues causing all incoming mail to drop for me

[Graeme Fowler via mailop]

On 3 Nov 2022, at 15:59, Brian Knight via mailop  wrote:
> I'm seeing DNS issues this morning connecting to sbl.spamhaus.org.
> 
> This morning, my Postfix server was rejecting all incoming emails as spam. 
> Found that the A record for sbl.spamhaus.org is gone, replaced with SOA and 
> NS records that look a bit odd.

https://www.spamhaus.org/faq/section/DNSBL%2520Usage#122

There is no A record.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Tangent: Banks and imprint requirements in Germany

[Graeme Fowler via mailop]

[Admin Note]

Guys, ladies, people, fellow humans...

I spend a couple of days dealing with a work-based major incident and a 
weekend playing with racing cars (email me off list if you require an 
explanation of that!) and I open my email and...


90+ emails about laws in Germany.

Please stop it. If you ever have to prefix a subject with "Tangent" or "OT" 
or something similar, save it as a draft and go for a walk. When you've 
finished the walk, please delete the draft.


Please, for the love of $deity, keep it to email operations!

Thanks

Graeme
--
Yes. $deity can be undef or NULL.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Graeme Fowler via mailop]

Just for completeness here, and wearing both my Exim and Mailop hats:

No. There will be no changes to the Exim default configuration, nor should 
there be. If the suggestion was made of a commercial product with thousands 
of people behind it, it would likely result in costly litigation.


To suggest that an open source project - one with a shrinking developer 
group behind it, despite our best efforts - should do this, could be 
financial suicide for those developers.


Be sensible. The elephant in the room is a commercial ISP who've made a 
decision based on their own economics. Target that.


Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [dead thread] Re: SMTP noise from *.bouncer.cloud

[Graeme Fowler via mailop]

Now then...

On 7 Sep 2022, at 14:01, Laura Atkins via mailop  wrote:
>> On 7 Sep 2022, at 13:08, Radek Kaczynski (Radek from Bouncer) via mailop 
>>  wrote:
>> I've been thinking about incorporating blockchain technology and maybe smart 
>> contracts to make sure that the sender has the right to send to the 
>> recipient. But designing such a model would be super complex, cause it would 
>> have to be equal, and not available to the privileged.
> 
> You might want to look up “microsoft” “anti-spam” and “hash cash”.
> 
>> It's very complex… and I guess over my capabilities. But maybe some of you, 
>> or you together will figure out some real solution to the problem.
>> And maybe we could, instead of putting our time, energy and talent in 
>> fighting email verifiers, put it into creating new quality, that will solve 
>> the problem.
> 
> Wow. 

I see we've reached the mailop equivalent of Godwin's law - the first mention 
of blockchain.

Radek, thanks for your input, and thanks everyone for replying in (mostly) a 
fairly restrained way.

This thread is now dead. Please do not reply as your message will not reach the 
list.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [admin note] Re: SMTP noise from *.bouncer.cloud

[Graeme Fowler via mailop]

Hi all

Bearing in mind that Radek has somewhat stuck his head above an apparent 
parapet in participating here, I’d just like to remind you all to:

1. Be kind, even if you’re being critical
2. For everyone’s sake, keep the thread on topic.

There is a real, identifiable, problematic issue at hand here - it doesn’t need 
the accompanimet of endless hypothetical statements or thought experiments.

Thanks

Graeme
obo mod team
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Graeme Fowler via mailop]

On 20 Jun 2022, at 16:59, Rob Nagler via mailop  wrote:
> I looked at mailop's history, and it was a simple reflector in 2018, less 
> than 5 years ago. 

That piqued my interest - it has never been a "simple reflector", it's been 
using Mailman 2.x from the very beginning.

What happened throughout 2017 and 2018 was a notable increase in subscriber 
domains switching to more restrictive SPF and DMARC policies, so the mailman 
option 'from_is_list' (as it was then) became increasingly used, rewriting the 
RFC5321.From: header and adding a Reply-To: of the original sender.

I don't recall changing that setting around that time, but the first munged 
email I can find is way back in October 2016, so it was obviously set to 
Munge/Rewrite at the time. My archive only goes back to that time anyway!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [Admin note] Standards

[Graeme Fowler via mailop]

Morning all

While there is a lot of chat about standards on the list right now, I'd just 
like to remind subscribers of the standards expected of them:

Disagree with the substance of posts, by all means - that’s how society moves. 
But do not, at any point, resort to ad-hominem comments or remarks, or abuse. 
Now may be a good idea to reacquaint yourselves with the charter points on the 
front page of https://mailop.org/

This is a list full of professionals, so please be professional. If you can’t 
manage that, please unsubscribe before Simon, Patrick or I do that for you - 
not that we want to, but there are standards to be upheld.

Regards

Graeme
(wearing moderator hat)

PS Neither I, nor the list, need any replies. Thanks.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Talking DOXING of spammers on this mailing list..

[Graeme Fowler via mailop]

On 2 Jun 2022, at 08:01, Philip Paeps via mailop  wrote:
> While certainly entertaining, it's not really immediately actionable for most 
> mailops. Unless you're proposing we compile our blocklists from a mailop 
> thread. :)
> 
> I suggest sdlu is a better venue for this. Definitely very interesting though.

SDLU is absolutely the place for it. It might sound like a good idea, but I'd 
prefer this list to stay off the radar of those people by not being of any 
specific "interest" to them!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Graeme Fowler via mailop]

On 15 Apr 2022, at 16:39, Grant Taylor via mailop  wrote:
> Your VPS doesn't sound like "a free service".  But there is a chance that 
> your VPS is with a VPS provider that has a ... questionable reputation.  --  
> I speaking in the hypothetical as I've not looked.  -- Thus you may be 
> suffering from guilt by association (with your chosen VPS provider).

$ host 217.182.79.147
147.79.182.217.in-addr.arpa domain name pointer rafa.eu.org.

$ whois -h whois.cymru.com 217.182.79.147
AS  | IP   | AS Name
16276   | 217.182.79.147   | OVH, FR

Obviously we’ve had a great deal of discussion of OVH over the years, most of 
which wasn’t favourable. YMMV, obviously.

Also (referencing Google), I believe this is where we have to state “their 
network, their rules”. Again.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What the f**k, Google?

[Graeme Fowler via mailop]

On 2 Mar 2022, at 11:38, Jaroslaw Rafa via mailop  wrote:
> Google has quite a time ago gone completely crazy with regard to spam
> filtering. Obviously non-spam messages being constantly classified as spam,
> obvious spams being accepted.

If I may increase the sample size from 1 to 7; my parents, wife, kids and I all 
use Gmail.

Whilst I may occasionally - like 5 or 6 times a year - have something that 
lands in the Junk folder, I almost _never_ receive “obvious” spam in the Inbox, 
and neither do they.

I do appreciate that some people on the list have issues with Google (and 
similarly with Microsoft), but those experiences are not necessarily replicable 
globally. If they were, users would have moved to other platforms already - and 
they haven’t.

Obviously, other opinions are available too!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] sharepointonline.com MX record is broken

[Graeme Fowler via mailop]

On 16 February 2022 23:26:57 Michael Wise  wrote:



" Can you hear me now?[tm]


Loud and clear. Thanks!

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] sharepointonline.com MX record is broken

[Graeme Fowler via mailop]

Hello people with a line into Microsoft…

Starting just before 7pm UTC Feb 15th, we started seeing rejections for emails 
coming from sharepointonline.com:

2022-02-15 18:58:19 [26060]
  H=mail-am6eur05on2111.outbound.protection.outlook.com 
(EUR05-AM6-obe.outbound.protection.outlook.com) [40.107.22.111]
  F= rejected RCPT <_redacted_>: SENDVRF1: 
Cannot verify sending domain or address

As of right now, the MX record does not resolve:

$ dig @8.8.8.8 +short sharepointonline.com mx
0 sharepointonline-com.mail.protection.outlook.com.

sharepointonline-com.mail.protection.outlook.com does not resolve. That 
probably needs fixing pretty quickly.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [Admin note] re spam filters

[Graeme Fowler via mailop]

You lot will start a discussion on *anything* :)

On 25 Jan 2022, at 15:28, Bill Cole via mailop  wrote:
> I don't think Graeme was trying to speak to the people who actively have this 
> problemn but rather to those of us not yet afflicted. Good spam filters 
> evolve and it is better to protect yourself from letting them evolve to 
> disdain this list before it happens rather than waiting for a problem. Every 
> incident of spam filters rejecting list traffic can damage the functional 
> reputation of the list and the facilities it uses.

Thanks Bill, pretty much bang on.

The intent was for the majority of subscribers who lurk to have a think about 
how they might avoid getting kicked off the list. Not the "usual suspects", but 
those who metaphorically stand at the back of the room near the coffee machine.

For those not familar with Mailman, it processes bounces according to a rule 
marking them as "hard" (+1 point) or "soft" (+0.5). Only one increment happens 
per day. If the total score for a subscriber exceeds 10, then their membership 
is disabled. They then receive one notification every 7 days until 3 have been 
sent, at which point they are forcibly unsubscribed.

The bounce counter is reset to 0 once a subscriber doesn't bounce for 7 days.

So... we don't need to reach out to people, as the MLM software does that for 
us.

Cheers,

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [Admin note] re spam filters

[Graeme Fowler via mailop]

Morning (afternoon, evening, night!) everyone

Over the last couple of weeks an increasing number of subscribers have 
either had their subscription disabled or been auto-unsubscribed because 
list messages to them have bounced.


Several of these have been reported in the NDR as being a result of spam 
being detected in the message.


Whether you're using a 500lb Gorilla like M365, Gmail etc or a smaller 
operation, or self-hosting then please take whatever steps you can 
(safe/trusted senders, passlists etc) for mail from this list.


Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Microsoft IP Filtering - sort of full details

[Graeme Fowler via mailop]

Howdy

On 16 Jan 2022, at 15:09, John Gateley via mailop  wrote:
> It has been several days without response.
> I have tried several times, the most recent were yesterday and day before 
> yesterday morning
> (24 and 48 hours, roughly), but NONE of my forwards are getting a response.

I think you may have misunderstood the semantics of Michael’s reply. A cursory 
search of this mailing list’s archive will show you that Linode are like 
Marmite - loved or hated, in terms of reputation, in equal measure. They have a 
decent response team but the size of the operation and the automation/APIs/web 
UI they offer means it is almost trivial to turn up an IP, burn it with 
outbound spam, get whacked, turn up another one and so on.

For some recipients’ admins, Linode are “block on sight”.

It may be that MS have finally had enough, and as has been mentioned many times 
- their network, their rules (which also applies to you, and Linode, and 
everyone on this list).

You might get it fixed, you might not.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Looking for a hotmail/outlook contact

[Graeme Fowler via mailop]

Liam

On 12 Jan 2022, at 20:29, Liam Fisher via mailop  wrote:
> Looking for a hotmail/outlook contact

Background detail is required here. Your name is all we have; an explanation of 
the issue you need to make contact about (IP addresses, domains etc) is needed.

Graeme
(not an MS employee)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Graeme Fowler via mailop]

Admin note:


On 8 January 2022 14:34:03 Slavko via mailop  wrote:


To concretize it to this topic: goggle's mailbox is not reliable for
receiving DMARC reports, even for low traffic individuals/SMBs.


Please, stop, it's already dead. Or for those unfamiliar with the phrase - 
unless there's something of value to add to this thread, please stop 
extending it.


Thanks

Graeme

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] blocked by microsoft

[Graeme Fowler via mailop]

On 5 Jan 2022, at 18:42, Jay Hennigan via mailop  wrote:
> If the only way to send email to Microsoft or its customers is to use a 
> Microsoft product, they've won.

But that’s not the case here, is it? In extremis, perhaps, but sending to a 
specific provider from a network they’ve blocked is always going to be a 
challenge.

It could just as easily have been a suggestion to use Gmail, or ProtonMail, or… 
well, y’know.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] spamhaus blocking Linode IPv6 (2a01:7e01)

[Graeme Fowler via mailop]

On 25 Nov 2021, at 10:33, Mary via mailop  wrote:
> I noticed today that spamhaus.org is blocking large net blocks of IPv6 
> (2a01:7e01) owned by Linode. Pretty much all my clients hosted at Linode are 
> being blocked en mass (for IPv6 only).
> 
> Is there a way to inform spamhaus about this rather aggressive blocking and 
> get things sorted?

It’s on the XBL rather than the SBL:

https://check.spamhaus.org/listed/?searchterm=2a01:7e01::

"A device using 2a01:7e01::/64 is infected with malware and is emitting spam.”

Coincidentally there’s also a CSS (so SBL) listing for 2a01:7e00::/32, also 
Linode.

Graeme


signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Another admin note.

[Graeme Fowler via mailop]

Making no apology whatsoever about top posting from my phone's mail client:

STOP with the niggles. Please, just stop.

"I'm getting 1 unsolicited calendar invites from $provider every 
minute" seems to me a legitimate operational problem and one worth raising 
here, and/or directly with $provider.


"I don't like the way Google users do this one specific thing that makes me 
get occasional emails" and "I don't use my Google account very often and I 
don't like the security reminder they send"... yeah, those are not what 
mailop is for.


I'm genuinely disappointed that I'm having to say this *again* this week.

Any mailing list lives and dies by its' utility. If subscribers continue to 
bring small, personal issues to the fore here, the utility of the list will 
change and people will leave.


Don't kill it off, people.

Thanks. I'm off out for a curry so behave yourselves!

Graeme


On 16 October 2021 16:27:10 yuv via mailop  wrote:


On Tue, 2021-10-05 at 18:15 -0700, Brandon Long via mailop wrote:

larger providers are their own special targets.


Thank you for sharing with us the perspective of a Big service
provider, and how you deal with annoyances on that exa-scale.



We also see spammers try to use Gmail to spam other


I allow myself to draw your attention to two annoyances, to which
Google is at least a contributing factor if not the culprit, on a scale
that is sufficiently large to warrant some sort of filtering /
automation, or better, supression at the sender (Google).


(A) the calendar invite/reminder.  I understand the convenience, to
some, of emailed invite/reminders when a user creates a calendar entry
and adds contacts.  However, whether the meeting is legit or not, I
have not granted permission to the user to spam me with
invites/reminders; and I have not granted permission to Google to spam
me with a proposition to create a calendar on its system on every
reminder that I have not replied whether I will attend or not the
meeting.  I have my reasons not to reply to calendar invites / publish
my intention to attend.  I have my reasons to hate external reminders
with a passion.  And I have my reasons not to use Google's services.
At the very least, I would expect Google to offer an opt-out mechanism
per recipient (and, also per domain) that does not require the user to
create an account with Google.  And I would expect Google to accept no-
answer for an answer instead of repeating the invite/reminder multiple
times.  Even once is too many, i.e. spam.


(B) the "help us keep your account safe" reminder.  While in (A) Google
is merely a contributing factor, this one is all on Google.  It affects
Google Accounts that are associated with a third-party email address.
I must maintain one Google account for things that cannot be done
without Google Account.  It is a bare-minimum Google Account with need-
to-know information only.  When I log into it, it verifies my email
address by email me a six digits temporary code, so I can only log in
if I am in control of the email address associated with that account.
And yet, invariably, a day or two after I log into that account I get
the annoying "help us keep your account safe" reminder in which Google
asks me to click on an URL to confirm that I still have access to the
email address.  That reminder also keeps coming in regular, too
frequent intervals.  Once a year I could understand/tolerate, though a
user should be allowed to opt-out of the practice all together, without
requiring the user to deliver to Google any further information.


Thanks for your consideration.
--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google Postmaster Tools - No data since October 4th

[Graeme Fowler via mailop]

ADMIN NOTE

On 14 Oct 2021, at 10:39, Jaroslaw Rafa via mailop  wrote:
[ yet more content about a specific problem unrelated to the thread subject ]

All: please desist from turning every single thread on this list into 
discussion of Jaroslaw’s Google issue.

I have had more than one email sent to me about this in response to my last 
comments about decency (thanks for those) - the feelings expressed were that 
the thread hijacking that keeps occurring is making the list dysfunctional and 
tedious.

This thread is specific to the loss of functionality of Google’s Postmaster 
Tools. Please keep it that way.

Thanks

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Admin note

[Graeme Fowler via mailop]

All

Can we please try to retain at least a veneer of professionalism and decency 
within posts? I remind you all of the list charter, here:

https://www.mailop.org/

Too many posts recently have been openly aggressive, attacking, and attributing 
things incorrectly/invalidly and/or making assertions that cannot be supported 
by facts. Please keep posts accurate, evidence-based (along with said 
evidence), and respectful.

Thank you,

Graeme
obo list mods


signature.asc
Description: Message signed with OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [Mod note] GDPR et al

[Graeme Fowler via mailop]

Hi folks

It’s time to knock the GDPR discussions on the head, please. This isn’t really 
the list to be discussing trans-national interpretations of a set of laws which 
aren’t explicitly mail operations related.

Thanks

Graeme
obo maiop mods.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailop Digest, Vol 13, Issue 2

[Graeme Fowler via mailop]

[Admin note]

On 2 Aug 2021, at 11:00, Hagop Khatchoian wrote, again:
> Thank you for your email. I am on my annual leave and expect to have limited 
> access to connectivity, so I will not be checking emails frequently.

User put on moderation to prevent further autoreplies hitting the list.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] OVH Strasbourg suffers major fire

[Graeme Fowler via mailop]

Morning all

Some of you may have seen that OVH has suffered a catastrophic fire in one of 
their datacentre locations in Strasbourg. The CEO has written that one 
datacentre is destroyed, one partially damaged, and several others offline due 
to electrical isolation.

All staff, thankfully, have been accounted for and are safe.

Hopefully nobody on the list has been directly affected. Many of us will be 
indirectly affected due to the volume of sites they host, and many more may see 
web apps not functioning as bits of them are also hosted there.

From a mailop perspective, whilst this may seem a bit dark, I’d be interested 
to see whether this creates a (however brief!) downturn in hostility, spam and 
scams.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [Admin note] recent UCEPROTECT issues

[Graeme Fowler via mailop]

Hi all

Those of you who posted in reply to Vittorio’s message about the reprehensible 
- there is no other polite term for it in English - behaviour of a 
representative of the UCEPROTECT DNSBL will probably have realised that Simon, 
Patrick and I put the thread on ‘hold’.

We’ve had several discussions between us about the specific issue of 
UCEPROTECT, their behaviour, and the concurrent discussion on the mailop list. 
Some of the replies that were held for moderation were intemperate in their 
language and would only serve to further inflame discussions on the issue, 
which we feel would not be productive. We also believe that to further discuss 
the non-operational issues at hand here is treading a fine line in terms of 
being off-charter for the mailing list.

As a result:

1. The thread will remain moderated. Please do not reply further or your 
message(s) may be discarded.

2. We will review, and _may_ release, a small number of replies that were held 
for moderation if we feel the messages would be useful. Alternatively we might 
compile a single reply with quoted text, if we feel that would be better.

3. The remaining messages in the moderation queue will be discarded without 
further reply.

4. Any list members who are users/customers of UCEPROTECT should review the 
initial post and the link it contains and decide their own course of action.

For the record, only twice in the history of the mailop list have we had to put 
in a moderation rule for something - both triggered by the same source. Here’s 
hoping we don’t need any more in future!

Thanks, as always, for your participation on mailop.

Regards

Graeme, Patrick & Simon
mailop.org admin team
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Graeme Fowler via mailop]

On 4 Feb 2021, at 15:26, Benoît Panizzon via mailop  wrote:
> But I also think EXIM is screwing up the order of the received messages
> in pipelining mode.

Please open a bug at https://bugs.exim.org/ and/or subscribe to the Exim Dev 
mailing list at  https://lists.exim.org/mailman/listinfo/exim-dev to talk about 
it with the dev group. As much debug info as possible will help, perhaps 
self-evidently, but it’s not always forthcoming...

Speaking purely personally, I am unaware of any previously raised issues of 
this type with pipelining. There have been others though.

Graeme
(mostly non-coding Exim person on top of mailop gubbins)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamcop

[Graeme Fowler via mailop]

On 31 Jan 2021, at 10:24, Marc Bradshaw via mailop  wrote:
> Is there anyone from Spamcop on the list?
> 
> We are seeing some strange results right how, which suggest a domain renewal 
> may have gone awry for the RBL domain.

Confirmed, registration has gone into "Domain Status: autoRenewPeriod" state 
and nameservers are Enom's defaults.

Updated Date: 2021-01-31T09:40:42.00Z
Registrar Registration Expiration Date: 2021-01-30T05:00:00.00Z
Domain Status: clientTransferProhibited 
https://www.icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://www.icann.org/epp#autoRenewPeriod

I've seen a couple of rejections of outbound email from work, but nothing more. 
Yet.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Graeme Fowler via mailop]

[Admin note]

Unless you are a representative of UCEPROTECT, or you have something to 
actually add to the discussion rather than endlessly nitting on statistics etc, 
please refrain from continuing this thread.

Over the years we've all seen many threads on many mailing lists of the form 
"$dnsbl_operator has practices I don't agree with and they've listed me". I can 
think of no threads that resulted in a change of operational policy on behalf 
of $dnsbl_operator.

As mentioned up thread, many messages ago, using UCEPROTECT Level 3 to block 
outright is (to quote):

> recommended only if you are a HARDLINER and you want to cause service 
> providers
> and carriers that have spammer / abusive clients to be quickly and 
> effectively blocked
> and it does not matter to you if regular email is also occasionally rejected.
   ^

Ethics aside, they are *very* clear about their policies in all regards.

You may now resume normal service.

Graeme (not in any way involved in, related to, knowing of or in fact a user of 
the aforementioned DNSBL provider)

[/Admin note]
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Weird 'tempfail too many recipients' bug/incompatibility EXIM => Postfix?

[Graeme Fowler via mailop]

On 19 Jan 2021, at 08:13, Benoit Panizzon via mailop  wrote:
> When it comes to the first recipient being tempfailed, in the postfix
> logs, I see that recipient being rejected, but at the same time the
> EXIM log show a 200 OK message for that same recipient.

Given that Exim logs what the far end gives back to it, I suspect you're 
looking at the Postfix end.

I'm not aware of any specific bugs in either piece of software that would do 
that, though, so perhaps it's a configuration issue - is the rejection 
happening one step further on in the RCPT loop?

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailanswers to rC3 users behind outlook-com.olc.protection.outlook.com get blocked

[Graeme Fowler via mailop]

On 24 Dec 2020, at 15:22, Markus Krieger via mailop  wrote:
> i'm writing on behalf of the rC3 infodesk of this years Chaos
> Comminication Congress.

Welcome to the list.



> Has someone on the list a contact at Microsoft / outlook.com to
> whitelist the following IPs/Domains?

Before anyone else chimes in (and I’m not an emplyee or representative of MS, 
but I’ve been on this list long enough to see this be asked over an over 
again): have you followed the link in the error message, which takes you to a 
page containing this link?

http://go.microsoft.com/fwlink/?LinkID=614866

You *must* raise a ticket. You’ll get no traction without one. And when the 
inevitable response is “not eligibile for mitigation”, you need to reply to 
escalate the issue.

Regards

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Looking for possible mailing list hosting

[Graeme Fowler via mailop]

On 16 Dec 2020, at 20:24, Dave Ely via mailop  wrote:
> I’m not sure who can help me out with this, but my husband has a folder of 
> emails that come from a mailing list.

Dealt with off-list.

Graeme (obo mods)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Looking for possible mailing list hosting

[Graeme Fowler via mailop]

Admin note follows:

Dave originally asked a very specific question, about mailing list hosting. Not 
forums, or IRC, or any other collaboration tools.

Please provide specific and relevant answers, and let’s not make *this mailing 
list* disintegrate into a religious discussion about the whys and wherefores of 
a bazillion different ways of doing things.

Thanks

Graeme (obo moderators)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Graeme Fowler via mailop]

On 8 Dec 2020, at 10:38, Graeme Fowler via mailop  wrote:
> Grant said, paraphrased

> If you decide otherwise, Rafa

Apologies for the mixed use of forename and surname; that was absolutely not 
intentional. Thanks to those who pointed that out privately.

Graeme (who needs to sleep for a long, long time)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Graeme Fowler via mailop]

On 8 Dec 2020, at 10:27, Jaroslaw Rafa via mailop  wrote:
> Dnia  7.12.2020 o godz. 18:02:08 Grant Taylor via mailop pisze:
>> you send me email from an unapproved IP and you have asked me to
>> reject unapproved emails via -all, them I'm going to reject your
>> email flat out.  After all, that's what /you/ as the domain owner /
>> administrator /asked/ me to do.
>> 
>> My personal option is that being soft and not rejecting on -all is
>> nothing short of coddling people that seemingly don't know how to
>> administer their email infrastructure.
> 
> The SPF RFC explicitly says:
> 
> "A "fail" result is an explicit statement that the client is not
> authorized to use the domain in the given identity. Disposition of
> SPF fail messages is a matter of local policy."
> 
> So no, it's not the sender who has the authoritative voice on what should be
> done with messages that fail SPF check, it's the recipient. Of course, *you*
> may decide what you say above, ie. that you reject such messages. But it's
> *your local policy*. Do not claim that it's a sender decision, because that
> claim is simply false. The RFC puts the responsibility *on you*.

You are both in violent agreement.

Grant said, paraphrased, that "the domain owner has asked me to do this" and is 
therefore _making a policy decision_ based on that guidance which is coming 
from the SPF record.

If you decide otherwise, Rafa, that's also your policy decision but you're 
going against the explicit guidance of the domain whose SPF record you've 
looked up.

The domain "owner" has stated something via a lookup system that practically 
anyone in the world can query. What we as receivers can't intuit is whether the 
"-all" was intentional, whether they knew what it meant, whether is was 
accidental or someone's playing a joke on the domain owner; we can only go off 
what it states. If it says "reject email from everywhere (except here)", then 
why wouldn't you?

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] JSON mail server logs ?

[Graeme Fowler via mailop]

On 20 Nov 2020, at 09:27, Peter N. M. Hansteen via mailop  
wrote:
> I would suggest looking at what happens in elasticsearch-land for this.

On 20 Nov 2020, at 10:31, Suresh Ramasubramanian via mailop  
wrote:
> Been around for at least 4 years now.
> https://blog.cadena-it.com/monitor-backup/exim-logstash-elasticsearch-kibana/

Crikey. It's an awful long time since I wrote the underlying links in that 
article.

Yes, I wrote the pattern matches for what became the Exim bits in logstash way 
back in 2014 and it got pulled into logstash-patterns-core in 2015.

As we moved away from ELK to Splunk some time later I haven't done any further 
enhancements.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] opendkim bad signature data from mx.mailop.org

[Graeme Fowler via mailop]

On 6 Nov 2020, at 17:14, SM via mailop  wrote:
> The message body is modified as it goes through the list.

Hrm. Something for us to look at over the weekend - we should be signing the 
email with the list’s DKIM config, rather than necessarily passing the original 
signature unaltered.

Obviously, messages get a footer attached (so body modified) and the various 
sender/recipient headers get modified, too.

Graeme (obo mods)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Problems reaching uwo.ca

[Graeme Fowler via mailop]

On 19 Oct 2020, at 12:18, Graeme Fowler via mailop  wrote:
> Just seeing if anyone else is experiencing an issue we're having ("we" being 
> Loughborough University), or if it is indeed Just Us [tm]. If anyone from or 
> related to uwo.ca is on the list, so much the better.

Not yet resolved but a contact withing UWO has advised they're having network 
problems with their connection to their local NREN.

Ta for the off-list responses.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Problems reaching uwo.ca

[Graeme Fowler via mailop]

Hi all

(cross-posted so apologies if you get this more than once)

Just seeing if anyone else is experiencing an issue we're having ("we" being 
Loughborough University), or if it is indeed Just Us [tm]. If anyone from or 
related to uwo.ca is on the list, so much the better.

We've had reports this morning of us rejecting emails from uwo.ca, and we have 
emails to uwo.ca stuck in the outbound queue. Inbound rejections are because we 
can't resolve the inbound MAIL FROM domain - lookups time out.

It seems we are unable to make any DNS queries against their IPv4 nameserver 
addresses. We can against their IPv6 nameserver addresses but there's no IPv6 
glue in their delegation from the .ca nameservers, we need to use v4 - and 
can't.

It also looks like we can't talk to the MX server farm on port 25 either.

So... is it a routing problem, or have we upset uwo.ca for some reason?

Regards

Graeme


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How to reply to this list?

[Graeme Fowler via mailop]

On 16 Oct 2020, at 13:51, Larry Struckmeyer via mailop  
wrote:
> Using Outlook thru O365 attempts to reply to a message in this list result in 
> the reply being addressed to the address of the person being replied to and 
> not the list. 
>  
> What is the correct way to reply to a message on this list?

Mailman munges the From: on emails from senders with a restrictive DMARC or SPF 
policy (using the from_is_list setting).

Basically, if you post from a domain with a restrictive sender policy, the 
original From: is set to the mailing list and the original sender address is 
placed in Reply-To:

To reply to the list, use “reply all” and if you like, move the mailing list 
address from Cc: to To:.

Graeme

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] 0Spam down

[Graeme Fowler via mailop]

On 9 Oct 2020, at 09:22, Hetzner Blacklist via mailop  wrote:
> It's just surprising the website is down (as 0spam.fusionzero.com
> forwards to 0spam.org).

It's working for me (on AS786).

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [ADMIN] List migration complete

[Graeme Fowler via mailop]

Hi all

On 29 Sep 2020, at 17:06, Al Iverson  wrote:
> The message has appeared! Thank you kindly for keeping the list up and 
> running!

Thanks :)

Predictably we have had/are having some teething troubles which those of you 
wearing deliverabiity hats will be very familiar with - a couple of DNSBLs had 
the IPv4 address listed as ‘DUL’, which it isn’t, and they’ve changed that 
(thanks to both of them for responding so quickly); we’ve got a couple of 
quirks relating to DANE which Patrick is looking into; and Google’s 
random-source-address retry mechanism is falling foul of postscreen, causing 
messages to be delayed on the way in.

Notably Microsoft’s response to email from the new list IP was an outright 
block with a link to follow in the SMTP response, which we did, and the address 
was delisted immediately. It pays to watch your logs, folks!

Please bear with us while we work through these wrinkles.

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] [ADMIN] List migration complete

[Graeme Fowler via mailop]

Hi all

FYI we have, finally, completed the mailing list migration to a new VM.

Firstly: many, many thanks to Andy Davidson for administering & hosting the 
list on his own kit for all the years it's been running. First message sent to 
the list was from Andy, way back in 2007!

The admin/moderation team is now (in alphabetical order):

Andy Davidson
Graeme Fowler
Patrick Ben Koetter
Simon Lyall

We can be contacted via postmaster _at_ mailop.org should any issues arise 
after the migration, particularly with respect to anything TLS shaped.

The list is now kindly hosted on a VM provided free of charge by netcup - 
https://netcup.eu - many thanks to them for their support.

Please note that the list's DNS zone is signed as per Patrick's email dated 
27/09/2020 21:16:48 UTC. There is more information there with regards to 
STARTTL/DANE, plus mention of DKIM, DMARC and ARC which are planned for the 
future.

Assuming that this message appears, we're in business!

Regards

Graeme
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] What's Microsoft's S3150 block list and where do I go to request removal?

[Graeme Fowler via mailop]

On 9 Sep 2020, at 19:11, Jaroslaw Rafa via mailop  wrote:
> Yes, they do.
> And especially on this list you should expect that.

And especially on this list you should expect that people will compose and read 
emails in all sorts of different ways, which you may have to adjust for in both 
senses.

Fixed that for you.

Graeme


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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Graeme Fowler via mailop]

On 27 Aug 2020, at 16:53, Tim Bray via mailop  wrote:
> Why t-mobile want to white list, I don't know.  But you can be sure they 
> don't get random spam from random compromised home broadband or cloud servers.

...until someone registers an IP with them, then $time passes and they 
terminate service or relocate to another provider and that IP address gets 
recycled onto a different, less technically able customer who's just been given 
a free pass into Deutche Telekom's mail system.

Or, nothiswouldneverhappenwouldit, a spammer/scammer sets up a perfectly 
legitimate company with a registered office and everything, gets allowed in, 
and then changes modus operandi. Rinse, repeat.

As many parties have said, the approach taken here simply doesn't scale in so 
many ways.

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

Re: [mailop] firebasestorage.googleapis.com any legitimate uses?

[Graeme Fowler via mailop]

On 27 Aug 2020, at 13:46, micah anderson via mailop  wrote:
> Benoit Panizzon via mailop  writes:
> 
>> In the last couple of days we face an increasing amount of phishing
>> sites hosted @ firebasestorage.googleapis.com targeting our customers.
> 
> We have been hit by the same, although strangely it has not been
> happening so much recently.

At $workplace we ended up putting a SpamAssassin rule for these, and hang the 
false positives (we've had two reported). I know we're rejecting some marketing 
email (Jet2 Holidays being one example).

The sheer number of messages mentioning the firebase storage API in URLs in the 
message - whether clicky-linky, or others like embedded images has been fairly 
astonishing.

There was another cloud storage widget being used in phish that reared up this 
morning but I can't remember what it was. It seems that it's "tactic du jour".

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

Re: [mailop] Extreme multiple posting (was Re: OVH Bulk Mailer? Anyone know this one?)

[Graeme Fowler via mailop]

On 8 Aug 2020, at 13:21, Ted Cooper via mailop  wrote:
> I received the message 43 times over a period of 21 hours starting at
> 2020-08-05 14:04:23 UTC.

There was a problem with the host the list lives on. When I realised, I poked 
Andy and he fixed it.

Apologies.

Graeme
___
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] t-online.de outage?

[Graeme Fowler via mailop]

On 10 Jun 2020, at 10:20, Hetzner Blacklist via mailop  
wrote:
> As far as I know this isn't a bug, it's a feature.

Joy.

> For the past few years, T-Online have been moving to a system where they
> block all unknown IPs. How exactly they define that is not 100% clear,
> but it seems to be any IPs that haven't recently sent them email.
> 
> So if an IP hasn't sent them email in the recent past, it is
> automatically on their blacklist. By default.

I thought I'd do a check on this assertion and it does appear to be accurate.

$workplace outbound servers get a 220. Amusingly (or perhaps not) the new 
mailop server, which we haven't switched in yet, gets the same 554 as everyone 
else.

That strikes me very much as a "does not scale well" approach.

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

Re: [mailop] Microsoft Outlook "Modern Authentication"?

[Graeme Fowler via mailop]

On 5 Jun 2020, at 05:26, Daniele Nicolodi via mailop  wrote:
> I don't see the gain as the same attacks are possible over a different
> protocol. I don't think that eliminating IMAP (and keeping SMTP
> submission as far as I know) reduces the attack surface. Am I missing
> something?

Very much so.

For malware families like Emotet and friends, one of the attack vectors is to 
hoover up emails from mailboxes then use those as implant methods by 'replying' 
to them with malware droppers attached. In UK HE we've also seen some similar 
methods utilised in attacks designed to con browsers into giving up the access 
token they're currently using, so actually making use of moden auth techniques!

Modern auth on IMAP and SMTP stops that pretty well dead, as does turning off 
authenticated SMTP (stopping the injection of content for outbound submission) 
and/or IMAP (for hoovering up the content in the first place).

It's a very long game though, this one.

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

Re: [mailop] Force double opt in for marketing list companies per email address

[Graeme Fowler via mailop]

On 2 Jun 2020, at 21:52, Oreva Akpolo via mailop  wrote:
> 
> I'm Oreva, a Deliverability Engineer at Mailchimp. There currently isn't a 
> system to force double opt-in on recipients per email address. What we can 
> recommend is to set up filters or folders, so that you're only seeing mail 
> from users you've actively subscribed to in your inbox. 

Is this where we say “Oh, mate”?

The average email recipient can’t spell scalability, and they sure as hell 
don’t understand it. What they sometimes understand is “why is all this crap I 
never subscribed to in my Inbox?”.

Are you really suggesting, as a representative of MailChimp, that you expect 
recipients to manage unwieldy and ever-growing allow- and deny-lists?

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

Re: [mailop] ADMIN: Mailop in 2020

[Graeme Fowler via mailop]

Hi all

Just a quick update: we haven’t forgotten about mailop and moving the list, but 
we *have* all been caught up in the maelstrom of work caused by the Coronavirus 
pandemic - to give one perspective, at work we took a University of 18000+ 
taught students and sevral thousand teaching, research, professional services 
and support staff from the previous “normal” state to completely online working 
in just shy of a week.

We will get to move the list, and sort out certificates etc, in due course.

Hope everyone’s bearing up, doing the right things, and staying healthy. It’s a 
strange time to be alive.

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

Re: [mailop] Abusix Potentially Compromised Account Report

[Graeme Fowler via mailop]

On 24 Mar 2020, at 16:52, Michael Peddemors via mailop  
wrote:
> Like others on the list pointed out, if you send 'noise' then people will 
> simply 'tune out' to your reports. While I commend you for looking at ways to 
> help address the problem, you might want to have a smaller set of more 
> accurate reports, and then widen it bit by bit, rather than the other way 
> around.

If I might add an extra bit of weight to the "noise" point: albeit operating at 
a vastly smaller scale than many here, the Abuseix report we got at $workplace 
tied up a member of the security team, 3 members of staff (whose accounts had 
not and never have been compromised but were incovenienced nonetheless) and 
colleagues on the service desk for an appreciable amount of time yesterday.

This at a point where world events dictate that we simply don't have that time, 
*especially* our first line guys.

I'm still not quite sure I understand the methodology myself.

Graeme (wearing work hat)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] List archive TLS cert expired

[Graeme Fowler via mailop]

On 24 Mar 2020, at 16:48, Mark E. Jeftovic via mailop  wrote:
> PSA: SSL for list archive site has expired

Not the first time; hoepfully the last.

We are, albeit slowly, moving onto a new platform but world and personal events 
have thrown a large spanner in the time available to deal with it.

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

Re: [mailop] Suggestions for mailops.org website - forum?

[Graeme Fowler via mailop]

On 17 Feb 2020, at 19:03, Scott Mutter via mailop  wrote:
> Regarding the suggestion for "content/questions/answers/links to put on the 
> website" - have you ever considered making this mailing list into a forum?

If we as a community can’t make use of a mailing list to sort out 
interoperability problems, then as a community we have failed :)

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

Re: [mailop] ADMIN: Mailop in 2020

[Graeme Fowler via mailop]

On 12 Feb 2020, at 16:39, I wrote:
> Step 2 is about to happen: I’m about to change the registered nameservers for 
> the domain.

When I wrote "about to happen" I did not factor in some really strange 
behaviour from OpenSRS, which we've now managed to get round.

The domain's nameservers have now been changed, and we'll be making some other 
changes as time allows over the next few days. The first and most significant 
change is that the domain's zone will be fully DNSSEC enabled.

The MX record and the mailing list itself remain on AndyD's server at this 
time, we'll let you all know when we're intending to cutover to a new platform.

Tata for now

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

Re: [mailop] ADMIN: Mailop in 2020

[Graeme Fowler via mailop]

On 8 Feb 2020, at 21:45, Simon Lyall via mailop  wrote:
> Cutover is probably still a few weeks away.

Step 1 has already happened: Andy Davidson, who originally registered the 
domain and has until now provided all the infrastructure for the domain and 
list, has handed the domain over to me. I think big thanks and a round of 
applause are due to Andy from us all for the years of providing the service to 
us all. Cheers, Andy!

Step 2 is about to happen: I’m about to change the registered nameservers for 
the domain. There should be no discernable effect in terms of mail flow or 
where to currently go to e.g. visit the archives/manage your subscription, but 
we’ll be able to bring up a new website in advance of moving the list itself.

**NOTE** although there’s been some decent planning here, things should not go 
wrong, but there’s always that chance…

See you on the other side!

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

Re: [mailop] Junk filtering as a tool for unfair competition

[Graeme Fowler via mailop]

On 24 Oct 2019, at 11:15, Jaroslaw Rafa via mailop  wrote:
> The goal of spam filtering is - in my opinion - filter the majority of spam
> messages, so that they don't clutter the user's mailbox and don't prevent
> him/her from normally using e-mail. If one or two (or even five) spam
> messages go through, it's not a tragedy - the user can delete them manually.

I'd love to have your user base. 1 or 2 potential junk/spam/phish messages in 
inboxes across ours makes for multiple calls to our service desk that the "spam 
filter has failed". It's like the delete key doesn't exist (or has been mapped 
to a "raise a ticket" routine).

> On the other hand, if one or two "legitimate" messages (for "legitimate",
> consider here "messages that recipient wants or at least may want") end up
> in the spam folder, which means they will never be read by an average user,
> is a much more serious issue.

I'll come back to this point below.

> If someone is stupid enough to fall for a phishing message, they should be
> educated. It should start from schools; it should take place in companies
> etc. People should be constantly taught how to recognize phishing and not
> fall for it. Why do we teach people how to safely cross the street, but we
> don't teach them how to safely use the Internet?

People still get run over crossing the road; they still cross the road in 
stupid places, when they're not concentrating, when they're in a rush, when 
they're not feeling very well... the list goes on. People aren't "stupid" per 
se, they are - as you state - human, and humans make mistakes. No amount of 
education will prevent humans making mistakes or being distracted. I'm not 
saying don't educate, but as someone who is regularly involved awareness 
campaigns about IT security I am acutely aware of the fine line between too 
much and too little. Too little? Users get scammed. Too much? They report. 
Every. Single. Unwanted. Message (even the ones that are "legitimate").

Additionally (from above), if you think education is the key, why not educate 
your users to check the junk folder? It would be "stupid" to not check it if it 
exists (your term). Our users are taught to do just this, a side-effect of 
which is week-old emails that were put in the Junk folder get reported as - you 
guessed it - Junk.

Humans are fallible. Computers programmed by humans inherit the same 
fallibility, despite our ongoing attempts to either teach them to not be or 
make them teach themselves. They inherit the same biases from us, but what they 
can do is the same task at mega-scale that we can do at an individual level, 
and they can do it much more quickly. And they never get tired. This does mean 
they can make mistakes at a stupendous rate too, though, which brings us to...

> Don't try to be too perfect at spam filtering. Just be good enough. That's
> enough :).

There's the issue. Your "good enough" isn't a global setting - so we're back to 
"their network, their rules" all over again.

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

Re: [mailop] www.openspf.net down

[Graeme Fowler via mailop]

On 20 Oct 2019, at 05:32, Brandon Applegate via mailop  
wrote:
> I suppose it’s not “service impacting” per-say, but it does play a part in 
> reading out SPF failures for example.
> 
> Anyone know the folks that run it - maybe reach out to them in case they 
> aren’t aware ?

See the discussion on this list from May 2019, starting with Message-ID: 


TL;DR: it died and has not been resurrected, excepting a static copy built from 
the Wayback Machine here:

http://www.open-spf.org/

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

Re: [mailop] Gmail marking email from me as spam

[Graeme Fowler via mailop]

On 14 Oct 2019, at 14:58, Nick via mailop  wrote:
>> If a large percentage of them have a signal which is 'poor' (FSVO
>> 'poor') then the inference is that the whole block is poisonous, and
>> you bin it (or put mail from it in the junk folder).
> 
> It is not an inference.  You agreed ("Does that really happen?" "No")
> that legitimate senders remain in the block.  The whole block is not
> poisonous.

*shrug*

If the majority of a netblock smells bad, it is easier to deal with it as a bad 
smell rather than make exceptions for lovely fragrances within.

> My question remains unanswered.  Why not treat each ip address on its
> own merits?  Is it technically infeasible, too expensive, less
> convenient, or what?

Definitely less convenient. In my case, I treat individual addresses, 
netblocks, email addresses, domains both as separate entities *and* together. 
Sometimes the signal for an individual IP address is vastly outweighed by the 
noise of the surrounding netblock. Sometimes it's the other way around (rarely, 
in my experience). Occasionally an individual IP address will look perfectly 
shiny and be in a great neighbourhood, but then starts sending phishing emails 
(just one example of many) and will end up with a poor local reputation. If it 
happens to be in a farm of related hosts for a given sending domain, that puts 
them all on notice.

I refer back to my first email in this thread:

"Their network; their rules".

Each and every operator does things slightly differently, based on the 
available data and the previous experience of said operator. Scale influences 
both of those things.

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

Re: [mailop] Gmail marking email from me as spam

[Graeme Fowler via mailop]

On 14 Oct 2019, at 14:30, Nick via mailop  wrote:
> If an ip address in the range is held by a legitimate mailer, you're
> saying the legitimate mailer will be evicted to make way for the
> spammer?  Does that really happen?

No; but if you don't get any email from the 'legitimate' sender then your only 
signal is that from the neighbours. If a large percentage of them have a signal 
which is 'poor' (FSVO 'poor') then the inference is that the whole block is 
poisonous, and you bin it (or put mail from it in the junk folder).

For 'small' operations, the visibility of the entire block is likely to be 
missing chunks. At Google's scale, they can see the entire operator as a single 
entity and make decisions based on that.

Even we (at $workplace) have automation in place which responds to netblocks 
which go rogue and spew junk/invalid RCPT and so on, and we're a drop in the 
ocean compared to the 500lb gorillas like Google.

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