Re: [mailop] Mailserver software

[Chris Adams via mailop]

Once upon a time, John Levine  said:
> The usual suggestions are postfix and exim.  Exim has somewhat more
> built in, e.g., DKIM signing, postfix seems somewhat more popular.
> Both are well supported on mailing lists with active help from the
> maintainers.

I think these are the only two major Linux/BSD SMTP servers I'd
recommend as current today... but which is "better" is like asking which
color is "better", purple or green.

> Sendmail is actively maintained and works fine, but configuring it
> is hard and the documentation is a 30 year stream of consciousness.
> Its support is on usenet, comp.mail.sendmail, where the maintainer
> is active but very grumpy.

I ran sendmail for many years, got my release notes entries to show for
it. :)  It was kind of neat to be able to do wacky things with what was
essentially a programming language config, but now I think there's
better ways to get most of the same stuff done with milters, policy
maps, etc.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Microsoft breaking ARC?

[Chris Adams via mailop]

My $DAYJOB has a service that does some email processing for customers
with Microsoft email, where MS gets a message, passes it to us with a
criteria based route, and then we pass it back to MS.  We are setting up
ARC to meet MS's requirements, and I have found that MS is passing
messages to us with already-broken ARC sealing.

Specifically, if a Hotmail user (or any MS email user in a different
domain I believe) sends a message, it gets a bunch MS-specifc headers,
some of which are then included in the ARC-Message-Signature header
list.  The specific problem headers are:

X-MS-Exchange-AntiSpam-MessageData-0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount

Then the message goes to a different MS server for the recipient domain,
which does a second ARC seal, including those same headers in the AMS
list.  However, AFTER doing the seal, MS renames those headers,
inserting a "-Original" in the name (I assume because second MS server
sees "my header from an outside source").  Since they do this after
sealing, the message always gets to my edge server and fails an ARC
verify.

My understanding of the whole ARC process is that you should verify on
input, do any processing/modifications you need to do, then seal on
output (and not change the message from that point).

Am I misunderstanding, or is this a bug on MS's end?  If it's a bug...
any ideas on how to get that through to the right people at MS?  I'm
guessing front-line support is not going to understand this.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Chris Adams via mailop]

Once upon a time, Jaroslaw Rafa  said:
> You can very well have a GUI when using KVM - virt-manager is a very nice
> piece of GUI to manage virtual machines running under KVM...
> 
> Of course it's not a web-GUI, ie. virt-manager is just an ordinary X
> application running on the host OS (I routinely use it remotely, from my
> desktop Linux PC which has a full X desktop running).

Cockpit can provide some basic KVM/libvirt VM management (including
graphical and serial consoles) in a web browser.

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

Re: [mailop] Debt Collection Client Email Servers

[Chris Adams via mailop]

Once upon a time, Alexander Huynh  said:
> Good news is there's a draft RFC presented at IETF 119 to tackle this: 
> https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/

Good luck on the problem senders implementing it... if they cared,
they'd already have something.  I also get money transfer notifications
from one bank; they have the typical "only for intended recipient,
notify sender if you aren't" disclaimer... along with the "this is sent
from noreply, do not reply" bit (so there's no way to satisfy the
"notify sender" part).

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

Re: [mailop] Debt Collection Client Email Servers

[Chris Adams via mailop]

Once upon a time, Brielle  said:
> E-mail addresses aren't guaranteed to actually belong to the person you think
> you are sending to.

Yep - I recently started getting debt collection emails to a Gmail I
don't give out (only used for Google stuff).  I've had the Gmail account
since the beta days, so I don't believe anyone else has ever had this
email address.  The debt collection emails are for a cell phone account
with a carrier I've never used.

And there's no "unsubscribe" or "this is not me"... so it's pure spam.
I've tagged enough as spam that Gmail sends them directly to the spam
folder now, hopefully it's dropping the reputation of the sender too
(IPs, domains, etc.) for repeatedly sending such junk.

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

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

[Chris Adams via mailop]

