Re: [mailop] Suggestions for medium performance mail server

[Al Iverson via mailop]

If it were me, I'd probably investigate Kumo MTA, it's open source,
good for bulk senders, and the peeps behind it are known members of
the email community/M3/etc. https://kumomta.com/

Dunno if it'll do everything you need, but it immediately clicked for
me as sounding the closest to what you might need.

Amazon SES works pretty well, too, but there would be ongoing costs
incurred, of course.

Cheers,
Al

On Mon, Apr 7, 2025 at 12:25 PM John Levine via mailop
 wrote:
>
> I'm consulting for a non-profit that needs to upgrade its mail system. They 
> send
> about 100,000 messages a day, a combination of a nightly update message that
> people can subscribe to, and transactional mail reporting when things happen.
> There's no discussion lists, and the inbound mail is a relative trickle,
> adequately hosted at Google. The mail stream is very clean and most of the
> complaints we get are people asing where's my nightly update when the job that
> creates them burps.
>
> It's currently running through an old sendmail server but surely we can do
> better than that. What should I use? We particularly want good logging so when
> someone asks why didn't I get my update we can tell them without grepping
> through a whole day's logs. We also have problems of people signing up with 
> fake
> addresses so I need to be able to collect signup confirmation failures fairly
> quickly and turn off the corresponding accounts. (Yeah, I know about sending a
> message with a link, but people use throwaway address places that work for a 
> day
> and then stop.)
>
> I have a place to host a VPS and send mail which is not Google or AWS or Azure
> so that's not a problem.
>
> TIA,
> John
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



-- 

Al Iverson // 312-725-0130 // Chicago
http://www.spamresource.com // Deliverability
http://www.aliverson.com // All about me
https://xnnd.com/calendar // Book my calendar
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Uptick in Microsoft marking Wikimedia Foundation email as spam

[Jesse Hathaway via mailop]

We are seeing an uptick in our email from the Wikimedia Foundation being
marked as spam by Microsoft. If someone from Microsoft would be able to
provide me some insight as to why, that would be much appreciated.
Alternatively, if someone has a Microsoft contact they could share that
would also be helpful. Yours kindly, Jesse Hathaway
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Suggestions for medium performance mail server

[Viktor Dukhovni via mailop]

On Mon, Apr 07, 2025 at 01:21:44PM -0400, John Levine via mailop wrote:

> We particularly want good logging so when someone asks why didn't I
> get my update we can tell them without grepping
> through a whole day's logs.

For timely delivery status info, I'd recommend enabling VERP and having
the sending process request each of success, delay and failure
notification on delivery attempts, then just parse and feed the reports
into a database.  This approach is logging infrastructure and
MTA-independent, but that said Postfix can help fill some gaps, because
it can simulate the client requesting DSN and VERP if for some reason
the actual client can't.

Postfix can also be easily configured to not defer success DSNs to a
remote system by ignoring the DSN keyword in the remote EHLO.  Any
handoff to the domain's MX is then reported as a successful transfer of
responsibility to the recipient's domain, what happens after that is
their problem.

smtp_discard_ehlo_keywords = DSN,silent-discard
# For processing return traffic to VERP sender addresses
recipient_delimiter = +

# No implicit propagation of per-domain policy to sub-domains
parent_domain_matches_subdomains =
# Internal forwarded domains...
# Use of a separate "relay" transport avoids inbound delays if
# output is for some reason congested.
relay_domains = internal.example, ...

At ~100,000 messages per day performance is not a concern, this is very
modest volume.

> We also have problems of people signing up with fake addresses so I
> need to be able to collect signup confirmation failures fairly quickly
> and turn off the corresponding accounts.

These can use a separate envelope sender, and separate database tables,
and perhaps the code handlign receipt of the delivery notifications can
take immediate action as well as recording the status in a database.

Though of course some systems tempfail (4XX) invalid addresses, and
then it is less clear whether to immediately drop the account, but
perhaps for signup that's good enough???

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

Re: [mailop] Emails from my domain [redacted] apparently being dropped after successful delivery to ProofPoint.

[Mark Alley via mailop]

He's all set, handled off-list.

- Mark Alley

On Wed, Apr 9, 2025, 6:54 PM joemailop--- via mailop 
wrote:

> Hello All,
>
> I was wondering if anyone from ProofPoint might be around to assist with
> deliverability issues for emails coming from my [redacted] domain going to
> more than a few ProofPoint hosted customers, both enterprise and essentials.
>
> I've checked the IP reputation lookup, but our outbound email shoot out
> O365 and while /maybe/ there's an IP or two that could be stinky, this has
> been going on for a few weeks now and every email we send basically comes
> out of a different O365 IP, so we're thinking this is some type of domain
> reputation issue?
>
> Replies off-list are preferable.
>
> Best regards,
> -joe
>
> ___
> 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] Fwd: Validity (return path blocklist)

[Seth Mattinen via mailop]

On 4/4/25 17:48, Tom Bartel via mailop wrote:

Peter,

Thanks for this thoughtful response - it is good feedback and we'll take 
it to the team here to discuss.


If anyone else has similar input on cut line for a non-commercial usage, 
we'd love the input.



Queries to the certified list should be free at any volume if you're 
charging them to be on the list in the first place instead of double 
charging to be on it and charging everyone else to check it.


Beyond that, death by a thousand subscriptions is tiring.

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

Re: [mailop] Suggestions for medium performance mail server

[Marco Moock via mailop]

Am 07.04.2025 um 13:21:44 Uhr schrieb John Levine via mailop:

> It's currently running through an old sendmail server but surely we
> can do better than that.

What is bad with that?

> What should I use? We particularly want good logging so when someone
> asks why didn't I get my update we can tell them without grepping
> through a whole day's logs.

What is the problem with that?

> We also have problems of people signing up with fake addresses so I
> need to be able to collect signup confirmation failures fairly
> quickly and turn off the corresponding accounts. (Yeah, I know about
> sending a message with a link, but people use throwaway address
> places that work for a day and then stop.)

Can you move that to mail-only subscription?
You could then make SPF/DKIM mandatory to avoid forges.

Every web form can be used with forged addresses (such attacks are
common).

-- 
Gruß
Marco

Send unsolicited bulk mail to 1744024904mu...@cartoonies.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Attention Mimecast - you are sending DMARC reports with duplicate report id

[Daniel K. via mailop]

Sending it here, since postmas...@mimecast.com does not accept mail from
me; I'm not on the allowed-list. I hope someone from Mimecast can look
at this, or forward it to the correct place.

Do not hesitate to contact me directly if you need more info.


First, thank you for changing to send gzipped files, as required by the
RFC, instead of zipped ones.


In the past few days I've received DMARC reports on behalf of our
customers with a previously seen report-id.

Eg.:

0044873f58cedf992dbd9fcb6cac4d985dbcf8e5cef3ffd6fa43c0f17081d9cc
previously seen on 2023-12-07

21bce24721b306266789789e9919fbfe118e60125eb435743c5b2b5336fb6b5b
previously seen on 2024-11-25

8573f4fe0518067c7282be6b932693e4020797a0386eeb63da447734158ebd07
previously seen on 2024-12-06

Can you please look into having it be random, as it is supposed to be
unique among reports to the same domain.


Further, the extra contact info in your DMARC reports point to:

  https://community.mimecast.com/s/knowledge

a nonexistent page.


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

[mailop] Handling certificate expiration (Was: Re: Google and Spam detection)

[Mark Milhollan via mailop]

On Mon, 7 Apr 2025, Klaus Ethgen wrote:


With this Lets-Encrypt-stuff comes that the certificate needs to be
replaced every 3 Months. I do not have all the time to replace them that
often.


FYI, it seems likely that all certificate issuers will change to short 
intervals as well, gradually down to 47 days by 2028, suggesting that by 
that time automation will be all but required.  Mainly it is for 
browsers but that would force some senders to go along if their 
receivers began rejecting expired certificates or those that exceed the 
limit (e.g., self-signed for 10 years), which seems almost certain due 
to the underlying tooling being primarily browser focused.



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

Re: [mailop] Handling certificate expiration (Was: Re: Google and Spam detection)

[Viktor Dukhovni via mailop]

On Mon, Apr 07, 2025 at 12:47:33PM -0400, Bill Cole via mailop wrote:
> On 2025-04-07 at 09:38:56 UTC-0400 (Mon, 7 Apr 2025 06:38:56 -0700 (PDT))
> Mark Milhollan via mailop 
> is rumored to have said:
> 
> > Mainly it is for browsers but that would force some senders to go along
> > if their receivers began rejecting expired certificates
> 
> It is exceedingly rare for senders to use *any* certificate in a SMTP TLS
> session. Very few servers request them and they are not needed for
> encrypting traffic.

The OP is suggesting that servers would need to set short expiration
times even on self-signed certs, ...  Some sort of server cert is almost
always required to use TLS with SMTP, use of anonymous ciphers (TLS <= 1.2),
or raw public keys (RFC7250) is relatively rare (Postfix to Postfix when
TLS 1.3 is not supported would be the bulk of anon-TLS traffic).

