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

[Dan Mahoney via mailop]

> On Apr 15, 2024, at 16:40, Kevin A. McGrail via mailop  
> wrote:
> 
> Hi All,
> 
> We have four servers where we can't retrieve our free ESXi VMWare license 
> after Broadcom shut things down and they are in evaluation mode for about 30 
> more days.
> 
> Does any one have any advice?  Is there a product we can buy?  Is there an 
> alternative you've been switching over to using?  Anyone have a spare license 
> we can use?

This was especially obnoxious of them, because normally your license key for 
the “free” ESXI, which was useful if you just wanted a standalone box in a 
closet to run a few things, lived in VMWare customer connect.  Your need for 
things like VCenter came in when you wanted a central control plane, or access 
to features like VMotion.

And now, not only have they not removed access to the ISOs, but license keys 
that they *gave to you* are magically disappeared.  Those licenses would still 
work — vmware machines do not “phone home” in any way.  The features are coded 
into the license key itself.

Put another way: you should not have to rely on data-hoarding screenshots of 
the management UI to get what you were already granted.

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

Re: [mailop] New to mass mailings

[Dan Mahoney via mailop]

> On May 8, 2023, at 8:45 PM, H via mailop  wrote:
> 
> On 05/08/2023 05:27 AM, Laura Atkins via mailop wrote:
>> 
>> 
>>> On 8 May 2023, at 08:57, Dan Malm via mailop  
>>>  wrote:
>>> 
>>> On 5/6/23 17:28, H via mailop wrote:
 I am new to doing mass mailings to customers and leads - not spam - and am 
 looking for some introduction how to interpret different types of 
 rejection messages so we can improve our success rate etc.
>>> 
>>> Many mailbox providers do at least some things "their own way" so there's 
>>> no catch-all one-stop for all messages and codes. But a good start for what 
>>> the different status codes (should) mean is 
>>> https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml
>> 
>> How are you acquiring your leads, are you purchasing them from somewhere?
> Building lists of leads ourselves but also purchased leads. Just the former 
> would be way too slow of course. By the way, we are communicating with 
> corporate customers, not with individuals using their personal email 
> addresses.

Okay. you’ve got me.

That’s not “leads”, that’s spam, plain and simple.  Maybe — maybe when your 
list of leads comes from an entire company you’ve purchased, this might make 
sense, but if it’s a third party purchase, there’s literally no business 
relationship where a party can claim to have opted in.

I’m more than happy to help people figure out why their mail is being rejected 
when they’re trying to send things like purchase receipts, or opt-ins that 
happened at purchase time.  Or people who are running mailing lists for things 
like open-source projects, but for the stuff you’re doing, I’m in favor of mail 
clue being more like a lightsaber: nobody tells you how to make it, you have to 
figure it out on your own.

Do you have any idea how much b2b spam we get from people who scraped our info@ 
address from our site (three letter domain, on the net for 30 years)?  How many 
people are “just trying to help” with no actual reachability info as required 
by can-spam?  Or, laughably, people trying to sell us more lists of leads from 
other conferences we’d attend?  Hell, dayjob is a software company and for some 
reason we get a ton of companies in china trying to sell us pipes, pumps, and 
butterfly valves — I have no idea why.

If the EU wanted to do something about this, maybe instead of making me accept 
cookies 37 times a day or writing multi-year legislation about phone charging 
ports, they could pass some legislation with teeth.

And don’t get me started on how much of it is enabled by the 
abuse-box-routes-to-devnull freemail folks.

-Dan___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Simple mailing list expander program for aliases files?

[Dan Mahoney via mailop]

All,

Sometimes a problem comes across your desk that you say “wait, how is this not 
solved yet?”.

At the day job, we have a contact list for our customers that comes from our 
ticket system, and it’s stuffed into an alias file with :include:.

The way postfix handles these aliases, is that it preserves the original 
envelope sender and recipient (which we don’t want anyway), and o365 is 
rejecting on that envelope sender/recipient (that it’s not allowed to deliver 
to our internal envelope recipient, which is not unreasonable, but still 
surprising we haven’t hit it before.

The obvious answer is: “Don’t use the :include: mechanism, just use a mailing 
list manager.”  Which, for one alias in a system, feels like overkill.  I don’t 
need membership management.  I don’t need archiving.  I don’t need bounce 
detection.

So I’ve gone down the rabbit hole, looking for various combinations of remailer 
scripts, forwarder scripts, group forwarder scripts, mailing list expanders, 
etc.  And I’m coming up surprisingly short.

Could I knock something together myself in perl in a half hour?  Sure.

Would it likely have its own untested edge cases for us to discover?  
Absolutely.

In a world of DKIM/DMarc compliance, especially, where “blow away the original 
headers and forward anew” is the best answer, I’m shocked to not find something 
like this as well.

Our needs are simple: a unix program we can pipe a message to that will 
preserve the original message mime portions and subject, but discard most of 
the previous other headers.  How in 30 years of email, something that I can’t 
just pkg install isn’t easily findable baffles me.

If someone knows of something, let me know.

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

Re: [mailop] OpenDMARC

[Dan Mahoney via mailop]

> On Dec 29, 2022, at 20:38, Mark Foster via mailop  wrote:
> 
> Some reading that might be useful.
> 
> https://github.com/vshymanskyy/StandWithUkraine/issues/135
> 
> https://www.theregister.com/2022/06/27/7zip_compression_tool/
> 
> https://pcper.com/2022/06/boycott-7-zip-because-its-not-on-github-seriously/
> 
> My impression is that 7-Zip is way, way down the severity list, and the 
> author can't help the actions of his own government.
> 
> Best part of open source projects is the ability for the code to be 
> independently reviewed.

At this point we're so off in the weeds that this has little to do with either 
OpenDMARC or mail operations at all.

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

Re: [mailop] Postfix.org borked?

[Dan Mahoney via mailop]

> On Nov 21, 2022, at 2:49 PM, Bill Cole via mailop  wrote:
> 
> On 2022-11-21 at 16:41:44 UTC-0500 (Mon, 21 Nov 2022 16:41:44 -0500)
> Michael Orlitzky via mailop 
> is rumored to have said:
> 
>> On Mon, 2022-11-21 at 11:12 -0800, Dan Mahoney (Gushi) via mailop
>> wrote:
>>> 
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 512
>>> ;; QUESTION SECTION:
>>> ;postfix.org.   IN  A
>>> 
>>> 
>> 
>> You want www.postfix.org. The bare domain name has never(?) worked.
> 
> The bare domain has a MX record. SERVFAIL is never a proper response. Should 
> answer an A query with NOERROR and zero answers.

To be clear, I was also hitting errors when I was trying to (from a direct 
google link) hit the www.postfix.org mailing lists page, and getting a safari 
timeout.

-Dan

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

Re: [mailop] two openssl (in OpenDKIM) questions for the masses

[Dan Mahoney via mailop]

> On Sep 20, 2022, at 20:31, Philip Paeps via mailop  wrote:
> 
> On 2022-09-16 05:44:50 (+0800), Dan Mahoney (Gushi) via mailop wrote:
>> I'm attempting to get a point release of OpenDKIM out that should include 
>> ecc key support (it's been in our develop branch for a while).
>> 
>> In doing the cleanup, I also have had to modernize it to play nice with 
>> modern versions of autoconf, and the code to detect openssl versions also 
>> allows for gnutls.
>> 
>> Thus the questions:
>> 
>> * Does anyone know of an OS packager that's choosing to build with gnutls 
>> instead of openssl.  (It would simplify autoconf a lot to remove the gnutls 
>> support, as there are AC macros for openssl, but not for gtls).
> 
> The FreeBSD port has an option to build with gnutls instead of OpenSSL.  This 
> option is off by default.  It is not exercised by our package builders so 
> it's anyone's guess how well it works.  Given that the option exists, I would 
> expect the port MAINTAINER to have tried it ... at least once. :)
> 
>> * Does anyone have an OS using openssl 3.0 as the default rather than the 
>> 1.1 branch, that we can test the mainline branch on?  (We don't want access 
>> to your OS, just...to know which it is).
> 
> Again, not by default, but you can set OPENSSL_VERSION=openssl-devel on 
> FreeBSD to build with security/openssl-devel (which is currently 3.0.5) 
> instead of the base system OpenSSL.  This is known to break a lot of things.  
> OpenDKIM may be simple enough that it works for you though.

As you may have seen, there are several OSes doing this now, which means I need 
to deploy VMs to test it.

Perhaps too much noise for mailop, but maybe not:

The way opendkim detects the crypto libs is with a pretty obnoxious handrolled 
check that the FreeBSD port totally overwrites.  I'd like to be able to compile 
the native package on Freebsd, which it presently doesn't do.

Our next release will probably include a note in the README that says something 
like "if you are using gnutls as part of a prebuilt package, we want to hear 
from you".  Fewer code permutations feels more maintainable.

I'm going to be reaching out to the FreeBSD port maintainer (who is not me, I 
maintain the opendmarc port, not the opendkim one)

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

Re: [mailop] DMARC Stockholm syndrome, Reject vs spam folders

[Dan Mahoney via mailop]

> On Sep 19, 2022, at 09:15, John Levine via mailop  wrote:
> 
> It appears that Jim Popovitch via mailop  said:
>> On Mon, 2022-09-19 at 17:07 +0200, Alessandro Vesely via mailop wrote:
>>> 
>>> ARC is the authentication of choice in this case because, being devised for 
>>> this task, it is supposedly straightforward to configure for it, whereas 
>>> whitelisting after SPF or DKIM smells like a hack.
>> 
>> I wish ARC was straighforward to configure and implement, but sadly I
>> haven't experienced that. ...
> 
> I entirely agree that ARC isn't yet ready for prime time.  I know the
> guy who runs OpenARC and I believe he is looking for people to resume
> work, but even at the big gorillas they are not yet using it to
> fix mailing list filtering mistakes.

Arc's biggest problem is that nobody trusts it, because it's a second party 
sender.  I.e. why should gmail trust lists.foobar.org 
 to sign for microsoft.com .  
I mean, if foobar was known-trustworthy, then maybe.  (Other examples, perhaps, 
might be nanog.org , mailop, ietf, etc).

I run a fairly large mailman install at the day job, where we talk about a 
piece of open-source DNS software.  I'd like to think we're trustworthy.  We've 
had our mailing lists since before gmail existed :)

Getting openARC running, using the standard FreeBSD port was not terribly hard, 
(but could have been more straightforward, I'll admit), and we're arc-sealing 
with our existing DKIM keys, using openARC.  Those arc seals are validating, at 
least according to the validator gmail is running.

I also have commit access to the Trusted Domain Project's repositories, and 
want to do more things with this, but I am not natively a C coder.  I'm trying 
to wrangle community patches into play between github and sourceforge, get 
better documentation written, and spin up more CI infrastructure, as well as 
triage the "this needs code" fixes that someone else can review.

My current task (as you may have seen in an earlier post) is trying to get a 
version of openDKIM that supports newer encryption types into a released 
version, and that I am sure also plays nice with openSSL 3.0 (i.e. doesn't just 
stop validating sha1 because some OS packager decided anything with that algo 
is bad) and also solving any latent CVEs.  I think OpenDKIM has one, but it's 
about the test suite, which most people never run, but I'd like to fix it 
anyway.

OpenARC could certainly use more docs about where in the milter chain to put 
it, and on which machines.

-Dan

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

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Dan Mahoney via mailop]

> On Jul 23, 2022, at 01:14, Hans-Martin Mosner via mailop  
> wrote:
> 
> 23. Juli 2022 00:54, "Atro Tossavainen via mailop"  
> schrieb:
> 
>> Er, I think you mean
>> 
>> https://msbl.org/ebl.html
> 
> Yeah, basically that, except that i'm thinking of a somewhat wider scope by 
> also covering compromised mailboxes, which gets closer to the PII danger zone 
> as those woould belong to individuals more likely than the typical spammer 
> addresses which are probably controlled by spammer teams or at least have not 
> the slightest relation to the particular spammer using them.
> 
> But the presence of the EBL shows that other people think that hashed e-mail 
> addresses are reasonably safe to handle, even though they (like most BL 
> operators) prefer to stay somewhat anonymous. That's at least a partial 
> answer to my concerns.

I have several catch-all domains that have been dictionary spammed with no use, 
ever, of all the addresses but like, one.

On the same note, dayjob has several addresses, like the codesign@ and pgpkey@ 
addresses which are tied to things, and go to a mailbox, but that nobody will 
EVER subscribe to a list.  I also see a fair volume of trafic to various 
noreplys at, that I am pretty sure are NOT non-delivery notifications.

I would love a way to give those addresses (in a hashed form) to ESPs saying 
"Look, if somsone is sending to those, it's a bogus list and does not pass 
muster, and you should reject the customer".

I'd love a way to put those addresses in the DNS as a similar flag.  "Do not 
allow this address to be added to any mailing lists, promotional marketing, or 
@##$*&#ing google groups, period.  Attempts to do so are suspect".

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

Re: [mailop] Google's Request to the FEC about Allowing Political Email to Bypass Spam Filtering

[Dan Mahoney via mailop]

> On Jul 14, 2022, at 3:42 PM, Brandon Long via mailop  
> wrote:
> 
> 
> 
> On Sun, Jul 10, 2022 at 10:28 AM Andrew C Aitchison via mailop 
> mailto:mailop@mailop.org>> wrote:
> 
> On Sun, 10 Jul 2022, Anne Mitchell via mailop wrote:
> >> On Jul 9, 2022, at 8:15 PM, Brett Schenker via mailop  >> > wrote:
> >>
> >> Just put it all in quarantine. It only requires reporting on how much is 
> >> going to spam. Reporting 0 would technically be correct since quarantine 
> >> is different.
> >
> > Or a 'Political' tab, just like the 'Promotions' tab.
> 
> Wouldn't that be labelling, which would mean they need explict
> permission before enabling it for each user ?
> 
> The labeling she mentioned is from a proposed law, not one that has passed.

Yeah, like nobody ever codes against an Internet Draft. :)

-Dan___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?

[Dan Mahoney via mailop]

One more comment on this.

I got added to: 

Hi d...@prime.gushi.org,
asaccessories...@gmail.com added you to the Insights group.
Google Groups allows you to create and participate in online forums and 
email-based groups with a rich community experience. You can also use your 
Group to share documents, pictures, calendars, invitations, and other 
resources. Learn more.

If you do not wish to be a member of this group you can send an email to 
insights89+unsubscr...@googlegroups.com or follow this unsubscribe link. If you 
believe this group may contain spam, you can also report the group for abuse. 
For additional information see our help center.

I followed the abuse link, clicked the “Spam” button and got a black pop-up 
that said, simply “Failed to report group as abuse”, before disappearing a 
second later.  I did it a second time so I could screenshot it.

This is broken.

-Dan

> On Jun 16, 2022, at 11:57 PM, Cyril - ImprovMX via mailop  
> wrote:
> 
> That's a really great question and I've also experienced a ton of spam 
> comming from Google Groups I never opted in.
> 
> I followed the recommendation of Brandon Long, and at my great surprise, I 
> was in 0 groups! (despite receiving spammy emails).
> 
> Just yesterday I got one (attached here as EML), saying it came from Google 
> Group, with a link to Google group that leads to an error, and an unsubscribe 
> link (and email) that never works!
> 
> Maybe they are faking the fact that they come from Google Groups: Looking at 
> the Received headers seems to indicate it was sent from an IPv6 address 
> toward Google, that then redirect to Outlook () to finally land in my own 
> GMail address.
> 
> I don't know if this is specific to my situation but it seems closely related 
> to what this thread is about. Hopefully, sharing an EML will bring some light 
> on the issue.
> 
> Best,
> Cyril
> 
> Le jeu. 16 juin 2022 à 17:59, Dan Mahoney via mailop  a 
> écrit :
> All,
> 
> I'm getting regular spam from google groups.  (This week, it's in Arabic).  
> Since it's google groups, any abuse reports would just be devnulled.
> 
> Sender: -2040---_...@googlegroups.com
> List-Archive: <https://groups.google.com/group/-2040---__--
> Dkim-Filter: OpenDKIM Filter v2.10.3 prime.gushi.org 25GFIHZg049346
> X-Spam-Asn: AS15169 2607:f8b0::/32
> Dmarc-Filter: OpenDMARC Filter v1.4.1 prime.gushi.org 25GFIHZg049346
> X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on quark.gushi.org
> Authentication-Results: prime.gushi.org; dmarc=pass (p=none dis=none) 
> header.from=gmail.com
> Authentication-Results: prime.gushi.org; spf=pass 
> smtp.mailfrom=-2040---__--+bncbdo7v2elqijrbletvwkqmgqehrat...@googlegroups.com
> Authentication-Results: prime.gushi.org; dkim=pass (2048-bit key; 
> unprotected) header.d=googlegroups.com header.i=@googlegroups.com 
> header.b=f2HCls9/; dkim=pass (2048-bit key; unprotected) header.d=gmail.com 
> header.i=@gmail.com header.b=LDfTQwoh
> 
> Can someone please explain to me how/why a google group manager is able to 
> just add any email address and send to it?  Considering all the 
> authentication they're requiring, this seems like a gaping hole in any kind 
> of security.
> 
> Can someone also explain to me why a group name like -2040---___-- isn't 
> immediately flagged as hella suspicious?
> 
> Specifically, the email address they're sending to is: freebsd *at* 
> gushi.org, which I only use for mailing lists and bug trackers related to 
> that project.  That project does not use google groups.  It's been harvested 
> by a few other spammers, and sold a couple times, and at some point I'll move 
> it to a year-based alias.
> 
> -Dan
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> <_ _box Routines offertes pour l'achat d'une box_ 
> _.eml>___
> 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] Question for Google -- how am I able to be added to google groups without opting in?

[Dan Mahoney via mailop]

> On Jun 18, 2022, at 12:59 AM, Brandon Long via mailop  
> wrote:
> The opt-out link is https://groups.google.com/d/optout 
> 
This required adding freebsd@ as an alternate address to my profile.  I *hope* 
that does it.

> Does any other reporting method you have involve authentication of the 
> reporter?

Spamcop does, which is part of my normal workflow.  It's not perfect but it's 
the best thing we've got right now.  If you have the power to reach out to 
deputies@ and figure out how you can accept reports from them (since they are 
in standardized formats, easy for you to digest) it would be a huge leap 
forward, even if everything *else* you send to ab...@google.com gets the 
classic autoresponder that currently goes out.

>> I think that welcome message also has a link to the global settings, but it 
>> has been years since I've worked on this.  You can set the global settings 
>> from the web ui: 
>> https://support.google.com/groups/answer/9792489?hl=en&ref_topic=2458613 
>> 
>> That allows you to prevent group managers from inviting or directly adding 
>> your email address to groups.
> 
> You're telling me I have to go create a google account for free...@gushi.org 
>  (again, only for my work with that project), just 
> to stop it from being added to groups?  
> 
> Or blackhole all mail from googlegroups to that account?  What's the point of 
> using these types of usage specific email accounts if not to be able to do 
> that?

Ultimately, the result does tend to look like that, or adding it to a procmail 
rule that causes other bayesian learning to happen, or feeding it to other 
datapoints.  I just wish the possible behavior was something that made the 
originator stop thinking they've found a way to game your system.

I run some fairly popular lists relating to an open source dns server.  I have 
headaches galore every time I can't deliver to you because "someone changed 
something".  There's irony in having my users complain about that at the same 
time as I'm receiving spam from these groups.

-Dan___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Question for Google -- how am I able to be added to google groups without opting in?

[Dan Mahoney via mailop]

> On Jun 16, 2022, at 3:55 PM, Brandon Long via mailop  
> wrote:
> 
> You should get a welcome message when a user direct subscribes you to a group 
> that should have an unsubscribe link in it.  The welcome message part of the 
> flow that the group manager can set should be added to that message.

I have not gotten any welcome messages.  But from what you say, there's no 
opt-in required?  No confirmation link?

> There are limits on how many people a group manager can add in this way, it's 
> really not an efficient way to spam a lot of people, but there do seem to be 
> some low level spammers who spend a lot of resources to spam very few people, 
> and our abuse systems play a lot of wack-a-mole with them.

There's a limit per-list perhaps, but they create multiple lists, and they're 
not paying people US wages to do this nonsense.

>   I no longer have any access to look at the abuse results for this group or 
> owner.   And you can definitely report abuse on particular groups from the 
> web ui, and that is useful to us to learn and improve.

So any reports must be manual, and distinct from any other reporting method I 
may have.  You can do better.

> I think that welcome message also has a link to the global settings, but it 
> has been years since I've worked on this.  You can set the global settings 
> from the web ui: 
> https://support.google.com/groups/answer/9792489?hl=en&ref_topic=2458613 
> 
> That allows you to prevent group managers from inviting or directly adding 
> your email address to groups.

You're telling me I have to go create a google account for free...@gushi.org 
(again, only for my work with that project), just to stop it from being added 
to groups?  

This is insane.

-Dan

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

[mailop] Question for Google -- how am I able to be added to google groups without opting in?

[Dan Mahoney via mailop]

All,

I'm getting regular spam from google groups.  (This week, it's in Arabic).  
Since it's google groups, any abuse reports would just be devnulled.

Sender: -2040---_...@googlegroups.com
List-Archive: 

Re: [mailop] forwarding to gmail - problem

[Dan Mahoney via mailop]

> On May 6, 2022, at 8:14 AM, Luis E. Muñoz via mailop  
> wrote:
> 
> On 6 May 2022, at 3:48, Dan Mahoney via mailop wrote:
> 
>> If you’re already doing DKIM and SPF anyway, arc is another milter in the 
>> chain that gives you that benefit. (You want it after your DKIM and DMARC 
>> validators). You can leverage your same DKIM keys to use arc (or a different 
>> one), but it’s largely the same idea. Right now nobody is validating arc, 
>> but this is largely because nobody’s signing/sealing with it…because nobody 
>> is validating it…because nobody is signing/sealing with it….someone needs to 
>> move first.
> 
> I think there's slightly more at play. Besides "trusting" the big ones, how 
> would gushi.org know that it can trust libertad.link's ARC signatures? Or 
> posed in a different way, what prevents spammer.co to make a false 
> attestation to send spam made to look like it was sent from some innocent 
> bystander?

You’re correct here.  If you’re the i=1 arc sealer, and you apply an arc-seal 
and arc-authentication-results header that says, in effect, “yup, looked good 
to me at the time”, things will still validate, unless you drill down into the 
message and look at other things that were broken in the way forwarding is 
known to.  At that point, you can no longer validate the original DKIM 
signature (because the signed headers have been modified).

Gmail has no purported cause to trust my arc-seals on my little Vultr vm that’s 
handling my personal mail, but at the end of the day if I’m applying those 
seals, and someone else isn’t, I see my stuff as less likely to be dropped than 
the guy who isn’t.  Doing the work to set up the sealing as a “best practice” 
feels reasonable(*)

What arc DOES purport to do, is makes *forwarded* (or third-party-handled) mail 
obvious.  It changes it from “unvalidateable” to having at least one mechanism, 
which at least has a traceable path.  We hope.

I happen to run a major listserv, and I’ve turned it on.  In a system with lots 
of first-mover-disadvantages, I’ve made my move.  A 2-line question from gmail 
to bind-users now has headers for days. :)

-Dan

*(I’ve seen stuff you people wouldn’t believe. Over the years, I’ve had _adsp 
records, _domainkey policy records (i.e. domainkey with no selector), SPF 
(sometimes in addition to TXT) DNS records, hashcash signatures on my mail, 
experimenting with GPG-signing all mail, hell, there was even that one site 
that made me embed a haiku in my mail headers.  I’ve set spf -all and still got 
forged mail blowback.  This is totally whack-a-mole, hilariously in a world 
where I get more b2b spam to info@dayjob *from* the big three freemails)

> 
> How do we make this scale?
> 
> I think the response to those issues are in part the cause for the loop you 
> cleverly explained before.
> 
> Best regards
> 
> -lem
> ___
> 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] forwarding to gmail - problem

[Dan Mahoney via mailop]

Two inline thoughts.

> On Apr 30, 2022, at 4:48 PM, Ángel via mailop  wrote:
> 
> On 2022-04-29 at 10:28 -0700, Brandon Long wrote:
>> There have been other reports on this list of Gmail requiring
>> authenticated email.
>> 
>> We don't require authenticated email... but we vastly prefer it, and
>> that preference has only increased over time.  And the dkim replay
>> attacks have meant increasing the scrutiny of messages which are dkim
>> authn but not spf authn, which of course can hurt forwarding. 
>> Forwarding is getting the short end of the stick in that
>> toss up.
>> 
>> The above rejection isn't for the dkim replay case, of course, it's
>> for no authn at all.
> 
> Yep. I completely understand it's not authenticated. The problem is,
> it's out of our reach to authenticate that third party email. It's the
> recipient who wants to receive it.
> 
> 
>> SRS style rewriting allows the forwarder to get feedback if the
>> forwarding destination address goes away, > and do bounce handling...
>> and prevent bounces from going back to the original sender, exposing
>> the destination address. There are good reasons to do the rewrite,
>> but not as likely for the average procmail user, and having a good
>> spam filter that doesn't forward is very important.

What’s the threshold for not forwarding?  If a user is at some point used to 
receiving all mails, but with SA’s default score of 5 tagged with a standard 
*SPAM header, or an X-Spam-Status header, gmail should easily recognize 
that it’s a forwarding account.

There are going to be false positives to a spam filter — and what should happen 
with those?  They get not-forwarded and put in a mailbox on the forwarding 
server that the user literally never checks?  Rejected at SMTP time, for fear 
of gmail?

And then there are false negatives, which will make a forwarding server seem 
more spammy, unless *my* spam filter and *gmails* are in perfect harmony.

To the point that when I send a new mail to a gmail user, it’s routed to the 
spam folder, because “Lots of mail from prime.gushi.org  is 
spam”.  Seriously.  With nothing showing in postmaster.

There’s a couple of very standard headers that the common open source filters 
add (spamassassin, crm, dspam). Gmail could trivially recognize upstream spam 
filters (per sending-host) and act on them.   They choose not to.

[…]

>> An even better one would be ARC, it would be pretty easy to specify
>> one or more ARC ADMDs as trusted forwarders on a per-user basis (or
>> for workspace admins).
>> 
>> This suffered from a chicken/egg problem on top of the general 
>> "hard for most users to understand", and the general small usage of
>> regular forwarding...
>> the better option was to generalize the benefits of ARC to all users
>> automatically... but that work is still in progress.
> 
> ARC would indeed be a more complete solution. However, I suspect this
> may be one of those cases where perfect is the enemy of the good.
> Specially since this doesn't solve the issue of which ADMDs to trust.

If you’re already doing DKIM and SPF anyway, arc is another milter in the chain 
that gives you that benefit.  (You want it after your DKIM and DMARC 
validators).  You can leverage your same DKIM keys to use arc (or a different 
one), but it’s largely the same idea.  Right now nobody is validating arc, but 
this is largely because nobody’s signing/sealing with it…because nobody is 
validating it…because nobody is signing/sealing with it….someone needs to move 
first.

Unlike DMARC with p=reject or spf with -all, there’s no harm in adding an ARC 
signature.  There’s no DNS record that you put in ARC (other than for the 
domainkey) that says “if arc fails do this” and the ARC rfc does not extend 
DMARC to change its action.

I spent arguably an hour tweaking it and turning it on both on $dayjob’s mail 
entry points and on the sending-end of our mailman 2.x server.  If more people 
start looking at that info, we’re ready.

Right now, one of the best things gmail could do is when you say “view 
original” for a message, in addition to showing the SPF/DMARC/DKIM status at 
the top, show the arc status too, at the top of the page.  Make people more 
aware of ARC.  Gmail pushed ARC as a solution, and yet it’s not advertised to 
users as something that they should see passing.

That said, if you have a gmail account for testing, you can see the arc=pass or 
arc=fail results of mails you forward, down there in the headers.


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

Re: [mailop] forwarding to gmail - problem

[Dan Mahoney via mailop]

I've told any of my users to not forward to gmail instead, but rather to just 
use their pop-fetcher.

Two problems I had there.

1) Not a goog issue, but Microsoft effectively discontinued this feature for 
hotmail, for some reason, so it's not universal advice.

2) Gmail started hitting MTU/ipv6 issues with my system, and the error they 
presented to the user was useless (and in fact, cut off mid-sentence in the 
Google UI).  My solution was to create a v4-only hostname and v6-only hostname, 
which required reworking all my certs.

The bigger problem here is that there's no place a regular gmail or hotmail or 
($freemail) user can reach out to for help.

-Dan

> On Apr 28, 2022, at 12:58 PM, Scott Mutter via mailop  
> wrote:
> 
> Automatic email forwarders are generally a bad idea, at least in my
> humble opinion.
> 
> They're always going to fail SPF unless you rewrite the
> sender-envelope, which I also don't think is a good idea.
> 
> Ultimately, the argument generally comes down to "well, these used to
> work" and that's part of the problem.  People expect everything to
> work just like it used to - but they also want to gain all of the
> benefits of newer anti-spam/anti-phishing components.  That's just
> simply a false narrative.
> 
> I'm not sure what specific mail system the user is using, but my
> suggestion would be to set up the address to collect into a local POP3
> mailbox on the same server that's doing the forwarding.  Then
> configure your Gmail account to POP mail from that POP3 mailbox.  This
> side steps the issues of SPF failing, while also allowing the user to
> remain exclusive to their Gmail account.
> 
> On Thu, Apr 28, 2022 at 2:02 PM Brandon Long via mailop
>  wrote:
>> 
>> Are they using the suggestions on 
>> https://support.google.com/mail/answer/175365 for procmail forwarding?
>> 
>> There's a double edge sword with SPF auth for forwarding.. if you re-write 
>> the envelope sender to the forwarding address and forward spam, the 
>> forwarding domain can accumulate poor reputation.  If you don't rewrite the 
>> envelope sender, then the messages will no longer be SPF authed, and that 
>> may cause spam detection issues.
>> 
>> There's no great solution to this problem.  Theoretically, one could try to 
>> walk the line and rewrite the sender for some messages where you think it's 
>> not spam but having no auth causes issues ... though it won't work for say 
>> domains with DMARC since there has to be alignment.
>> 
>> ARC is the theoretical solution to this, where it can forward auth 
>> information, but how to handle the forwarded auth information is still a 
>> work in progress.
>> 
>> In a long ago thread, we discussed the benefits of doing both forwarding and 
>> pop fetching, to handle the edge cases.
>> 
>> Brandon
>> 
>> On Thu, Apr 28, 2022 at 11:49 AM Geoff Mulligan via mailop 
>>  wrote:
>>> 
>>> I have a user on one of my servers that uses procmail to forward messages 
>>> to their gmail account.
>>> 
>>> Every once in a while messages sent to them are "bounced" to the sender 
>>> with the error fro gmail:
>>> 
>>> 550-5.7.26 This message does not have authentication information or fails 
>>> to 550-5.7.26 pass
>>>authentication checks. To best protect our users from spam, the 
>>> 550-5.7.26
>>>message has been blocked.
>>> 
>>> How can I diagnose this???
>>> 
>>> Is it that the message sender's domain has a DMARC setting or some such 
>>> that gmail is using and that my server (which is just forwarding the 
>>> message) is failing?
>>> 
>>> If so, how is someone supposed to forward messages to gmail???
>>> 
>>> Thanks,
>>> Geoff
>>> 
>>> ___
>>> 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 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] SMTP line wrapping breaking DKIM signatures when forwarding

[Dan Mahoney via mailop]

> On Apr 26, 2022, at 10:18 AM, Robert L Mathews via mailop  
> wrote:
> 
> We've recently been getting more complaints about seemingly valid messages 
> that are rejected when we forward them. Tracking down the problem, it happens 
> when:
> 
> 1. The message that we receive from a third party has line lengths that 
> exceed 998 bytes in violation of RFC 5322 2.1.1;
> 
> 2. The message envelope sender uses SPF "-all";
> 
> 3. The message has a valid, aligned DKIM signature matching the From header 
> when it arrives;
> 
> 4. Postfix wraps the message at 998 bytes when forwarding it due to 
> ;
> 
> 5. This breaks the DKIM signature in the forwarded copy, because addition of 
> the "CR-LF-SP" changes the DKIM body hash;
> 
> 6. The forwarding destination finds no valid DKIM signature, so it uses the 
> SPF "-all" and rejects it with a message like this Gmail example: "550 5.7.26 
> This message does not have authentication information or fails to pass 
> authentication checks".
> 
> How do other people handle this problem? I've seen suggestions of simply 
> preventing Postfix from doing any wrapping, like:
> 
> https://github.com/trusteddomainproject/OpenDMARC/issues/166
> 
> It feels a little evil to just pass non-SMTP compliant messages on to others, 
> but on the other hand, changing the body of a message that has a DKIM 
> signature is clearly wrong, too.

The pedantic* answer here might be to make postfix smart enough to not apply 
this logic *if* there's a DKIM signature with simple/simple in the 
canonicalization.

Postfix itself has zero knowledge of these headers, so adding conditionals to 
tweak this would probably be more trouble than it's worth.

The only way this will pass into gmail is if postfix practices that age-old 
adage of computing: garbage in, garbage out.

-Dan

-- 

* Because you can't have pedantic without "Dan"
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Dan Mahoney via mailop]

> 
>> I am not
>> familiar with the lawsuits, but the general solution to all reputation
>> services, whether IP-reputation, consumer credit, or any other business
>> that collects information about other subjects (the building block of
>> surveillance capitalism!) is consent:  if the subject does not consent,
>> do not collect/report.  No reporting, no cause for legal action.
>> Provide reputation certificates for subjects that opt into the service
>> and let recipients decide how to deal with the absence of such
>> reputation ceritificate(s).
> 
> your unfamiliarity extends demonstrably beyond the lawsuits. if you choose to 
> do some research and ask some informed questions, i'd love to hear them and 
> try to engage further.

This will be off-topic for mailop, but…I remember Vixie giving a talk at 
MeetBSD, at the same moment that I found out that the latest-at-the-time 
equifax breach had exposed my information a few years back.

I would LOVE there to be legal structure to say “Gee, Equifax, you failed to 
demonstrate the basic opsec of paying some junior admin to type `yum upgrade 
apache-struts`, so you don’t get to keep my PII anymore.”  I would love if 
there was an option to simply put a flag on my SSN that says “gather/sell no 
data” to any of the dozens of agencies that harvest this (radaris et al) and 
package it up neatly.  

This is not the place to get into what dystopias being able to fully “opt out”  
would lead to, except that in either case (IP or PII), a lack of fingerprint 
would surely also be regarded as suspicious and approached with gated, minimal 
trust, if any at all.  

More on topic, however:

Consent or no, for all the intelligence sources you know about (on mxtoolbox’s 
multi-rbl checker, etc), there are dozens, possibly hundreds more, private 
ones.  Some in a manually maintained DB, some in a bayesian statistical DB 
based on how likely your domain is to spam based on email volume and SPF/DKIM 
records, and some that model way more data that you can imagine, that only 
exist in the mind of an AI that’s completely opaque, even to the people that 
coded it.

I strongly believe one such black box exists inside G, and that it's not the 
only place.

The best thing you can do is learn the correct inputs to the black box, at the 
time.  Build your own statistics of what your netblock is doing, and actually 
read and report on them before someone else does.  Email is no longer “set it 
and forget it” and hasn’t been for decades or more.

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

[mailop] Deep dive into the dayjob's mail servers and SPF/DKIM tightening

[Dan Mahoney via mailop]

Dayjob (you know who) has been doing DKIM/DMARC for a few years now, but at the 
hinting of some knowledgeable users on this list, there were a few discoveries 
we made.  

We use dmarcian, and I also dogfood the same service for my personal domain.  
They’ve been good to us and were involved in the standards process.

Here’s a few discoveries I’ve found in the process of trying to 
torque-every-bolt to spec.  It is a long-tail problem.  Maybe these things will 
help you, too.

1) Our dmarc reports themselves were not being DKIM signed.  In postfix land 
this is because there’s a different milter setting for things that call the 
sendmail command line, than that for things that talk on 25.

2) There are some people on our mailman lists who are probably forwarding their 
stuff to freemail providers.  This makes our domain name look 
frequently-spoofed, and it makes their IPs look like frequent spoofers of that 
domain.  My guess is that they’re doing some procmail/formail thing that breaks 
the DKIM signatures.  ARC-sealing would not help this, at least on our end.  
The forwarders would have to do the arc-sealing.  I can “fix" this problem by 
setting p=reject, but I’ve attempted to reach out to them instead :)

3) SPF records can get really tangly.  We at one point had a /16, and that was 
causing some not-ours-anymore IPs to be listed under our administrative control 
in postmaster tools.  (Does that mean a new owner of those ips was spoofing our 
domain specifically?  I don’t think so). 

3a) In narrowing that down to discrete blocks, I finally had to (“break out “ 
my spf record ” “to multiline format") in my zone file which does afford some 
readability benefits and make version control a little easier, but there’s 
still theoretical max-length rules, and max-lookup rules to be aware of.

4) China just sends a metric ton of garbage, some of it with made-up 
subdomains.  It caused me to go through the various sending subdomains we *do* 
have, make sure they had their own dmarc policies, then drop a sp=reject at the 
root domain.

5) Our mailman list was only signing things from its own lists.foo.org 
 subdomain (it delivers directly, not via our border 
MX).  While it’s a minor abuse of power to have us sign anything from our 
domain, we also post to and participate on those lists *a lot*, so 
percentage-wise, this affects IP reputation quite a bit. (SPF always passes 
which is an equal "abuse of power").  

5a) For this, the correct solution *would* be getting openarc running so 
everyone not under our domain can benefit from it.  Dmarcian and friends don’t 
give me much visibiity into how our arc sealing of other domains is being 
respected, since they’re not our administrative domains.

-Dan___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] $GOOG

[Dan Mahoney via mailop]

[Note that I'm replying to add a datapoint or two to this whole thread, rather 
than to just one person's comments.  (The in-reply-to header has to be set to 
something, it might as well be the first post).]

To add to a long (looong) thread, let me add something indecipherable, but it 
requires looking at an image from google postmaster tools:

https://imgur.com/a/BSANX0s 

According to this graph, for the past many, many days, we've had 100 percent 
SPF and DKIM compliance with all messages we send.

But by the same graph, our dmarc compliance is all over the place.  DMARC has 
no headers it adds to outbound mail, our record hasn't changed in months.  If 
*either* SPF or DKIM validate 100 percent of the time, my DMARC should also be 
100 percent, no?

Is this because some machine under (our org) is sending invalidated mail for 
other domains, but for all mail received with a From: header of that org, 
everything looks good?  (Like a listserv would do).

If so, that's graphing two RADICALLY different things on the same misleading 
graph.  (Also, the graphing algo hides the dmarc line behind the SPF line, 
c'mon google, you're smart enough to figure out how to overlap those lines 
visibiy).

If this is our mailman lists causing this stupidity, does it make sense to 
stuff those under a secondary domain and a distinct /24 and /48?  

==

Related, looking at dmarcian, we're having a bunch of chinese ipv4 addresses 
spoof us and attempt to send to google, but those also fail SPF *and* DKIM.  
We're a very old (older than gmail), short-named domain so it might make us 
attractive, but *none* of that spoofing shows in that google graph either.

(https://imgur.com/a/nxrSMIK )

I'm trying to play the correct game here, but Google postmaster tools shows no 
ipv6 addresses when I click on "ip reputation", and until the issues a month 
ago, that was all we did.  We've been dual stack for over a decade (although 
gmail hasn't).

Things simply do not correlate.

-Dan

> On Apr 13, 2022, at 2:43 PM, Paul Vixie via mailop  wrote:
> 
> it's troubling me that in a recent thread asking where to host mailboxes, 
> google was recommended several times, in spite of the fact that google is 
> provably wrong and provably non-transarent in how they decide what inbound 
> e-mail to reject.
> 
> of all constituencies, this one, mailop, is one i would have expected to know 
> better than to cooperate with your oppressor.
> ___
> 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] Can someone from google/gmail contact me offlist?

[Dan Mahoney via mailop]

Day Job (ISC.org) is having delivery issues to gmail due to our “very low” 
reputation.  I call shenanigans.

Mar 30 07:21:58 post postfix/smtp[75122]: D7B673AB008: 
to=, 
relay=gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b]:25, delay=1.7, 
delays=0.31/0/0.85/0.52, dsn=5.7.1, status=bounced (host 
gmail-smtp-in.l.google.com[2607:f8b0:400c:c14::1b] said: 550-5.7.1 
[2001:4f8:0:2::2b  19] Our system has detected that this message 550-5.7.1 
is likely suspicious due to the very low reputation of the sending 550-5.7.1 
domain. To best protect our users from spam, the message has been 550-5.7.1 
blocked. Please visit 550 5.7.1  https://support.google.com/mail/answer/188131 
for more information. c8-20020a056102318800b003255333019bsi4904938vsh.501 - 
gsmtp (in reply to end of DATA command))
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sorbs DNS problems

[Dan Mahoney via mailop]

> I collect related NS records and try to ping them from another IP
> (different ISP), to be sure that they are not blocked by me nor by my
> ISP, and results corresponds with my experiences:
> 
>ns0.sorbs.net. 113.52.8.11 ping fail
>ns2.sorbs.net. 87.106.246.125 ping fail
>ns4.sorbs.net. 78.153.202.24 ping OK
>ns5.sorbs.net. 72.12.198.241 ping fail
>ns1175.dns.dyn.com. 108.59.166.201 ping fail
>ns2174.dns.dyn.com. 108.59.168.201 ping fail
>ns3179.dns.dyn.com. 108.59.170.201 ping fail
>ns4151.dns.dyn.com. 108.59.172.201 ping fail
>ns9.sorbs.net. 169.48.121.207 ping OK
>rbldns10.sorbs.net. 185.87.186.55 ping OK
>rbldns7.sorbs.net. 88.208.216.85 ping fail
>rbldns0.sorbs.net. 113.52.8.50 ping fail
>rbldns17.sorbs.net. 210.50.3.173 ping fail
>rbldns3.sorbs.net. 74.208.146.124 ping fail
>rbldns16.sorbs.net. 74.53.186.252 ping fail
>rbldns8.sorbs.net. 89.150.195.2 ping fail
>rbldns4.sorbs.net. 78.153.202.22 ping OK
>rbldns15.sorbs.net. 87.106.246.154 ping fail
>rbldns2.sorbs.net. 72.12.198.247 ping OK
>rbldns18.sorbs.net. 72.12.198.248 ping OK
>rbldns14.sorbs.net. 194.134.35.168 ping fail
>rbldns12.sorbs.net. 74.208.146.124 ping fail
>rbldns13.sorbs.net. 113.52.8.157 ping fail
>rbldns6.sorbs.net. 194.134.35.204 ping fail
>rbldns1.sorbs.net. 78.153.202.21 ping OK
>rbldns11.sorbs.net. 216.12.212.155 ping fail
>rbldns9.sorbs.net. 169.48.121.206 ping OK
> 
> As any can see, some responds, and some not...
> 
> I do not know, if they are not accessible or have ICMP blocked, but i
> will expect, that if they block ICMP, they will block all not only some
> hosts.

Why are you instead not doing a dig against these ips?  It's clear you 
understand that ICMP may be blocked, so why not use a check method that 
actually uses the protocol you'd use to query them?

-Dan


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

Re: [mailop] not a way to do abuse contacts, What am I supposed to do with abuse complaints on legit mail?

[Dan Mahoney via mailop]

> On Jan 17, 2022, at 11:06 AM, John Levine via mailop  
> wrote:
> 
> It appears that Grant Taylor via mailop  said:
>> 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?
> 
> This idea has been floated before and misses the point.
> 
> It is quite simple to use RDAP to get the abuse contact email for
> anyone who has provided the info to their RIR.  I do it all the time.
> The problem is that too many operators don't bother.  If they don't
> tell the RIR, they are not likely to spend effort putting extra
> stuff in their rDNS.

What do you do when abuse complaints are just observably bounced or blackholed, 
and not accepting email from gma^W that provider isn't an option?

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

Re: [mailop] Privacy research spam apparently from a grad student at Princeton

[Dan Mahoney via mailop]

Which domain?  Feel free to encode it out as need be.

> On Dec 14, 2021, at 6:49 PM, John Levine via mailop  wrote:
> 
> It appears that Simon Arlott via mailop  said:
>> On 14/12/2021 18:53, John Levine via mailop wrote:
>>> I think this is different and really is a botched survey from a grad 
>>> student.  Poking
>>> around his department's web site, it seems like the sort of stuff he is 
>>> interested in.
> 
> I heard back from the student.  It's real, he thinks spamming scraped 
> addreses is dandy.
> 
> 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] Privacy research spam apparently from a grad student at Princeton

[Dan Mahoney via mailop]

We saw similar at the dayjob:

To Whom It May Concern:

My name is Mary Clark, and I am a resident of Roanoke, Virginia. I have a few 
questions about your process for responding to General Data Protection 
Regulation (GDPR) data access requests:

Would you process a GDPR data access request from me even though I am not a 
resident of the European Union?
Do you process GDPR data access requests via email, a website, or telephone? If 
via a website, what is the URL I should go to?
What personal information do I have to submit for you to verify and process a 
GDPR data access request?
What information do you provide in response to a GDPR data access request?
To be clear, I am not submitting a data access request at this time. My 
questions are about your process for when I do submit a request.

Thank you in advance for your answers to these questions. If there is a better 
contact for processing GDPR requests regarding dayjob.org, I kindly ask that 
you forward my request to them.

I look forward to your reply without undue delay and at most within one month 
of this email, as required by Article 12 of GDPR.

Sincerely,

Mary Clark


> On Dec 14, 2021, at 12:13 PM, Simon Arlott via mailop  
> wrote:
> 
> On 14/12/2021 18:53, John Levine via mailop wrote:
>> I think this is different and really is a botched survey from a grad 
>> student.  Poking
>> around his department's web site, it seems like the sort of stuff he is 
>> interested in.
> 
> The way the content is phrased makes them almost identical.
> 
> Either:
> 1. The scam emails are really a version of the survey but using fake
>   names and domains.
> 2. The scammers are now using this researcher's name to make it appear
>   legitimate.
> 3. The researchers have copied the "scam" text.
> 
> I've had similar spam from the "CISPA Helmholtz Center for Information
> Security and Ruhr-University Bochum in Germany" that looks legitimate
> albeit misguided in believing that it's appropriate to email abuse@ on
> every website they think lacks a privacy policy.
> 
> -- 
> Simon Arlott
> ___
> 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] Gmail rejects multiple From:'s. Who else?

[Dan Mahoney via mailop]

> On Dec 13, 2021, at 1:55 PM, Vsevolod Stakhov via mailop  
> wrote:
> 
> On 13/12/2021 17:19, Alessandro Vesely via mailop wrote:
>> Hi,
>> I assume everybody knows that RFC 5322 allows multiple mailboxes in the 
>> From: field.  This feature existed in RFC822 already.  I think it is to be 
>> used for those cases where multiple persons are authoring a message, albeit 
>> adding the list of coauthors is usually not done.  This message is an 
>> example.  How many rejects does it yield?
>> Gmail reacts like so:
>> Action: failed
>> Status: 5.0.0
>> Remote-MTA: dns; gmail-smtp-in.l.google.com [108.177.119.27]
>> Diagnostic-Code: smtp; 550-5.7.1 [192.0.2.4  13] Messages with multiple 
>> addresses in From:
>> 550 5.7.1 header are not accepted. do22si22787062ejc.211 - gsmtp
>> Is it customary to reject messages with multiple addresses in From:?  Why?
>> Best
>> Ale
> 
> 
> This is a clear case where RFC is wrong and bogus when one takes into 
> consideration other Internet standards, for example DMARC or even DKIM. There 
> is also a clear way to implement the behaviour you've described without such 
> a violation: just add a Reply-To header with multiple addresses.
> 
> Rspamd has a high score rule to penalize messages with multiple from, as I've 
> seen just spam with multiple from headers in practice like other people in 
> this mailing list.

Yeah, the university edge-case was one I could think of where for 
academic/journalistic reasons both a student and professor would be 
co-authoring/co-publishing a thing.  (Naming order is distinct enough (and 
matters) in that field, but I'll totally admit it's an extreme outlier).

-Dan

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

Re: [mailop] Gmail rejects multiple From:'s. Who else?

[Dan Mahoney via mailop]

> On Dec 13, 2021, at 9:44 AM, Slavko via mailop  wrote:
> 
> Signed PGP part
> Hi,
> 
> Dňa Mon, 13 Dec 2021 18:19:07 +0100 Alessandro Vesely via mailop
>  napísal:
> 
>> Is it customary to reject messages with multiple addresses in From:?
>> Why?
> 
> AFAIK, DMARC works with only one From: address, thus sites which
> are verifying DMARC tends to reject multiple addresses in it.

Dmarc works with multiple froms only in the case where the froms are in the 
same sending domain.

https://github.com/trusteddomainproject/OpenDMARC/blob/master/SECURITY/CVE-2019-16378

-Dan

> 
> regards
> 
> -- 
> Slavko
> https://www.slavino.sk
> 
> 

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

Re: [mailop] Bro, do you even VERP?

[Dan Mahoney via mailop]

> On Nov 7, 2021, at 7:18 AM, Larry M. Smith via mailop  
> wrote:
> 
> On 11/6/2021, Dan Mahoney (Gushi) via mailop wrote:
>> All,
>> I have email for my whole domain.  I'm typically known to sign up for 
>> services with vendor@mydomain, so that when an email gets retired or leaked, 
>> I route it to /dev/null, or in the event of a leak, retire it from the 
>> original place (say, ad...@mydomain.com) and auto-route it to spam reporting 
>> and bayes learning.
>> One of my older ones: d...@mydomain.org was a general purpose one, and thus 
>> for that one, rather than just routing it straight to sa-learn, I put in an 
>> autoresponder saying "the spammers won this address, if you really want to 
>> contact me, use this".
>> Here's the thing though.
>> Spam is coming to me with VERP'ed addresses.  It's getting autoresponded to. 
>>   Those autoresponses are then bouncing back to me as undeliverable.
>> So...you're a spammer.  You're going to the trouble to do VERP.  You're 
>> throwing the responses on the ground, or even blocking their receipt.  Or 
>> your VPS got suspended (which I'm sure you saw coming).
>> What's the bloody point here?  I mean, I know there doesn't have to be one, 
>> buy I'f love to hear ideas as to what the possible use case is.
>> I mean, logically, one thing I could do is have my autoresponder detect the 
>> verp'ed format to this address specifically, and not attempt to respond to 
>> it (and in fact, I could report on/train on it).
>> The autoresponder is for legitimate humans trying to contact me directly 
>> (i.e. nobody who will use verp).  In the few years since I realized this 
>> address was a lost cause, nobody's tried.  (Although I have started getting 
>> spam at gushi2015@domain, so that's some intelligence).
> 
> You might find a better operational experience by just rejecting the messages 
> in SMTP post DATA with a URL for a whitelisting web page.  E.g.;

I got the suggestion to reject at SMTP time from two different people.  I’ve 
been running mail for 20+ years now, and there was logic to why I didn’t.

I can’t control the subject of nondelivery reports.  Worse, nontechnical users 
do not know how to read non-delivery reports.  (Ask me how I know).  In my 
initial message, I had said that some number of people used this address 
(remember, the LHS was danm@ not somecompanyname@).

Ergo, I wanted to give some amount of time where mail would still come through 
(and be captured) versus an outright reject.  Thought did go in to this, 
really.  My logic is “never reject when you can use it to feed spamtraps”. :)

-Dan

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

Re: [mailop] Reporting/detecting google groups spam

[Dan Mahoney via mailop]

> On Oct 18, 2021, at 1:02 PM, Atro Tossavainen via mailop  
> wrote:
> 
> On Sun, Oct 17, 2021 at 01:04:53PM -0700, Dan Mahoney (Gushi) via mailop 
> wrote:
>> All,
>> 
>> For years now I've been the target of a number of resumes from
>> UAE-based google-groups.
> 
> Have a look at these two things.
> 
>  https://www.spamhaus.org/rokso/spammer/SPM1559/syedsmarketing
> 
>  
> https://www.spamhaus.org/rokso/evidence/ROK13034/syedsmarketing/10-2021-group-uae

Yup, definitely them.  Any way I can aid in reporting this stuff more 
efficiently?  (Note this is my personal AS, not the dayjob's, but we're both no 
strangers to fighting the good fight).

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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dan Mahoney via mailop]

I will say, as a data-point, that dayjob has had one customer that required us 
to use a CA for our SMTP server that’s on a whitelist-approved by a certain 
automaker industry consortium.  To the point where when they decided they 
couldn’t communicate with a secure SSL cert (even though SSL was there), they 
started faxing us their tickets.

I can imagine other industries requriring the same.

What’s annoying is that some commercial CA’s are just barely starting to 
support ACME, and it’s not as reliable/well-documented/transparent as the free 
stuff.

> On Oct 16, 2021, at 12:10 AM, Grant Taylor via mailop  
> wrote:
> 
> On 10/15/21 11:54 PM, Michael via mailop wrote:
>> Remember, each lookup against Let's Encrypt shares information, that can be 
>> resold.
> 
> What is different for a CA that a certificate is purchased from?
> 
> 
> 
> -- 
> 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] Google Postmaster Tools - No data since October 4th

[Dan Mahoney via mailop]

> On Oct 13, 2021, at 12:11 PM, Alex Irimia via mailop  
> wrote:
> 
> Hello all,
> 
> Anyone here from Google who can unplug GPT and plug it back in?
> It seems to have stopped working on October 4th.

Alex, your post reminded me:

I have *never* seen any data in my postmaster tools, FWIW, and google’s docs 
are silent as to the threshold.  

But still, messages I send people get auto-routed to spam folders because “Lots 
of mail from prime.gushi.org  is spam”.

If someone knows what one can do about this, please do let me know, here or 
offlist.___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC and pure SPF

[Dan Mahoney via mailop]

> On Oct 4, 2021, at 3:24 AM, Slavko via mailop  wrote:
> 
> Signed PGP part
> Hi,
> 
> please i want to ask how to deal with pure SPF when DMARC is in use. I
> understand how to deal with SPF within DMARC checks and i do not want to
> diskuss this.
> 
> But what if domain owner specify eg. -all (or ~all) and SPF check
> against SMTP.From (or EHLO) fails (or softfails) with this rule?

RFC7489 Section 10.1 makes a caveat of this very thing.  If you're specifying a 
dmarc policy for your domain that suggests that users who ONLY check SPF should 
reject on this case, there's no good way to tell a site that uses SPF *AND* 
DKIM to evaluate them separately.

> Have i (my MTA) follow this rule (respect domain owner) and reject
> (mark) mail without taking DMARC policy into account. Or have i make
> decision only based on DMARC result AND policy and ignore pure SPF
> checks at all?
> 
> AFAIK, even when SPF in DMARC fails, there still can be DMARC success
> with DKIM and this can leads to ignore SPF -/~all. I am confused...

In general, if you're publishing a DKIM record, then you acknowledge that there 
are cases where SPF will not be enough (relays, mailing lists, etc).  So 
setting -all is probably a good idea.

That said, if you are ONLY publishing SPF records, then maybe you really want 
-all.

Note as well that some systems just use SPF as a metric (say, as part of 
SpamAssassin) and don't use it to reject at transaction time.

Note as well that OpenDMARC at least has the ability to both do its own 
evaluations *or* trust a header added by an earlier milter.

-Dan

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

Re: [mailop] Gmail users on mailing lists

[Dan Mahoney via mailop]

> On Sep 24, 2021, at 12:49 AM, Gregory Heytings via mailop  
> wrote:
> 
> 
> Apparently Gmail is now using very strict rules for replies sent to both the 
> mailing lists and the OP (aka Reply to all):
> 
> to=<...>, relay=alt1.gmail-smtp-in.l.google.com[142.251.9.27]:25, 
> delay=73156, delays=73155/0.04/0.56/0.17, dsn=4.7.28, status=deferred (host 
> alt1.gmail-smtp-in.l.google.com[142.251.9.27] said: 421-4.7.28 
> [95.142.160.155 15] Our system has detected an unusual rate of unsolicited 
> mail originating from your IP address. To protect our users from spam, mail 
> sent from your IP address has been temporarily rate limited. Please visit 
> https://support.google.com/mail/?p=UnsolicitedRateLimitError to review our 
> Bulk Email Senders Guidelines. dz15si5588101edb.601 - gsmtp (in reply to end 
> of DATA command))
> 
> I got this on the first mail I sent when I replied to a message posted to a 
> mailing list by a Gmail user.  I'm the only user of that server / IP address, 
> and it was the first email I sent to a Gmail user in a few days, so I smiled 
> when I read "an unusual rate of unsolicited mail".

And yet I routinely find myself added to new-every-week UAE google-groups that 
send me hiring spam.

They'll block you for "sending lots of spam" but it'll show nothing in their 
webmaster API.

And good luck contacting them.

They really don't practice what they preach.

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