Once upon a time, Alexandre Dangreau  said:
> Hello, 
> 
> > there are other providers in the same price range which assign /64. 
> 
> The VPS/PCI price start at 4€ per month. Not sure you will be able to find 
> server with /64 IPv6 at this price.

Linode/Akamai has $5/month VMs that include a /64.  So that's not a good
excuse either.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Chris Adams via mailop]

Once upon a time, Alexandre Dangreau  said:
> In fact, if you need a /64 IPv6 range you probably use the wrong service. For 
> VPS and Public Cloud instances (PCI) the IPv6 range is shared with all the 
> VM, so each VM (VPS or PCI) have one single IPv4 (/32) and one single IPv6 
> (/128).
> 
> Only baremetal have a dedicated /64 IPv6 range. The support team could help 
> you to find a server corresponding to your needs.

What you are saying is that OVH has bad product design (another reason
VPS customers should look elsewhere).  Other VPS providers do not have
such an artificial limitation; proper network support should not be an
up-sell.

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

Re: [mailop] Dot as the first character of a line ? (RFC 5321, Section 4.5.2)

[Chris Adams via mailop]

Once upon a time, Cyril - ImprovMX  said:
> Just to clarify, I'm not trying to pin some issue on a company (Google) but
> I'm trying to understand why aiosmtpd seems to follow an RFC that
> appears to be clear on the behavior, that GMail doesn't do but doesn't
> appear to be the only one (as my user is generating a document that also
> doesn't seems to follow it).
> 
> I'm more thinking about a different interpretation on the RFC that leads to
> various behavior between aiosmtpd and (some) others.

You have only looked at half of the two related pieces about lines which
start with a dot (you quoted the the "remove a leading dot" piece).  The
other half of the puzzle is that when transmitting a message via SMTP,
the sender is required to ADD a leading dot to any line with a leading
dot (that is then, per the RFC section you quoted, removed by the
receiver).

If your sending software is not adding the second dot to lines that
already start with a dot, that is your problem.

Basically, if you have a line in your original message that looks like
(indented JUST to make it clear):

.example.com

then when it is actually being transmitted via SMTP, the sender changes
it to:

..example.com

and then the receiver strips the leading dot to make it:

.example.com

as originally written.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] DMARC report generators

[Chris Adams via mailop]

I guess companies are using hand-rolled DMARC report generators that
don't pay attention to standards... just on my personal domains, I see
multiple kinds of failures.  Today I've had several with an invalid
Message-Id header (no brackets, I see this from multiple sites so I
guess some common report generator is doing this), Trustwave sending
from an IP with invalid DNS, and this oddity from GoSecure:

  From: dmarc-rep...@gosecure.net
  To: dmarc-rep...@cmadams.net
  Date: Sat, 20 Jan 2024 18:17:16 +
  Date: Sat, 20 Jan 2024 10:17:16 -0800
  Subject: Report domain: cmadams.net Submitter:gosecure.net
Report-ID:3E142D0B10BBC11A97A7146A82662F23

I realized I was blocking reports as spam because of the various errors.
Oops.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Chris Adams via mailop]

Once upon a time, Jaroslaw Rafa  said:
> Dnia 25.08.2023 o godz. 09:48:35 Chris Adams via mailop pisze:
> > 
> > So even for transactional messages, there's usually an account making
> > the purchase, or something is being delivered to an address, or the
> > like.  So a "this is not me" link should be able to note that (a) don't
> > send more mail about the current transaction to this address and (b)
> > don't send any mail for future transactions with the same delivery to
> > the same address without further input.  Future orders that would have
> > transactional emails blocked should pop up and say "hey, this address is
> > flagged as NOT YOU, are you sure?".
> 
> This does not solve the problem of one-time purchases WITHOUT an account
> (actually may be multiple "one-time" purchases, but without registering an
> account at the shop and logging in).

"or something is being delivered to an address"

One of the things that prompted me to send the initial message here is
DoorDash delivering food to the same person.  In that case, it appears
they made an account, but even if they didn't, it's probably going to
the same place.  So "delivery address+email" is a unique identifier.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Chris Adams via mailop]

Once upon a time, Brotman, Alex  said:
> Are you suggesting that an unsub results in a suppression?  That hardly seems 
> ideal.  That seems to suggest I sign up for a brand's email list.  Order some 
> stuff, get receipt.  Later unsub.  Later buy again, but get no receipt?  
> (Presuming it comes from the same ESP)

So even for transactional messages, there's usually an account making
the purchase, or something is being delivered to an address, or the
like.  So a "this is not me" link should be able to note that (a) don't
send more mail about the current transaction to this address and (b)
don't send any mail for future transactions with the same delivery to
the same address without further input.  Future orders that would have
transactional emails blocked should pop up and say "hey, this address is
flagged as NOT YOU, are you sure?".

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

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

[Chris Adams via mailop]

Once upon a time, Paul Menzel  said:
> I guess it’s ignorance, and that nobody complains to them. Depending
> on your jurisdiction you can report this case to the “data privacy
> office”, and you can contact the data protection officer of the
> offending company.

I hadn't thought about trying that route... but it's also like telling
people they can track down spammers IMHO.  It shouldn't be acceptable
behavior.

> (You could also try to reset the password, often sent to the
> registered email address.)

So for a few of these, I've considered that... but also think that in
some jurisdictions someone could then try to come after me for accessing
an account that wasn't mine.  In the Delta Airlines case this week,
there isn't even an account; it's a case of an employee getting a ticket
for a family member and sending ticket messages (so I'm getting the
family member messages - no Delta account to log in to).

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

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

[Chris Adams via mailop]

Once upon a time, Mike Hillyer  said:
> You get a doordash status message, you decide you don't need them, you 
> unsubscribe. A couple of months later you need to reset your password and now 
> you never get the reset link because you unsubscribed from transactional 
> messages? Sure, we can get infinitely granular or always exempt password 
> resets, but it becomes a slippery slope that results in a lot of engineering 
> hours.

Not spamming people does sometimes require more work.  And I believe
this kind of stuff is exactly the definition of spam: UCE.  There is no
doubt that it is unsolicited, no doubt that it is commercial.  Why
should it get a pass?  "Because it's hard" is no more of an excuse for
this than any other type of spam.

So yeah, password resets and/or email resets could still go (although
still a "not me" link should at least signal somebody that "something is
wrong"), but everything else should follow at minimum an opt-out system,
if not opt-in.

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

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

[Chris Adams via mailop]

Once upon a time, Christine Borgia  said:
> Because it's not a subscription. The person is entering the email address
> where they want their order info to go, and they are entering your email.
> The onus is on that person and not the vendor.

That's a very vendor-centric look at it.  When I get order confirmation,
a your order is being prepped, your order has been picked up, your order
has been delivered emails, what is that but not a subscription to a
series of events that I did not request?  The sender does in fact bear
responsibility - they are the one sending the messages and the only one
that can make them stop.

A few vendors manage to put a "this is not me" link in messages (which
is functionally an unsubscribe, even if you don't want to call it that).

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

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

[Chris Adams via mailop]

What do you do when legitimate mail (lately, DoorDash order info and
Delta Airlines tickets) is sent to the wrong address?  These types of
messages rarely have an unsubscribe method.  I get a ton of crap to a
Gmail address that I really only use for Google-related stuff (not as a
general email box), so I know instantly that this is not to me.

Why do vendors think they don't need an unsubscribe in this type of
mail?  Just because their customers are dumb and don't know their own
email address doesn't mean they should continue sending personal
information about them to other people.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any old-school sendmail types here good with the m4?

[Chris Adams via mailop]

Once upon a time, Sean Kamath  said:
> That’s how I learned BSD4.3’s csh had a fun history expression “bug” (it 
> caused csh to coredump):

Yeah well, csh considered harmful. :)

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

Re: [mailop] Mail Sending Self-Test Platform

[Chris Adams via mailop]

Once upon a time, Tom Ivar Helbekkmo  said:
> Tobias Fiebig via mailop  writes:
> > If I read RFC8461 correctly, this is not required for MTA-STS policies:
> 
> Until they formally override POSIX, they have to abide by it.

Since POSIX has nothing to do with network communication protocols for
email, that's a funny hill to die on.  The RFC defines the response
format, which doesn't have to be a text file on a POSIX system at all
(could be generated on the fly, could be on a non-POSIX system).

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

[mailop] Gmail funny: flagged their own DSN message as spam

[Chris Adams via mailop]

I have a Gmail address - I don't give it out, the only legit mail I get
to it is generally Google account related stuff (bills and such).  I
have a forward set up on it to send everything to my personal server.

This morning, there was some spam that got through Gmail's filters sent
to it.  Gmail tried to forward it, but my server's spam filters rejected
the message (reject during SMTP, no bounce generated from my server).
Gmail generated a delivery status notification message...  and sent that
directly to the Gmail spam folder.

Oops... :)

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

Re: [mailop] The oligopoly has won.

[Chris Adams via mailop]

Once upon a time, Jim Popovitch  said:
> I agree. Self hosted email is not hard, and it's just not super easy. :)
> 
> The much harder aspect of email is getting your peers, family, and
> friends to adopt encryption.

Self-hosted email is hard (or really, impossible) for a high enough
percentage of the Internet population that it is effectively 100%.  My
father has been using computers since well before I was born, is still
working on rockets today, but I have to explain email technicalities to
him sometimes, things that we just take for granted.

It's similar in a way to how blogs were popular before a succession of
social media megacorps took over; the average techy could pop up
something on their ISP-provided web space back in the day, but the
average individual online now could not possibly do that.  Even dealing
with a hosted WordPress or the like is beyond most.  And even the
density of capabale people is way to low to support friends-and-family.

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

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

[Chris Adams via mailop]

Once upon a time, Ángel  said:
> On 2022-08-21 at 15:18 -0500, Chris Adams wrote:
> > Also, I believe you can offer both RSA and EC certs, so shouldn't be
> > a negative to getting an EC cert (you just need to have RSA too).
> 
> How would you do that?
> 
> You could use different certificates on different interfaces, based on
> the hostname the client is connecting to (assuming they support SNI),
> or even the client IP address.
> 
> But I don't think you could easily vary the type of certificate you
> present to the client.
> Technically, the ClientHello message shal be sent before the
> ServerHello, so I guess you could predict, based on the ciphersuites
> presented, if the client is likely to support an EC cert and present an
> EC or RSA certificate based on that, but I don't know of a SSL library
> which allows you to do that.

That's how it works, and it is supported by at least OpenSSL (which I'm
guessing is probably the widest-used library).  For example, nginx's
mod_ssl allows a single server to have both an RSA and an ECDSA cert
configured.  F5 load balancers support this as well, and include this in
the KB article:

   Once configured, the choice of certificate presented comes down to
   the negotiated cipher suite in the SSL handshake during the client
   and server hello phase.

   https://support.f5.com/csp/article/K21239684

Postfix's TLS_README also says it supports multiple server cert types,
determining which to use based on the negotiated ciphersuite.
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

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

[Chris Adams via mailop]

Once upon a time, Slavko  said:
> BTW, Chris, if ssl-enum-ciphers nmap's script was not updated recently
> (1-3 years -- i do not remember when exactly i tried it last), do not
> rely on it, it doesn't support TLS1.3...

The version included with nmap 7.92 does recognize and enumerate
TLSv1.3.

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

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

[Chris Adams via mailop]

Once upon a time, Alexander Huynh  said:
> On 2022-08-21 19:46:31 +, Slavko via mailop wrote:
> >Is that typo? AFAIK both these cipher suites are usable only
> >with RSA certificate, they difers only by ephemeral key exchange
> >algo...
> 
> Sorry, you're right that it's a typo. I just re-tested and want to
> clarify that: ECDHE-RSA-AES128-GCM-SHA256 is exclusive to RSA
> certificates, and ECDHE-ECDSA-AES128-GCM-SHA256 is exclusive to EC
> certificates, which is less widely supported by other MTAs.
> 
> I've hobbled up a script to enumerate ciphersuites at
> https://gist.github.com/ahrex/8d2c15086a116bb9388424c40687f20f,

There's also the nmap script to do enumeration (although it doesn't work
against some STMP servers, it seems to for most).  On my Fedora Linux
system, you can use it like:

nmap -Pn -sV --script /usr/share/nmap/scripts/ssl-enum-ciphers -p 25 
gmail-smtp-in.l.google.com

Also, I believe you can offer both RSA and EC certs, so shouldn't be a
negative to getting an EC cert (you just need to have RSA too).
-- 
Chris Adams 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google still using SHA1 (and forcing it)?

[Chris Adams via mailop]

Once upon a time, Lukas Tribus  said:
> No, you didn't just disable SHA1. You disabled all MACs except SHA256
> and SHA384, including the crucial AEAD MAC for modern GCM ciphers.

Ahh, my mistake, sorry.  The code in question is actually Java and sets
a list of ciphers, which both openssl s_client and gnutls-cli make it
hard to replicate for testing.  I will continue to look.

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

[mailop] Google still using SHA1 (and forcing it)?

[Chris Adams via mailop]

I ran into an issue at $DAYJOB where we had a hard-coded TLS version and
ciphersuite set connecting to Google (specifically aspmx.l.google.com).
The problem turned out to be a library upgrade had disabled SHA1, so the
TLS hello handshake failed.

Here's an example to reproduce it with gnutls-cli:

$ gnutls-cli --priority=NORMAL:-VERS-ALL:+VERS-TLS1.2:-MAC-ALL:+SHA384:+SHA256 
--starttls-proto=smtp aspmx.l.google.com:25
Processed 148 CA certificate(s).
Resolving 'aspmx.l.google.com:25'...
Connecting to '2607:f8b0:4002:c08::1a:25'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed

If you add ":+SHA1" at the end of the priority string, it connects
successfully (and uses SHA1).

Oddly, if I nmap scan what ciphers appear to work with TLSv1.2, there
are SHA256 and SHA384 ciphers available (and were in our hard-coded
list).  From an nmap:

|   TLSv1.2: 
| ciphers: 
|   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|   TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|   TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|   TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|   TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A

So is there a bug on Google's side forcing SHA1, or am I missing
something (which is quite possible, getting into obscure bits of TLS
does trip me up)?

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

Re: [mailop] Did Google become stricter about RFC 5322?

[Chris Adams via mailop]

Once upon a time, John Levine  said:
> Same here. I set up a kludge to rewrite From: headers several years
> ago (not rewriting to the list address, which sucks) and it still
> works fine.

Is there a standard for doing rewrites like that?  Because I like to see
actual senders in the From: line (while recognizing the need to do the
rewrites), I have a script that recognizes a couple of rewrite methods
I've seen and reverses them for messages going into my mailing list
folders.  It's very much just done based on what I've seen though, so
probably doesn't "fix" a lot.

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

[mailop] Looking for EarthLink Contact

[Chris Adams via mailop]

Is there anybody from EarthLink who can contact me off-list?
We are seeing emails sent to EarthLink recipients have the From header
domain overwritten with the CNAME the domain points to and would like to
discuss.

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

Re: [mailop] Google DNS Quad 8 Outage tonight (Grant Taylor)

[Chris Adams via mailop]

Once upon a time, Joel M Snyder  said:
> Since this is happening in a number of countries, it's hard to
> discern exactly why 8.8.8.8 is given the exception

Possibly because some consumer equipment and software appears to have
8.8.8.8 hard-coded, ignoring local (e.g. DHCP-provided) settings.  IIRC
I've seen that behavior from some (but not all) Google Home products and
the Netflix app on various devices.

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

[mailop] Carrierzone - Incorrectly Rewriting From and Return-Path Headers?

[Chris Adams via mailop]

Hi --

We are seeing some odd behavior with emails delivered to recipient
mailboxes protected by Carrierzone (https://carrierzone.com/).

Emails leaving our platform have a proper From header. However, when they
are received by Carrierzone, both the From and Return-Path headers have had
the domain replaced with  "sparkpostmail.com".   It's almost as if they are
using the organizational domain from our connecting IP's rDNS lookup and
rewriting the header using that domain.

A subset of the headers are below
Below you can see in the Authentication-Results-Original header that
the header.d is correct.  But the From address has been replaced.  The same
thing happens with the Return-Path header.  We have further verified that
when the mail left our platform the headers were correct.

I am curious if anybody has seen this with them or other filter providers
before?
And would anybody have a contact at Carrierzone that I could reach out to?

Thank You!

--
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 sparkpostmail.com discourages use of 66.175.45.214 as permitted sender)
Received: from mail314c28.carrierzone.com (66.175.45.214) by
 DB5EUR01FT007.mail.protection.outlook.com
 (10.152.4.107) with
Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.4129.25 via Frontend Transport; Sat, 22 May 2021 14:39:08 +
Authentication-Results-Original: mail314c28.carrierzone.com; dkim=pass
 (1024-bit key) header.d=send.o***l.com 
header.i=@send.o***l.com 
 header.b="tBmppuh8"
Received: from mta-88-193.sparkpostmail.com (mta-88-193.sparkpostmail.com
 [192.174.88.193])
by mail314c28.carrierzone.com (8.14.9/8.13.1) with ESMTP id 14MEd3NK026470
Reply-To: "O***d" >
From: "O***d" >
Date: Sat, 22 May 2021 14:39:02 +
List-Unsubscribe: 
List-Id: 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: What's the point of secondary MX servers?

[Chris Adams via mailop]

Once upon a time, John Levine  said:
> That sounds like two equal priority MX records.  No problem with that.
> 
> Personally I'd use two A records for one name, but whatever.

IIRC from back in the day, when I ran sendmail for an ISP, the host
status tracking was done by hostname, not by IP.  Having multiple MX
records pointing to hostnames with a single IP worked better than a
single MX record pointing to a hostname with multiple IPs.  I don't
remember if a single queue run tried multiple IPs for the same host or
not.

That's old knowledge, and I don't know how modern mailers handle things
(haven't had need to look at that in a while).

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

[mailop] How long to retry?

[Chris Adams via mailop]

Just an idle Sunday question... how long do you have your mail server(s)
configured to queue and retry messages before bouncing them back to the
sender?

I know back in the day, 5 days was the norm, to handle servers that were
only sometimes connected, outages, etc.  I think that's still the
default in most software.  But that seems really long now.  I took a
quick look at some of my logs, and out of 4.6 million messages relayed
to outside servers, 134 of them took longer than 12 hours.  Of the
messages that took longer than 1 minute, 77% were relayed within 1 hour
(probably greylisting).  Of the messages past 1 hour, 80% were relayed
within 6 hours.

I've got the queue life set to 1 day on some personal servers, but I'm
wondering if I should go even shorter.  For the most part, users don't
really understand warnings and all - they'll be best server by getting a
bounce as soon as practical.

Anybody know what the big guys (Google and the like) do?  I thought
about setting up an address to always return 4xx and sending tests, but
I'm lazy so I figured I'd ask here instead. :)

-- 
Chris Adams 

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

Re: [mailop] Issue with Mailop 'From' header

[Chris Adams via mailop]

Once upon a time, Grant Taylor  said:
> On 8/15/19 11:17 AM, Mark Milhollan via mailop wrote:
> >perhaps a way can be found for your MUA to help you
> 
> It's a complete hack.
> 
> But I use procmail to doctor messages as they come into my mailbox.
> I mostly add List-Post: header if it doesn't exist and rely on my
> MUA's Reply List function.
> 
> But it would be trivial to create additional rules to do something
> like the following:
> 
> 1)  Check if the From: header is the list.
> 2)  Check if the Reply-To: header is set.
> 3)  Replace the list's From: header with a synthetic From: based on
> the contents of the Reply-To:.

Here's what I do (should work for most Mailman lists):

:0 f
* ^reply-to:
* ^x-beenthere: \/.*
{
MLADDR=$MATCH

:0 f
* $^from: .* via .* <$MLADDR>
* ^reply-to: \/.*
| formail -i "From: $MATCH"
}

-- 
Chris Adams 

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

[mailop] Problem sending to @vtext.com

[Chris Adams via mailop]

I have customers that (unwisely) depend on sending email to SMS via the
@vtext.com gateway.  Lately, the messages have been periodically backing
up in our queues because the Cloudmark SMTP servers reject the messages.
I get different error responses:

452 4.1.1  requested action aborted: try again later (in 
reply to RCPT TO command))

421 vzw-ibgw-5001a.stratus.cloudmark.com cmsmtp Connection refused - 
LhYMh85jEL68J - POL109G - too many sessions from 76.164.172.160

Sometimes, the servers will accept messages for a short while, then
reject them for a while, then accept a few, etc.  I looked to see if the
POL109G had a specific meaning, but just found references to others
getting that error.

As far as I can tell, we don't have spam/garbage/etc. going out to the
@vtext.com numbers that would cause this (when I look at the messages in
the queue they all look legit).  Is there anything I can do to improve
the delivery of these messages?
-- 
Chris Adams 

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

Re: [mailop] Admin: Gmail users of mailop suspended due to bounces.

[Chris Adams via mailop]

Once upon a time, Grant Taylor via mailop  said:
> On 4/28/19 11:35 AM, John Levine via mailop wrote:
> >Oversigning those headers is silly.
> 
> Oversigning may be /silly/.  But it's still the sending site's choice.

So should mailing lists reject such messages?  If they're going to add
headers and the signing effectively says "don't", why should the list
accept the message?
-- 
Chris Adams 

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

Re: [mailop] Mailing List Address Formats..

[Chris Adams]

Once upon a time, Michael Peddemors  said:
> I don't know of this particular mailer, but can I get some feedback
> to confirm that the '*' character is not a permitted character in an
> email address? (user name portion)

You can always use this handy-dandy regular expression to validate email
addresses:

http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
-- 
Chris Adams 

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

[mailop] Email viruses still a thing?

[Chris Adams]

I was looking at some stats on a mail server cluster I operate to handle
a handful of small telephone companies, and I noticed that I get almost
no viruses blocked anymore.  It's a fairly typical setup of postfix and
amavisd (calling spamassassin and clamav), with some DNS-based
blocklists on the front end.  Looking at the last 3 weeks of logs, I
only see about 1 out of every 57,000 messages blocked as a virus.

Mostly just wondering if my virus filtering is hosed up, or have email
viruses really dropped that much (or are enough of the sources blocked
by DNS blocklists?). :)

-- 
Chris Adams 

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

Re: [mailop] Is outlook.com blocking the Linode IP ranges?

[Chris Adams]

Once upon a time, Grant Taylor via mailop  said:
> Ya.  I'm dealing with that on a shared /64 for IPv6 with one mailing
> list that I subscribe to and have problems replying.  Fortunately
> IPv4 gets through so I block IPv6 to them.  It's an ugly hack but it
> allows me to reply to the mailing list once a month.

You can get a dedicated v6 /64 from Linode just by asking; they route it
to the assigned IP in the shared /64, so you have to do a little bit of
config trickery to make the dedicated /64 the primary source for
outgoing v6 connections.  I did that years ago and haven't had any v6
trouble since (just used for my personal stuff only so very low volume).

-- 
Chris Adams 

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

Re: [mailop] Gmail - SSL cert changes - way to whitelist

[Chris Adams]

Once upon a time, Kostya Vasilyev  said:
> The app "remembers" the SSL certs it has seen for a particular server
> / port, and if, when it connects, it finds that the cert has changed -
> 
> - it flags this as an error and requires the user to decide if he/she
> wants to proceed (displaying information about the "last known" and
> the "new" certificates).

Aside from your Google-related questions, this is going to be a problem
with anybody using Let's Encrypt certs, as they'll typically change
every two months.

-- 
Chris Adams 

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

[mailop] Another Google email issue

[Chris Adams]

We have a customer that sent mail through our server to a domain we
manage in Google.  The sender got a bounce back with:


Technical details of permanent failure:
Your email to group [address] was rejected due to spam
classification. To address this issue:

* Contact the owner of the group, who can choose to enable message
moderation instead of bouncing these emails.
* Set up SPF records for your sending domain if you have not done so
already.

Instructions for both steps can be found here:
https://support.google.com/a/answer/168383.


The message was sent to three address: one user and two groups.  The
user got the message, but the groups bounced it.

The sending domain has proper SPF, and the headers included in the
Google bounce message include the SPF "pass".  The info at the support
page appears out of date and doesn't match the bounce message.

Any suggestions?
-- 
Chris Adams 

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

Re: [mailop] New comment - [#503261] Re: Microsoft holding IPs hostage?

[Chris Adams]

Once upon a time, Apsis Deliverability Team  said:
>  There is a new comment in the ticket submitted by Anthony Chiulli to / APSIS 
>   Comment added by : Dickie LaFlamme  Comment Content:  

Has some effort been made to find who is sending list messages to
Salesforce and shoot them?
-- 
Chris Adams 

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

[mailop] Verizon Wireless refusing to talk

[Chris Adams]

I have a couple of mail servers for an ISP that can't send mail to
@vtext.com and @vzwpix.com addresses.  On connection, their servers just
return a 554 and close the connection:

$ telnet smtp.vzwpix.com. smtp  
Trying 69.78.128.215...
Connected to smtp.vzwpix.com..
Escape character is '^]'.
554 njbrspamp6.vtext.com
Connection closed by foreign host.

Any suggestions?  Do they have a blacklist or something that these
servers may be on?
-- 
Chris Adams 

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

[mailop] Comcast, IPv6, and Spamhaus

[Chris Adams]

I tried to send a message to a @comcast.net customer from my Linode VPS
(with IPv6 enabled) and got the following reject:

... while talking to mx2.comcast.net.:
<<< 554 resimta-ch2-17v.sys.comcast.net comcast 2600:3c03::f03c:91ff:fe96:5e2 
found on one or more DNSBLs, see 
http://postmaster.comcast.net/smtp-error-codes.php#BL01

The URL says that it is listed by Spamhaus Zen.  AFAIK they aren't
listing IPv6 (their lookup form doesn't accept IPv6 addresses at least).
Is Comcast just misapplying DNSBLs to IPv6 addresses?  Any Comcast
admins around that could help?

The above address has matching reverse and forward DNS, and I haven't
had delivery issues to anybody else.  Double-checked the server, and I
don't see any sign of spam or anything.

-- 
Chris Adams 

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

Re: [mailop] dnswl.org contact?

[Chris Adams]

Once upon a time, Tony Vroon  said:
> On 22/01/15 14:30, Chris Adams wrote:
> > I haven't heard anything back.
> 
> It takes anywhere up to 48 hours to get a response. It isn't a giant
> team of people, so a response in minutes is unlikely.

It had been about a week and a half (should have said that in my email,
sorry); I wasn't expecting an instant reply, but I thought after that
long that maybe something had gotten lost.

Thanks to Matthias Leisi for looking into it for me.
-- 
Chris Adams 

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop

[mailop] dnswl.org contact?

[Chris Adams]

I run some mail servers for some ISPs, and I was looking at trying to
improve our spam filtering, including reducing false positives, so I was
looking at dnswl.org.  Per their site, I emailed off...@dnswl.org, but I
haven't heard anything back.  Does anybody know another contact?

-- 
Chris Adams 

___
mailop mailing list
mailop@mailop.org
http://chilli.nosignal.org/mailman/listinfo/mailop