In Postfix, with DANE "3 1 [12]" records and OpenSSL 3.2 or later, raw
public keys are used, and the certificate is replaced by just the
enclosed public key, any expiration date is then never communicated
to the client.

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

Re: [mailop] Fwd: Validity (return path blocklist)

[Simon Wilson via mailop]

Hi Andy,

On Thursday, April 10, 2025 07:05 AEST, Andy Smith via mailop 
 wrote:
 
Hi,

On Fri, Apr 04, 2025 at 11:29:58AM +1000, Simon Wilson via mailop wrote:
> as there was discussion back in November about Validity's usefulness
> on this list am posting it here too.

What bothers me more than Validity's decision to reduce their free
offering to 10k queries per month is the fact that I have so far
received three almost entirely content-free emails from a salesperson
there urging me to "book some time on [their] calendar" to discuss
giving them money.

I will also note that each of those emails comes with an unsubscribe
link at the bottom, which I have used multiple times now, and this
hasn't so far stopped the emails coming.

I did not sign up with Validity to become a sales lead, I did so because
they were providing a free service and I agreed that that it was
reasonable for them to have contact details of their users in order to
manage it properly. I realise I was extremely naive to believe this was
ever an operational relationship but it has certainly stopped being one
now, and I would like to get off that ride.

It is this which will forever leave me with bad memories of Validity,
not them deciding they can't actually justify providing free services
any more.

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
 
I was encouraged when they interacted with the list emails, but that has gone 
silent since Saturday, and my direct request for information has also gone 
unanswered.
I've disabled the Validity lookups.
Simon.
-- 
 Simon Wilson
M: 0400 121 116
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Looking for connection logs

[Ferris, Rhys (SAA) via mailop]

Hello friends,

I'm looking for anyone who may have some logs connecting to just one of our 
servers that would be willing to share them.
Specifically:
V-ICO-PPMX1.senate.gov
Samples between
Between 07:30 and 09:30 EDT
As well as
Between 10:00 and 13:30 EDT

Feel free to connect off list.

Thanks,
Rhys (R-ee-s) Ferris
Senior Systems Engineer
Identity and Collaboration Operations (ICO)
United States Senate, Sergeant at Arms
rhys_fer...@saa.senate.gov


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

Re: [mailop] Google and Spam detection

[Alessandro Vesely via mailop]

On Mon 07/Apr/2025 21:28:24 +0200 Jaroslaw Rafa wrote:

  But if I*would* check
SPF, and I would notice a large number of SPF failures for some domain which
would seem to be legitimate mail, I would just either ignore "-all" or
ignore SPF completely for that domain.



Read Appendix D of RFC 7208.  Dnswls provide for such a wide range of options 
between -all and ~all...



Best
Ale
--




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

Re: [mailop] Google and Spam detection

[Klaus Ethgen via mailop]

Hi,

Am Mo den  7. Apr 2025 um 11:02 schrieb Jaroslaw Rafa via mailop:
[Automatisation of short term SSL-Cert replacement]

I am aware of scripts and tools to renew the certificates. But I refuse
to let such tools change some security stuff like certificates. Letting
them do that stuff I could likewise drop it completely. It is a complete
bankruptcy. (I hope to use that word the right way.)

I do not want to start a discussion about the foll of the current SSL
infrastructure. It is broken by design and all that stuff like short
running certificates or CAA makes it even worse.

The only solution for that would be TLSA but browsers boycott that
approach as it would render all that commercial CA needless.

In context of mail we have DANE, which is basically TLSA. So fine for
that area.

> > I have a very accurate SPF. But I refuse to use any other than `-all` as
> > without it, it would make SPF useless! I never ever want any other host
> > to send mails in my name!
> 
> I hope you are well aware of the consequences (eg. that this does break
> forwarding) and accept them.

I am.

Currently there are some ways around that. As SPF is only caring about
the envelope sender, it is enough to change that by the forwarding
system. Another system is SRS.

SPF without -all is technical useless.

By the way, I did not mean DKIM changing the meaning but DMARK. DMARK
does validate the From-header with SPF what is REALLY breaking forwards.

> > >  * Don't do sender callout verification to SMTP servers which aren't
> > >yours.
> > 
> > Why not?
> 
> Because many receiving servers now consider this as malicious activity and
> will put you on the blocklists if you do this.

Until now it didn't but I will think about that. Thanks.

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop