Re: [mailop] eu tld have one ipv6 addr not listen to udp

2024-05-07 Thread Carsten Schiefner via mailop

Benny -

On 07.05.2024 20:12, Benny Pedersen via mailop wrote:
eu zone: The server(s) were not responsive to queries over UDP. 
(2001:978:2:1::93:2)


why is it not resolved ?


I fail to see any mail ops related issue with this.

Or don't I and there simply isn't any?

Best,

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


Re: [mailop] Off-Topic - VMWare ESXI 7.0

2024-04-16 Thread Carsten Schiefner via mailop

On 16.04.2024 16:06, Kevin A. McGrail via mailop wrote:
As the original poster, I wanted to say thanks.  Based on the dozen or 
so replies so far, I clearly struck a nerve.  I'm reading all the 
replies with great interest.


Even without having any of your current itches, Kevin, I am having a 
close eye on this particular thread and will certainly keep it for 
further reference.


Thanks, folks, for all your contributions, assessments etc. - truly 
appreciated!


Best,

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


Re: [mailop] Hotmail complains about their own mail

2023-12-16 Thread Carsten Schiefner via mailop
Hi Thomas,

> Am 16.12.2023 um 10:34 schrieb Thomas Walter via mailop :
> 
> Hey guys,
> 
> this was new:
> 
> 1. Hotmail user sends delivery service phishing email.
> 2. Our server bounces with 550 5.1.1 User doesn't exist.
> 3. User marks non-delivery mail as Junk?
> 4. Hotmail sends complaint about the bounce message to our abuse.
> 
> I'm not sure how to react to that.

given this organization’s ongoingly here debated track record of non-reaction, 
how about:

OM Chanting @ 432 Hz https://youtu.be/SBiwLibZqfw

- these three hours should help numbing the mental pain sufficiently.

> Would it be possible for Microsoft to not send complaints if the offending 
> mail is a bounce message?

Theoretically: probably yes.
Practically: highly likely no.

On a second and less sarcastic glance: Did the bounce still contain portions of 
the original delivery service phish? If so, then actually this might have 
triggered their processing it as Spam. Of course, bounce mails should not get 
this treatment, regardless their payload.

Best,

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


Re: [mailop] Microsoft rejecting their own headers

2023-12-15 Thread Carsten Schiefner via mailop
Maybe they have just started eating their own dog food V2.0 at MS? ;->

SCNR.

Best,

-C.

> Am 15.12.2023 um 11:37 schrieb Laurent S. via mailop :
> 
> It seems Microsoft made very recently a change. Since then, we get a 
> whole bunch of reject with this message:
> 
>> 554 5.6.211 Invalid MIME Content: Single text value size (32820) 
> exceeded allowed maximum (32768) for the 
> 'X-Microsoft-Antispam-Message-Info-Original' header.
> 
> The company I work for does some e-mail handling where our clients would 
> keep their MX at microsoft and route some inbound mails through our 
> infra by connectors.
> 
> What is stupid is that the header that causes the reject upon reinject 
> is written BY THEM! How about not writing such crazily long report on a 
> single header?
> 
> We are now implementing a reject on the same header length for this 
> service, but I suppose our customer will realize soon that they are 
> missing some mails and will, as usual, put the blame on us instead of 
> microsoft.
> 
> Regards,
> Laurent
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] 451-Reject due to policy restrictions from web.de and gmx.de

2023-12-14 Thread Carsten Schiefner via mailop
Morning, Andreas & all -

I can't confirm this: the sending server hasn't DKIM yet deployed, but a test 
email to my gmx.net account nonetheless went through fine.

Best,

-C.

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Andreas via mailop 
To: mailop@mailop.org
Sent: Mi., 13 Dez. 2023 22:30
Subject: [mailop] 451-Reject due to policy restrictions from web.de and gmx.de

Hello all,

do any of you who do not live in Germany have this error message from 
GMX and WEB.DE? Or is this an educational measure for German providers only?

451-Requested action aborted\n451-Reject due to policy 
restrictions.\n451 For explanation visit https://postmaster.gmx.net/de/
https://postmaster.gmx.net/en/case?c=r0103

Hundreds of domains go through our servers, should we now explain to 
every customer that if they, as German citizens, want to send an e-mail 
to other German citizens, especially if they live with Web or GMX.de, 
they must first populate their domains with DKIM entries? Cool thing, 
especially so close to Christmas.

Kind regards
Andreas

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


Re: [mailop] Bounces

2023-11-16 Thread Carsten Schiefner via mailop
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.

Best,

-C.

> Am 16.11.2023 um 15:43 schrieb Michael via mailop :
> 
> Always terrible when big ESP's simply say 'Remove Us' and think it will 
> happen because they are big, instead of 'asking' why you are being flagged, 
> and what can you do to improve your reputation..
> 
> Especially as a 'Financial Services' related business, the onus is on you to 
> ensure that you are at the top of your game, and have clear transparency..
> 
> And on this list, you better be willing to share exactly what email/domain/ip 
> is having the problem, if you want the community to help you out..
> 
>> On 11/16/23 03:46, Polath, Kiran via mailop wrote:
>> Hello Team,
>> We at Broadridge Financial Solutions sends millions of email as financial 
>> customer communication on behalf of our clients .We see our emails are 
>> frequently getting blocked by charter.net 
>> 
>>  & rr.com, this is impacting our reputation . Can you take it as high 
>> priority and remediate this as it is very important to our customers to have 
>> this resolved. please find the below reasons
>> 550 5.1.0 ...@ ... sender rejected. Please see 
>> https://www.spectrum.net/support/internet/{hash}-{hash} 
>> for more 
>> information. AUP#In-1310
>>
>> 2023-11-15 02:52:11 EST
>>
>> charter.net
>> 550 5.1.0 ...@ ... sender rejected. Please see 
>> https://www.spectrum.net/support/internet/{hash}-{hash} 
>> for more 
>> information. AUP#In-1310
>>
>> 2023-11-15 02:52:11 EST
>>
>> wi.rr.com
>> 550 5.1.0 ...@ ... sender rejected. Please see 
>> https://www.spectrum.net/support/internet/{hash}-{hash} 
>> for more 
>> information. AUP#In-1310
>>
>> 2023-11-15 02:52:11 EST
>>
>> charter.net
>> 550 5.1.0 ...@ ... sender rejected. Please see 
>> https://www.spectrum.net/support/internet/{hash}-{hash} 
>> for more 
>> information. AUP#In-1310
>>
>> 2023-11-15 02:52:10 EST
>>
>> wi.rr.com
>> 550 5.1.0 ...@ ... sender rejected. Please see 
>> https://www.spectrum.net/support/internet/{hash}-{hash} 
>> for more 
>> information. AUP#In-1310
>>
>> 2023-11-15 02:52:10 EST
>>
>> wi.rr.com
>> Regards,
>> *Kiran Kumar Polath*| ICS-Email Operations | Broadridge Financial Solutions 
>> (India) Private Limited
>> Adjacent to Cyber Towers, Hi-Tech City, Madhapur | Hyderabad 500081 
>> Telangana | India | m +91 8008297767| m +91 9154044691
>> 
>> broadridge.com __
>> This message and any attachments are intended only for the use of the 
>> addressee and may contain information that is privileged and confidential. 
>> If the reader of the message is not the intended recipient or an authorized 
>> representative of the intended recipient, you are hereby notified that any 
>> dissemination of this communication is strictly prohibited. If you have 
>> received this communication in error, please notify us immediately by e-mail 
>> and delete the message and any attachments from your system.
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
> 
> -- 
> "Catch the Magic of Linux..."
> 
> Michael Peddemors, President/CEO LinuxMagic Inc.
> Visit us at http://www.linuxmagic.com @linuxmagic
> 
> A Wizard IT Company - For More Info http://www.wizard.ca
> "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
> 
> 604-682-0300 Beautiful British Columbia, Canada
> ___
> mailop mailing list
> mailop@mailop.org
> 

Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook

2023-11-11 Thread Carsten Schiefner via mailop
Hi Andrew,

> Am 11.11.2023 um 14:25 schrieb Andrew C Aitchison via mailop 
> :
> 
> […]
> 
> I guess we need to look at ClientID
> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ (SMTP)
> https://datatracker.ietf.org/doc/draft-yu-imap-client-id/ (IMAP)
> and OAuthBearer RFC7628
> to see whether either or both could help us identify the incoming
> client sessions ?

thanks - that’s interesting.

Would you happen to know of any prototype implementation of either one of these 
two drafts?

Thanks & best,

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


[mailop] Probably OT: privacy respecting mail app for Android

2023-11-11 Thread Carsten Schiefner via mailop
All -

> Am 11.11.2023 um 12:43 schrieb Bjoern Franke via mailop :
> 
> […]
> 
> This seems to be not restricted to iOS apps. Recently I tried "Blue Mail" on 
> Android and after logging in a contabo box connected to my IMAP server. Even 
> after uninstalling the app, the connection stayed, so I changed the 
> credentials.

there is:

FairEmail - Fully featured, privacy oriented email app
https://email.faircode.eu/

available for Android.

According to an *EXTREMELY* privacy concerned colleague of mine this is the 
only app meeting his concerns in this regard.

He runs it on GrapheneOS, an Android clone designed with a strict focus set on 
privacy aspects.

Disclaimer: I am by no means whatsoever affiliated with the organisations or 
the people behind FairEmail or GrapheneOS. Or the projects themselves.

Best,

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


Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook

2023-11-10 Thread Carsten Schiefner via mailop

Interesting, Louis - ...

On 10.11.2023 20:30, Louis Laureys via mailop wrote:
The fact that it transfers all of your messages is new (to me), the 
whole transferring of credentials has been the standard for almost all 
mobile email clients as on ios you can't keep an imap connection open 
for instant notifications. On android you can, but only after hunting 
for all the battery saving settings and turning them off for the app. So 
your credentials will be sent to the server, so it can use the 
platforms' notification channel instead. I think I've ever seen an app 
warn me that they will be storing my credentials in their cloud, but 
they do.


... I have not been aware of the fact that *ALL* apps actually might be 
doing this.


It was just recently that I looked for alternative iOS mail apps - and 
"phoning home" credentials got noted only for the Spark app.


Thanks & best,

-C.

Op vrijdag 10 november 2023 om 16:54, schreef Carsten Schiefner via 
mailop :


Folks,

sort of triggered by Benoit's recent and absolutely spot-hitting
rant about Microsoft's inability resp. unwillingness to
appropriately deal with spam complaints, I thought I should share
this article:

Microsoft lays hands on login data: Beware of the new Outlook

https://www.heise.de/news/Microsoft-lays-hands-on-login-data-Beware-of-the-new-Outlook-9358925.html
 
<https://www.heise.de/news/Microsoft-lays-hands-on-login-data-Beware-of-the-new-Outlook-9358925.html>

with you.

Although it is not strictly related to email service providers'
operations, I wonder about the unintended resp. unwanted side
effects wrt. email operations it could have that you have to
involuntarily hand off your credentials to a third party.

So, your account got hacked and you happen to use such an Outlook
version: where was the leak? On your end? Or on Microsoft's?

Opinions?

Best,

-C.
___
mailop mailing list
mailop@mailop.org <mailto:mailop@mailop.org>
https://list.mailop.org/listinfo/mailop
<https://list.mailop.org/listinfo/mailop>

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


Re: [mailop] Microsoft lays hands on login data: Beware of the new Outlook

2023-11-10 Thread Carsten Schiefner via mailop

Hi Andrea & all -

On 10.11.2023 18:08, Andrew C Aitchison via mailop wrote:

Microsoft lays hands on login data: Beware of the new Outlook
https://www.heise.de/news/Microsoft-lays-hands-on-login-data-Beware-of-the-new-Outlook-9358925.html
with you.

   ...  ...
So, your account got hacked and you happen to use such an Outlook 
version: where was the leak? On your end? Or on Microsoft's?


Opinions?


How much of this is new ?


It was to me at least - I have not yet been aware of this:


For over a decade you have had the option of downloading
your other email accounts into Gmail (via IMAP I think)
do that you could work on them in one place.
I believe it was reasonably obvious that this gave Gmail
your password etc. and whilst I told my users not to do it
(especially as this was also their local desktop login)
I don't think anybody panicked.


Gmail "feature".


Is this new Microsoft version significantly different ?


In the light of the above: probably not.

I have read that Spark, an email app for iOS, does a similar trick with 
IMAP credentials.


Then again, this is probably just a small issue as any third party email 
app for iOS is a niche product as the vast majority of users will use 
Apple's iOS Mail app as this comes on-board as the default.


Now, with Outlook... Oh, wait: what again comes as an on-board default 
on any MS Windows installation?


Best,

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


[mailop] Microsoft lays hands on login data: Beware of the new Outlook

2023-11-10 Thread Carsten Schiefner via mailop

Folks,

sort of triggered by Benoit's recent and absolutely spot-hitting rant 
about Microsoft's inability resp. unwillingness to appropriately deal 
with spam complaints, I thought I should share this article:


Microsoft lays hands on login data: Beware of the new Outlook
https://www.heise.de/news/Microsoft-lays-hands-on-login-data-Beware-of-the-new-Outlook-9358925.html

with you.

Although it is not strictly related to email service providers' 
operations, I wonder about the unintended resp. unwanted side effects 
wrt. email operations it could have that you have to involuntarily hand 
off your credentials to a third party.


So, your account got hacked and you happen to use such an Outlook 
version: where was the leak? On your end? Or on Microsoft's?


Opinions?

Best,

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


Re: [mailop] Zero-day RCE for exim - whacky stats?

2023-10-02 Thread Carsten Schiefner via mailop

On 30.09.2023 10:35, Carsten Schiefner via mailop wrote:

[...]

But would you happen to have any more details wrt. the withholding and 
the 50%?


[Link to https://seclists.org/oss-sec/2023/q3/254]

Thanks, Simon & Andrew!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Zero-day RCE for exim - whacky stats?

2023-09-30 Thread Carsten Schiefner via mailop

Hi Simon,

On 30.09.2023 10:18, Simon Arlott via mailop wrote:

On 30/09/2023 08:50, Andrew C Aitchison via mailop wrote:

I see that there is an Exim release candidate out on test at the moment
https://lists.exim.org/lurker/message/20230926.174111.cb403675.en.html
but know nothing about whether it fixes any of these vulnerabilities.


It doesn't fix the vulnerabilities. The fixes are being withheld until
the release of 4.97 and only cover the 50% of the reported
vulnerabilities (those that affect the SPA authenticator).


thanks - that clarifies it with a bit of a time perspective.

But would you happen to have any more details wrt. the withholding and 
the 50%?


Thanks & best,

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


Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

2023-08-25 Thread Carsten Schiefner via mailop

Hi David,

On 25.08.2023 13:54, David Conrad wrote:

Even if the RBC customer were in the EU, I think the challenge would be that he 
(safe guess given the email address chosen) wouldn’t know and/or be bothered to 
file a complaint. Whoever he is, he provided an email address years ago and 
hasn’t noticed he’s never received anything at that address (including 
statement notifications, low balance alerts, appointment reminders, etc.).  If 
RBC can be trusted (doubtful, but…), he also chose not to change it when he was 
informed it was wrong at the RBC branch he made an appointment to go to a year 
and a half ago. Now if I, as the impacted third party, could file a complaint… 
maybe some sort of UCE-related complaint?  Anyone know if Canada has laws like 
that?


what you have described is clearly an Information Security Incident. Period.

And it equally clearly affects PII. Period again.

The least RBC could - and SHOULD! - have done within a reasonable time 
frame after your initial report (to double-check on legitimacy, 
authenticy etc. of your claim) is to delete your email address from 
their customer's record.



Part of the annoyance is that at least some RBC staff are apparently aware they 
are sending email to the wrong email address yet there doesn’t appear to be a 
way to have that email address deleted from the customer's profile. I’m 
guessing it’s a systemic thing, perhaps the result of social engineering 
attacks. Still insane though…


That their customer doesn't seem to care and therefore does not attempt 
to rectify the wrong email address on his record at RBC's: that's an 
irritating shame, but somebody else's problem.


But that RBC has failed to delete *YOUR* email address (PII for sure 
according to GDPR) from a totally unrelated customer record for at least 
18 months now and after multiple attemps of yours to get this ironed 
out, makes *YOU* an affected individual, too. Certainly at least 
according to European GDPR.


I have filed an inquiry recently with a company I stopped having 
business with years ago, when they all of a sudden started to send me 
emails again. It was truly remarkable how quickly I received their 
apologies combined with a comprehensive explanation how this had 
happened and what they have done to prevent this from happening again.


Why? Because they knew and probably still know very well what otherwise 
might be at stake for them.


Best,

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


Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

2023-08-25 Thread Carsten Schiefner via mailop

David & all -

the EU's GDPR wrt. Information Security and PII Protection luckily hands 
a quite sharp sword to consumers: the fines for offenders are, well..., 
"fine".


If the real recipient of RBC's communication you are getting instead of 
her or him would be domiciled in EU territories (-> French overseas 
departments!) and would file a complaint with the appropriate DPA, RBC 
better sets aside a bit of money already. Even more so as they have been 
flagged multiple times already, in this instance by you, David.


Cheers,

-C.

On 25.08.2023 03:20, David Conrad via mailop wrote:
If the address isn’t a “no-reply@“, I generally do the same, but more 
and more I’m getting “this message is sent from an unmonitored email 
address, please do not reply”.


The worst so far is Royal Bank of Canada.  One of their customers used 
my gmail address and I’ve been getting all sorts of private information 
about them like low balance alerts with the exact amount in their bank 
account, etc.


I’ve tried contacting their security dept., their customer service 
dept., and even @rbc or equivalent in various social media (which I 
detest) saying “please, for the love of all gods, STOP.”  Once, via 
twitter, an RBC person gave me a number to call and through various 
hoops and literally _hours_ of sitting on hold, explaining the 
situation, jumping through stupid automated phone trees, etc., I finally 
spoke to a person who said they’d discuss it _with the customer_ during 
an appointment I knew the customer was having with them because I 
received the reminder notices.  That was about a year and a half ago.


Yet the email keeps coming.

It boggles my mind.

Regards,
-drc

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


Re: [mailop] Google Groups considered as spam by Gmail

2023-08-15 Thread Carsten Schiefner via mailop

On 15.08.2023 15:35, Mike Hillyer wrote:

Hey, I'm always happy when a MBP is so fair and even-handed that they will even 
subject their own mail to filtering.


Only that it should rather not be considered as spam.

And in fact, has not been until recently.

IIUC.


-Original Message-
From: mailop  On Behalf Of Carsten Schiefner via 
mailop
Sent: Tuesday, August 15, 2023 8:26 AM
To: mailop@mailop.org
Subject: Re: [mailop] Google Groups considered as spam by Gmail

On 15.08.2023 13:21, Bjoern Franke via mailop wrote:

I subscribed to some bigbluebutton related Google Groups some time ago.
In the beginning of June, something must have been changed at Gmail.
Every mail sent by these groups since then have been considered as
spam by Gmail - those mails had only technical content as before.


Google tastings its own dog food maybe? ;-> 
___
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 Groups considered as spam by Gmail

2023-08-15 Thread Carsten Schiefner via mailop

On 15.08.2023 13:21, Bjoern Franke via mailop wrote:
I subscribed to some bigbluebutton related Google Groups some time ago. 
In the beginning of June, something must have been changed at Gmail. 
Every mail sent by these groups since then have been considered as spam 
by Gmail - those mails had only technical content as before.


Google tastings its own dog food maybe? ;->
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


[mailop] Auto-forwarding emails as attachments

2023-07-13 Thread Carsten Schiefner via mailop

Hans-Martin & all -

On 13.07.2023 11:00, Hans-Martin Mosner via mailop wrote:
Has anyone on this list tried forwarding (e.g. for ex-employees) via 
attachment? The original message would be kept intact, while the outer 
message clearly originates with the forwarding agent who may even add 
a human readable reminder to the addressee to let the sender know 
about the changed address.


this is what I have thought up to tackle such tasks:



#!/bin/bash mailbody="$(grep -v '^From ' -)" today="$(date '+%d.%m.%Y')" 
msgid="$(echo "$mailbody" | grep -i '^message-id:' | sed 's/^[^:]*: 
//')" readarray -t recipients < ./addressees.list for i in 
"${recipients[@]}" do v_mailpart="$(date '+%s%N'|sha1sum|sed 's/ .*//')" 
echo "References: $msgid Subject: Forwarded email of $today for $i To: 
$i From: Carsten Schiefner  BCC: 
carsten@schiefner.berlin X-Forwarded-Message-Id: $msgid In-Reply-To: 
$msgid Content-Type: multipart/mixed;  boundary=\"$v_mailpart\" 
MIME-Version: 1.0 This is a multi-part message in MIME format. 
--$v_mailpart Content-Type: text/plain; charset=\"UTF-8\" 
Content-Transfer-Encoding: quoted-printable --$v_mailpart Content-Type: 
message/rfc822;  name=\"Attached Message.eml\" 
Content-Transfer-Encoding: 8bit Content-Disposition: attachment; 
 filename=\"Attached Message.eml\" $mailbody --$v_mailpart--" | exim 
-ti done





The script is invoked from the .procmailrc file:



:0 * ^To: .*[addressee's email address] | ./auto_forward_script




The email addresses in the "addressees.list" text file should have the 
format "first_name last_name " or something similar that 
will equally be understood by exim resp. your chosen MTA.


Feel free to use it and - even better! :-) - improve it. If that occurs, 
please be kindly asked to share your result here again.


Cheers,

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


Re: [mailop] Guide for setting up a mail server ?

2023-07-10 Thread Carsten Schiefner via mailop
Home - maddy
https://maddy.email/

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: "Taavi Eomäe via mailop" 
To: John Levine , mailop@mailop.org
Sent: Mo., 10 Juli 2023 10:12
Subject: Re: [mailop] Guide for setting up a mail server ?

Instead of struggling with Postfix, OpenDKIM, Dovecot and friends (and 
losing out on quite a few features). I'd really recommend looking at 
Maddy instead.

Immensely better "UX" than the currently mentioned approach.

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


Re: [mailop] SPF +all considered harmful

2023-07-08 Thread Carsten Schiefner via mailop
Good point - thanks for highlighting this, Hans-Martin!

> Am 08.07.2023 um 09:28 schrieb Hans-Martin Mosner via mailop 
> :
> 
> 
> Most likely none of you would consider adding +all to an SPF record a smart 
> move, here's another reason why you shouldn't do it:
> 
> Google cloud services are being used to spam (ongoing for a long time, Google 
> doesn't seem to care). What I noticed today is that the spammer is using 
> domains with SPF +all as sender and HELO domains, presumably hoping to avoid 
> SPF based rejections or quarantine.
> 
> This might lead to bad reputation for the domains involved...
> 
> Cheers,
> Hans-Martin 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] greylisting

2023-06-25 Thread Carsten Schiefner via mailop

Hi N.N. -

On 24.06.2023 21:57, ml+mailop--- via mailop wrote:

On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:

What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?


It isn't.

(it works fairly well for the way I'm using it...)


No doubts.

The question, however, is: will it ble..., erm, can one do without 
greylisting?


That at least is my experience.

I recently had to build my exim setup from scratch: without greylisting, 
when the former setup had it. Initially I have had plans to also deploy 
greylisting for the new setup, but eventually dropped these.


Because interestingly enough there has not been any noticable increase 
in spam influx. At all.


Disclaimer: I run a super small mail server compared to the setups being 
discussed here; a couple of hundred virtual email addresses, less than 
ten real accounts.


Cheers,

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


Re: [mailop] SendGrid is deleting your mail

2023-06-23 Thread Carsten Schiefner via mailop
Hi, Luke (& all) -

how about elaborating a bit further on the whats and whys of your setup?

Because at first sight it is indeed a bit hard to understand why SendGrid may 
not be in a position to follow the RFCs and the thereof derived and sort of 
well-established practices of handling server responses.

This might actually take a bit of heat out of this thread.

And after all, noboy here is really already at the top of their learning curve 
as I'd assume - and so additional knowledge is quite likely welcome. 

Best,

-C.

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Luke via mailop 
To: Bill Cole 
Cc: Luke via mailop 
Sent: Fr., 23 Juni 2023 18:53
Subject: Re: [mailop] SendGrid is deleting your mail

That's right, Bill. It's so simple. All the ESPs and MTAs out there have
tools built in to create and customize response handling rules for
absolutely no reason. We actually just do it for fun. We know that every
single 4xx should be retried and every single 5xx should not be retried.
But we thought it would be neat to have a table with hundreds of custom
rules just to make it sound more complicated than it is.

So, you're right, it's just because we are big and we don't think the rules
apply to us. Super productive take you have there. I can tell you've really
given this some thought.

On Fri, Jun 23, 2023, 7:37 AM Bill Cole via mailop 
wrote:

> On 2023-06-22 at 19:14:15 UTC-0400 (Thu, 22 Jun 2023 16:14:15 -0700)
> Luke via mailop 
> is rumored to have said:
>
>
> > Unfortunately we cant make a rule that retries all 4xx and doesn't
> > retry
> > all 5xx. Despite very smart, well intended people writing RFCs and
> > other
> > specs that make this feel super clean cut in an acedemic or lab
> > environment, it's just not how it works in the wild.
>
> And yet somehow it is how the overwhelming majority of mail systems have
> dealt with SMTP reply codes, for decades, successfully.
>
> SendGrid's deliverability problems are precisely because you and your
> coworkers think that you are so big that the rules can't apply to you.
> That you are somehow different and special.
>
> You are wrong. You're nothing special. You're just big. Get over
> yourselves.
>
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
> ___
> 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] PSL: SOA record per subdomain required?

2023-05-07 Thread Carsten Schiefner via mailop
Please ignore the below - I haven’t been aware that the list is split into two sections.And I have looked at the first one only - my apologies!Am 07.05.2023 um 23:01 schrieb Carsten Schiefner :Hi John,Am 07.05.2023 um 20:02 schrieb John Levine via mailop :[…]The same thing applies to all of these names, all in the PSL:dyn-berlin.dein-berlin.dein-brb.dein-butter.dein-dsl.dein-dsl.netin-dsl.orgin-vpn.dein-vpn.netin-vpn.orgI haven’t checked all the TLDs mentioned, but just .de.And I might have turned to the wrong list - but:public_suffix_listTextdokument · 238 KBclearly does not list any public suffices for .de.Which precisely matches my current state of knowledge.Hope you can clarify.Thanks and best,-C.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] PSL: SOA record per subdomain required?

2023-05-07 Thread Carsten Schiefner via mailop
Please ignore the below - I haven’t been aware that the list is split into two sections.And I have looked at the first one only - my apologies!Am 07.05.2023 um 23:01 schrieb Carsten Schiefner :Hi John,Am 07.05.2023 um 20:02 schrieb John Levine via mailop :[…]The same thing applies to all of these names, all in the PSL:dyn-berlin.dein-berlin.dein-brb.dein-butter.dein-dsl.dein-dsl.netin-dsl.orgin-vpn.dein-vpn.netin-vpn.orgI haven’t checked all the TLDs mentioned, but just .de.And I might have turned to the wrong list - but:public_suffix_listTextdokument · 238 KBclearly does not list any public suffices for .de.Which precisely matches my current state of knowledge.Hope you can clarify.Thanks and best,-C.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Yahoo: SOA record per subdomain required?!

2023-05-07 Thread Carsten Schiefner via mailop
So, at least for the time being, it appears that the Y! universe handle 
this in a non-deterministic manner.


Lovely.

On 07.05.2023 11:57, Ken Peng via mailop wrote:

May 7, 2023 at 2:17 PM, "Matt Palmer via mailop"  wrote:


[...]

It's deliberate, and documented:

https://senders.yahooinc.com/smtp-error-codes/#unresolvable-from-domain




Hello

After my test, the subdomain e.mail.de can delivery messages to yahoo.com.
And, e.mail.de has no soa RR as well.

$ dig e.mail.de soa +short

gets nothing.

I am guessing yahoo is blocking the specified subdomains, not all.

As a comparision, I sent another mail from my alumni email, alumni.nd.edu.

This is a real zone, has soa defined.

$ dig alumni.nd.edu soa +short
ns1.nd.edu. dns.nd.edu. 209 10800 3600 1209600 900

And the message was delivered to yahoo successfully.

Anyway yahoo should not reject a message only b/c its domain has no SOA.


regards,
Ken Peng

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


Re: [mailop] ab...@microsoft.com => Mailbox full

2023-04-22 Thread Carsten Schiefner via mailop
And whatever is being reported via this form will probably be internally sent 
to .

|-)

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Mark Foster via mailop 
To: Benoit Panizzon 
Cc: mailop@mailop.org
Sent: Sa., 22 Apr. 2023 7:28
Subject: Re: [mailop] ab...@microsoft.com => Mailbox full

Per https://msrc.microsoft.com/report/abuse it appears they would like 
you to fill in a web form, in order to "report suspected cyberattacks or 
abuse originating from Microsoft Online Services, such as Microsoft 
Azure, Bing, OneDrive, and Office 365."

It does cite ab...@microsoft.com as a valid contact for reporting Child 
Sexual Abuse imagery, which suggests a real person should be reading 
abuse@ - but I would not be surprised if they do the typical huge-org 
thing and filter out everything that should've been reported via another 
method, as a poor-persons's way to manage volume. I'm sure there's 
plenty of it.

Mark.

On 2023-04-21 01:32, Benoit Panizzon via mailop wrote:
> For heaven's sake Microsoft!
> 
> I'm trying to report the same spaming Office 365 Customer again which
> uses a shared ip address with some other Swiss companies that use
> Office 365 and experience collateral damage...
> 
> That is NOT the reply I expect.
> 
> === snipp ===
> 
> Delivery has failed to these recipients or groups:
> 
> ab...@microsoft.com
> The recipient's mailbox is full and can't accept messages now. Please
> try resending your message later, or contact the recipient directly.
> 
> === snapp ===
> 
> Yes please, how can I contact the microsoft abuse desk more directly?
> 
> Mit freundlichen Grüssen
> 
> -Benoît Panizzon-
___
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] Compromised email account trends

2023-02-22 Thread Carsten Schiefner via mailop

Sebastian & all -

On 22.02.2023 01:51, Sebastian Nielsen via mailop wrote:
Didn't get steve's mail for some reason (guess it was because i forgot 
to renew exim tls cert, but its renewed now), but replying to it here.


I have also noticed that: this particular email did not pop into my 
inbox either.


After having looked a bit deeper into this, it appears that Steve 
Freegard replied directly and only to Jarland Donnell on 21 Feb, 12:10 
(timezone?).


Jarland Donnell in turn has then replied publicly to the list again on 
21 Feb, 17:04:02 -0600.


That at least is how I would interpret the present/missing) list footers.

So no mails missed! :-)

Cheers,

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


Re: [mailop] Cyren

2023-02-03 Thread Carsten Schiefner via mailop

All -

for those amongst you who have no real clue what Matthew's email is 
about, please be referred to:


Cyren Announces Global Reduction in Force; Liquidity Challenges
https://ir.cyren.com/websites/cyren/English/5015/press-release.html?airportNewsID=631c3a77-555f-4a78-be5b-ec30c5cdaaac

Best,

-C.

On 03.02.2023 13:45, Matthew Stith via mailop wrote:

All,

Spamhaus is offering our data query service for free for 90 days for 
users impacted by Cyren's sudden liquidation. No strings attached just 
an effort to get those that are impacted by the news this week protected 
as quickly as possible. Our hopes is that this gives users protection 
against abuse while they figure out their next steps.

https://www.spamhaus.com/free-trial/sign-up-for-a-free-data-query-service-account/

And any Cyren employees that may be on this list. Know that you have the 
support of the community behind you.


Thanks,
Matt Stith
Spamhaus

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


Re: [mailop] gmail putting most messages into Spam

2023-01-17 Thread Carsten Schiefner via mailop
Thanks,  Jarland - excellent pointer!

-Original Message-
From: Jarland Donnell via mailop 
To: Mailop 
Sent: Mi., 18 Jan. 2023 0:31
Subject: Re: [mailop] gmail putting most messages into Spam

[...]

My first instinct in your position would be to use something like 
mail-tester.com to get a basic check over your headers, DNS, etc. I know 
it's not wildly popular on this list but in a world where the average 
user still runs to mxtoolbox, mail-tester.com is exponentially better in 
it's assessments.
___
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

2022-10-19 Thread Carsten Schiefner via mailop
Grant & all -

if it‘s a .de domain name one does not need a privacy service any longer since 
2018(?) as the GDPR (or its interpretation) mandates that holder data must not 
be available via WHOIS to the general public.

I would not be surprised if that‘d hold true for all ccTLDs where the GDPR is 
applicable.

Best,

-C.

> Am 19.10.2022 um 17:23 schrieb Grant Taylor via mailop :
> 
> On 10/19/22 7:25 AM, Johann Haarhoff via mailop wrote:
> T-Online:
>> the IP address  is delegated to your provider and there is no owner data 
>> in the public whois record for your domain.  Thus, the person or company who 
>> is responsible for this host is essentially anonymous to third parties.
>> 
>> Therefore we would expect that there is a page giving full contact details 
>> which can be reached via http:// or http://www.
> 
> Do you use privacy options in WhoIs for your domain name?  Since you 
> (understandably) obfuscated your domain name I can't check.
> 
> I wonder if having real, non-privacy options, in a domain name helps with 
> this.
> 
> 
> 
> -- 
> Grant. . . .
> unix || die
> 
> ___
> 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] T-Online is now really blocking messages from non-commercial and simliar senders

2022-10-19 Thread Carsten Schiefner via mailop
Having read up the entire thread now, I wonder if this issue might be worth 
raising with Germany‘s federal regulator for (inter alia) postal and telco 
services, BNetzA.

I wonder what would happen if the owner of a 20-storey apartment building would 
only allow properly accredited - according to its own, partly ambiguous rules - 
mail delivery services into the house…

Comments?

> Am 19.10.2022 um 13:39 schrieb Heiko Schlittermann via mailop 
> :
> 
> Hello,
> 
> I'm not sure how to complain and where. But I hope that here we can
> start a discussion again. I'm quite upset.
> 
> Is this the new world?
> 
> A given mailhost (ran privately for smaller entities) can't send
> messages to T-Online anymore.
> 
>  554 IP=168.119.159.241 - A problem occurred. …
> 
> The sending IP belongs to a rented host (rented from a major German
> hoster). The answer he (the owner of that host) got was about like this:
> 
> (translation by me): 
>  Sorry, we only accept messages from proven
>  commercial or similiar servers. Please use the SMTP relay of your hoster
>  or your ISP.
> 
> I know that T-Online's postmaster announced this kind of behaviour, but
> I didn't expect that they are going to implement it, as I saw enough
> complaints here.
> 
> From my point of view they now force smaller MSP into contracts with
> bigger mail relays, working towards a centralization of mail services,
> which IMHO is exactly the opposite way mail was originally designed to
> work as.
> 
> @mailops: What's your opinion?
> 
> Personally I consider this quite rude, and as a smaller ISP I'll be hit
> sooner or later. As an Exim developer I'm asking myself why they
> (T-Online) assume that I shouldn't run my own mail service.
> 
>Best regards from Dresden/Germany
>Viele Grüße aus Dresden
>Heiko Schlittermann
> --
> SCHLITTERMANN.de  internet & unix support -
> Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
> gnupg encrypted messages are welcome --- key ID: F69376CE -
> ___
> 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] The oligopoly has won.

2022-09-13 Thread Carsten Schiefner via mailop

On 13.09.2022 07:57, Eduardo Diaz Comellas via mailop wrote:

[...]

After investigation, several IPs used by gmail to send the email were 
blacklisted. I had a tough time explaining to the customer that it was 
gmail's fault to still use this IPs to send their email. Gmail never 
acknowledged the problem and didn't change the outgoing IP addresses. 
The problem was only "solved" when the blacklisting expired. And this 
was to a paying customer with 200 Gsuite accounts...


But isn't that just perfectly serving on the main point of this entire 
thread?


"Hey, we're Gmail - you better do not put any of our IP addresses on a 
blacklist!"


Best,

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


Re: [mailop] EC certs in MTA - MTA TLS

2022-08-23 Thread Carsten Schiefner via mailop

Thanks, Slavko - truly appreciated!

On 23.08.2022 16:17, Slavko via mailop wrote:

Dňa Tue, 23 Aug 2022 12:33:47 +0200 Carsten Schiefner via mailop
 napísal:


would you mind reporting back then and to share that particular exim
config snippet that does the trick?


No problem ;-)

It is really simple. The exim's specs (4.94.2) says:

   [...]

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


Re: [mailop] EC certs in MTA - MTA TLS

2022-08-23 Thread Carsten Schiefner via mailop

Hi Slavko,

On 23.08.2022 09:41, Slavko via mailop wrote:

Dňa Mon, 22 Aug 2022 19:05:27 -0500 Chris Adams via mailop
 napísal:


Postfix's TLS_README also says it supports multiple server cert types,
determining which to use based on the negotiated ciphersuite.


Exim declares that it supports this too, i will setup it by this
way and i will see after some time how it works.


would you mind reporting back then and to share that particular exim 
config snippet that does the trick?


Thanks & best,

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


Re: [mailop] What to do with a look-alike domain used in phishing

2022-07-18 Thread Carsten Schiefner via mailop
Thomas,

shall we talk this through out of band - and you may post a summary later on, 
if you wish?

Best,

-C.
-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Tobias Fiebig via mailop 
To: mailop@mailop.org
Sent: Mo., 18 Juli 2022 10:45
Subject: [mailop] What to do with a look-alike domain used in phishing

Heho,
~a year ago I registered a (by then) unregistered look-alike domain for a major 
European hoster, as I was receiving rather good spear-phishing from it, and it 
was, well, unregistered. (The domain is hetzners.de ). 

I setup DMARC p=reject and SPF -all, and let it be. Now, the domain keeps 
sitting around; Thing is, that dereg would most likely lead to more spam 
falling out of the domain again (or it being actually registered by some 
spammer), which is rather not so nice to the Internet as a whole. The hoster is 
not interested in receiving it from me (free of charge etc.; Offered to just 
send them the authcode). 

Now, what can I ethically do with the domain? I would kind of prefer it going 
to some org. that actually makes an effort in drying out domains used like 
this; Does somebody have a suggestion/contact whom to ask?

With best regards,
Tobias

___
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] Paper on email delivery/standards adoption

2022-06-13 Thread Carsten Schiefner via mailop
Thanks, Tobias, fo sharing!

All the best,

-C.

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Tobias Fiebig via mailop 
To: mailop@mailop.org
Sent: Mo., 13 Juni 2022 22:35
Subject: [mailop] Paper on email delivery/standards adoption

Heho,
Quiet some time ago i asked the list for some help in an ongoing email 
measurement study; The paper is now finally out and accepted. 

An open-access preprint can be found here:  
https://pure.mpg.de/rest/items/item_3384330_2/component/file_3388008/content

I guess the most interesting result on this list is that the 'Email Camel' 
(after the DNS Camel) is more complex than... well, DNS.

Anyway, figured it might be interesting for some on the list.

With best regards,
Tobias

___
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] Contact at Contabo?

2022-05-31 Thread Carsten Schiefner via mailop

Morning, Hans-Martin -

On 31.05.2022 07:26, Hans-Martin Mosner via mailop wrote:
does anybody have a working contact at Contabo? Mail to abuse@ does not 
seem to have an effect.


last time I have been in touch with them as their customer, it took them 
four working days to get back to me, although on a mere and totally 
non-urgent FYI message.


Inbound was , outbound however was .

Best,

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


Re: [mailop] Kirk MacDonald sucht freenet.de email abuse contact

2022-02-25 Thread Carsten Schiefner via mailop
All -

> Am 26.02.2022 um 07:24 schrieb Carsten Schiefner via mailop 
> :
> 
> Danke,  Martin - habe ich mal so an Kirk durchgereicht.

apologies for my above answer in German: I haven’t realized that Martin had 
changed mailing lists from DENOG’s to this one in the course of his answer.

Best,

-C.

> -Original Message-
> From: Martin Moutarde 
> To: Carsten Schiefner 
> Cc: mailop@mailop.org
> Sent: Fr., 25 Feb. 2022 23:52
> Subject: Re: Kirk MacDonald sucht freenet.de email abuse contact
> 
> 
> 
> Just found @ https://www.freenet.de/impressum/index.html
> 
> "Bei Missbrauch (Urheberrechtsverletzungen, IP-Attacken, Hacking, 
> gesetzeswidrige SMS- und Homepageinhalte) 
> wenden Sie sich bitte an die E-Mail-Adresse ab...@service.freenet.de ."
> 
> ---> should be: ab...@service.freenet.de
> 
> 
> best regards
> 
> Martin Moutarde
> 
> 
> 
> 
>> On Fri, Feb 25, 2022 at 07:53:48PM +0100, Carsten Schiefner wrote:
>> Allseits -
>> 
>> wer helfen kann und möchte...
>> 
>> Ein schönes Wochenende wünscht:
>> 
>> -C.
>> 
>>  Forwarded Message 
>> Subject:[mailop] freenet.de email abuse contact
>> Date:Fri, 25 Feb 2022 16:02:06 +
>> From:Kirk MacDonald via mailop 
>> Reply-To:Kirk MacDonald 
>> To:mailop@mailop.org 
>> 
>> 
>> 
>> If there are any folks from freenet.de in Germany on this list, could 
>> they please reply to me regarding delivery issues of mail out of 
>> sendgrid infra? It relates to an unclear (to me) SMTP 550 response code 
>> “No valid sender in header”
>> 
>> Kirk MacDonald
>> 
>> kirk.macdon...@resmed.com
>> 
>> Information Security Analyst
>> 
>> Halifax, NS CA
>> 
>> 
>> Warning: Copyright ResMed. Where the contents of this email and/or 
>> attachment includes materials prepared by ResMed, the use of those 
>> materials is subject exclusively to the conditions of engagement between 
>> ResMed and the intended recipient.
>> 
>> This communication is confidential and may contain legally privileged 
>> information. By the use of email over the Internet or other 
>> communication systems, ResMed is not waiving either confidentiality of, 
>> or legal privilege in, the content of the email and of any attachments. 
>> If the recipient of this message is not the intended addressee, please 
>> call ResMed immediately on 1 (800) 424-0737 USA.

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


Re: [mailop] Kirk MacDonald sucht freenet.de email abuse contact

2022-02-25 Thread Carsten Schiefner via mailop
Danke,  Martin - habe ich mal so an Kirk durchgereicht.

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Martin Moutarde 
To: Carsten Schiefner 
Cc: mailop@mailop.org
Sent: Fr., 25 Feb. 2022 23:52
Subject: Re: Kirk MacDonald sucht freenet.de email abuse contact



Just found @ https://www.freenet.de/impressum/index.html

"Bei Missbrauch (Urheberrechtsverletzungen, IP-Attacken, Hacking, 
gesetzeswidrige SMS- und Homepageinhalte) 
wenden Sie sich bitte an die E-Mail-Adresse ab...@service.freenet.de ."

---> should be: ab...@service.freenet.de


best regards

Martin Moutarde




On Fri, Feb 25, 2022 at 07:53:48PM +0100, Carsten Schiefner wrote:
> Allseits -
> 
> wer helfen kann und möchte...
> 
> Ein schönes Wochenende wünscht:
> 
>  -C.
> 
>  Forwarded Message 
> Subject:  [mailop] freenet.de email abuse contact
> Date: Fri, 25 Feb 2022 16:02:06 +
> From: Kirk MacDonald via mailop 
> Reply-To: Kirk MacDonald 
> To:   mailop@mailop.org 
> 
> 
> 
> If there are any folks from freenet.de in Germany on this list, could 
> they please reply to me regarding delivery issues of mail out of 
> sendgrid infra? It relates to an unclear (to me) SMTP 550 response code 
> “No valid sender in header”
> 
> Kirk MacDonald
> 
> kirk.macdon...@resmed.com
> 
> Information Security Analyst
> 
> Halifax, NS CA
> 
> 
> Warning: Copyright ResMed. Where the contents of this email and/or 
> attachment includes materials prepared by ResMed, the use of those 
> materials is subject exclusively to the conditions of engagement between 
> ResMed and the intended recipient.
> 
> This communication is confidential and may contain legally privileged 
> information. By the use of email over the Internet or other 
> communication systems, ResMed is not waiving either confidentiality of, 
> or legal privilege in, the content of the email and of any attachments. 
> If the recipient of this message is not the intended addressee, please 
> call ResMed immediately on 1 (800) 424-0737 USA.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Google considers DMARC reports to be unsolicited mail :(

2022-02-09 Thread Carsten Schiefner via mailop
"that *THIS* message is likely unsolicited mail" (my emphasis): IMHO this sort 
of leads to a message-based interpretation rather than a system-based one, 
Patrick.

-- 
Von meiner Hängematte aus gesendet.

-Original Message-
From: Patrick Ben Koetter via mailop 
To: mailop@mailop.org
Sent: Mi., 09 Feb. 2022 11:52
Subject: Re: [mailop] Google considers DMARC reports to be unsolicited mail :(

* Bernardo Reino via mailop :
> Dear all,
> 
> I have already experienced Google ratelimiting DMARC reports every now and
> then, which may be OK if they want it like that.. but this is new (to me):
> 
> Reporting-MTA: dns; katara.bbmk.org
> X-Postfix-Queue-ID: 3D2D71BE02E2
> X-Postfix-Sender: rfc822; rep...@dmarc.bbmk.org
> Arrival-Date: Wed,  9 Feb 2022 07:01:03 +0100 (CET)
> 
> Final-Recipient: rfc822; mailauth-repo...@google.com
> Original-Recipient: rfc822;mailauth-repo...@google.com
> Action: failed
> Status: 5.7.1
> Remote-MTA: dns; aspmx.l.google.com
> Diagnostic-Code: smtp; 550-5.7.1 [65.108.69.105  12] Our system has
> detected that this message is 550-5.7.1 likely unsolicited mail. To reduce
> the amount of spam sent to Gmail, 550-5.7.1 this message has been blocked.
> Please visit 550-5.7.1
> https://support.google.com/mail/?p=UnsolicitedMessageError 550 5.7.1  for
> more information. e21si14404251ljg.437 - gsmtp
> 
> I guess there's nothing to do, but I find this irritating.. I mean, they
> could just stop requesting DMARC reports instead of requesting and refusing
> them? :)

What makes you believe they reject the content of your message and not your
mail systems regardless of what it sends?

p@rick


-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

___
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] Musings on Mail Service Operators

2022-02-02 Thread Carsten Schiefner via mailop

On 02.02.2022 11:20, Jaroslaw Rafa via mailop wrote:

Dnia  2.02.2022 o godz. 10:47:33 Carsten Schiefner via mailop pisze:

Having now also read Michael's call for O365 assistance, I start to
earnestly wonder when folks are tired enough of having put their
email fate into the hands of a few mega-large Mail Service Operators
with kafkaesque and fully intransparent processes and instead will
attempt to regain knowledge to run their own and small-scale mail
systems again as they realize that proper and flawless electronic
communication is part of their core business functions - whatever
that business exactly might be.


I think it will rather go the other way, because of the scale of those
mega-large mail operators. Because of their scale, the average user's
perception is that "almost everybody" is using them, so if somebody has
problems with delivering mail to them, something must be wrong with the
sender, and not with those large operators. They are "too big to be wrong".
For the users using them the solution is simple: if you have problems
delivering mail to the large operator, you should switch to that operator as
well, instead of using some "unknown mail service". Then you will have no
problems.

And that's exactly what those big operators want...


That unfortunately makes quite some sense to me, too, Jaroslaw.

And it appears to be a classic perpetrator/victim reversal wrt. to the 
perception of the public... :-/

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


[mailop] Musings on Mail Service Operators

2022-02-02 Thread Carsten Schiefner via mailop
Having now also read Michael's call for O365 assistance, I start to 
earnestly wonder when folks are tired enough of having put their email 
fate into the hands of a few mega-large Mail Service Operators with 
kafkaesque and fully intransparent processes and instead will attempt to 
regain knowledge to run their own and small-scale mail systems again as 
they realize that proper and flawless electronic communication is part 
of their core business functions - whatever that business exactly might be.


Best,

-C.

 Forwarded Message 
Subject: [mailop] Office 365 Assistance
Date: Wed, 2 Feb 2022 04:06:20 +
From: Michael E. Weisel via mailop 
Reply-To: Michael E. Weisel 
To: mailop@mailop.org 



Hi everyone, I hope you are all well and staying healthy and safe.  
We’ve been working with The Home Depot on their Retool Your School 
Program (https://retoolyourschool.com/) for more than ten years now.  
Over the past year and especially the last few months, we are having a 
hard time getting their emails to the intended recipients with a lot of 
their messages going to junk.  All the messages are going to HBCU’s 
(Historically Black College and Universities) and a lot of them are 
using Microsoft Office 365.  We’ve begun to ask the colleges to mark 
their IP, domain, and email address as safe senders but it’s hard to 
reach everyone personally.  The messages are not bouncing back, just 
ending up in Junk for a large majority of subscribers.  This is a 100% 
opt-in program, and the list size is under 700 subscribers.  They send 
out once to twice a week from December through May.  All the colleges 
are competing for more than $500,000 in campus improvement prizes and 
many schools can’t participate because they aren’t receiving the emails. 
They have a dedicated IP address and custom DNS.  It’s setup with SPF, 
DK, DKIM, DMARC, SNDS, JMRP, and a “List Unsubscribe” in the header.  
I’ve filled out the forms for Office 365 support and the IP isn’t 
blocked.  I also filled out the Microsoft support form and the IP is 
also not blocked there or any indication through SNDS that there are any 
issues.  If anyone on list may be able to help, the program would be 
greatly appreciative.


Thanks,

Michael

Michael E. Weisel

CTO / Deliverability Lead

Gold Lasso

(301) 990-9857 Corporate

(240) 813-0174 Direct Dial
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


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

2022-01-25 Thread Carsten Schiefner via mailop

On 25.01.2022 13:56, Hans-Martin Mosner via mailop wrote:
25. Januar 2022 10:32, "Graeme Fowler via mailop" > 
schrieb:


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.

Wouldn't it be more straightforward to inform those whose mailboxes 
generated the rejections, instead of posting a "public announcement" 
that leaves everyone guessing whether they may somehow unknowingly 
involved? I've encountered this kind of bringing public attention to a 
problem that actually is caused by few people, and it always leaves a 
somewhat uneasy feeling. Or is it actually a problem with so many 
mailboxes that it's just easier to notify the whole list? :-)


And furthermore, what's the probability of a successful in-band 
reach-out to those having shown (temporary?) non-deliverances and 
bounces in the recent past for this very means of communication?


My guesstimation would likely add to Hans-Martin's suggestion to reach 
out to them on an individual basis.


Best,

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


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

2022-01-25 Thread Carsten Schiefner via mailop

Graeme & all -

if it wouldn't be this seriously concerning, a note of such content on a 
mailing list where one of the main purposes is to unblock mail blockages 
could be considered quite funny...


Best,

-C.

On 25.01.2022 10:32, Graeme Fowler via mailop wrote:

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


[mailop] RP RRs

2022-01-17 Thread Carsten Schiefner via mailop
Thanks, John - one indeed can get smarter every day; there is still 
enough stuff out there to become aware and to learn! ;-)


 Forwarded Message 
Subject: Re: [mailop] What am I supposed to do with abuse complaints on 
legit mail?

Date: 17 Jan 2022 14:09:55 -0500
From: John Levine via mailop 
Reply-To: John Levine 
Organization: Taughannock Networks
To: mailop@mailop.org
CC: mailopl...@amssupport.info

It appears that Scott Mutter via mailop  said:

-=-=-=-=-=-
-=-=-=-=-=-

On Mon, Jan 17, 2022 at 12:06 PM Grant Taylor via mailop 
wrote:


Drive by comment:

What if we had something like an MX record published for the IP
address(es) in reverse DNS / in-addr.arpa for
... and configure those MX records to route to a mail server
of the owners / administrators of the IP (space) in question?



Do reverse DNS entries support the TXT structure?  Why not just create a
special, specific TXT record for a contact email address?


This might be a good time to review the RP DNS record.  See RFC 1183.

As far as I can tell, I am the only person in the world that still
publishes them.

R's,
John
___
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] blocked by microsoft

2022-01-06 Thread Carsten Schiefner via mailop
That's true as well, Jay - what can I say...

On 05.01.2022 19:42, Jay Hennigan via mailop wrote:
> On 1/5/22 07:03, Carsten Schiefner via mailop wrote:
>> How about registering a Hotmail account for this purpose?
>>
>> And if you play it via its web GUI, I’m sure you’d get through.
> 
> That's exactly what the end goal is.
> 
> https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish
> 
> * Embrace - Take the RFC standards for email and incorporate them into
> MS products.
> 
> * Extend - Incorporate email into a proprietary product
> (Hotmail/Outlook/Office365).
> 
> * Extinguish - Ensure that any use of the original standard not
> incorporating MS's proprietary products is difficult or impossible.
> 
> If the only way to send email to Microsoft or its customers is to use a
> Microsoft product, they've won.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Ethics Complaint to Princeton (was: Bizarre GDPR/CCPA scam spam from Princeton researchers)

2021-12-23 Thread Carsten Schiefner via mailop

Greg -

On 22.12.2021 16:58, Grant Taylor via mailop wrote:

On 12/22/21 2:27 AM, Raymond Dijkxhoorn via mailop wrote:
Yes they do communicate but they are now sugesting to spam everybody 
once more with some explanation. ...


I wonder if they will learn anything if they see a non-trivial number of 
systems are now rejecting their messages.


during the last two years, I have lost my faith a bit wrt. the reactive 
learning capabilities of quite a portion of people...


Let's see.

Seasonal greetings,

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


Re: [mailop] Paging GMX mail admins: issues with automatic mail forwards

2021-12-21 Thread Carsten Schiefner via mailop

Thanks, Tobias, for your patient advise to get this sorted out!

Seasonal greetings,

-C.

On 01.12.2021 13:02, Tobias Herkula via mailop wrote:

Replied off list.

/ Tobias Herkula (Web.de|GMX|Mail.com)

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Carsten Schiefner via 
mailop
Gesendet: Montag, 29. November 2021 16:22
An: mailop@mailop.org
Betreff: [mailop] Paging GMX mail admins: issues with automatic mail forwards

All -

could a GMX mail admin please be in touch with me, please?

Or point me to such a person?

The issue in short: automatic mail forwarding sporadically fails from GMX mail-out 
servers with claims that "multiple delivery attempts failed" since the 
beginning of November.

Yet, grey listing is now switched off for all known GMX mail-out servers, 2nd 
MXer for the zone is also temporary switched off. Last, but not least: no 
traces of any delivery attempts for these fails in the logs.

I'd like to see this erratic behavour tracked down and solved.

Thanks & best,

-C.

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


[mailop] Paging GMX mail admins: issues with automatic mail forwards

2021-11-29 Thread Carsten Schiefner via mailop

All -

could a GMX mail admin please be in touch with me, please?

Or point me to such a person?

The issue in short: automatic mail forwarding sporadically fails from 
GMX mail-out servers with claims that "multiple delivery attempts 
failed" since the beginning of November.


Yet, grey listing is now switched off for all known GMX mail-out 
servers, 2nd MXer for the zone is also temporary switched off. Last, but 
not least: no traces of any delivery attempts for these fails in the logs.


I'd like to see this erratic behavour tracked down and solved.

Thanks & best,

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