I've enjoyed following @rfcs. It's a steady reminder of the history I've lived through, what came before me, and alternate histories not taken.
But it just threw RFC 3463 at me, and: TOO SOON, BOT, TOO SOON. #ryoms
@markstos @jwildeboer @homelab for me I self host what makes sense to me. I have #nextcloud #immich #forgejo #jellyfin #keycloak #audiobookshelf . my current goal is to have email #ryoms
made some accounts for kids on the home mail server.
which was working just fine as a single user box with a bunch of virtual domains and aliases.
but adding local users blew up my happy illusion of a proper postfix configuration.
local aliases and virtual aliases have a complicated relationship.
As the owner / operator / postmaster of a tiny little email server, I find that sometimes, but rarely, outbound mail can get blocked and bounced. It happens. Once a decade or so. Some organizations use a sledgehammer to avoid unknown senders like me, even though I provision all the industry standards authentication tools and protective protocols.
So this evening, I forwarded the "offending" email to the administrator of the receiving site, politely explaining how this Nigerian princess just wants to give his customer US$30 million in gold to transfer $3 billion through his bank.
Something like that.
I’m seeing tons of the following in the mail-server logs. Anyone know what’s up there? Just the usual or a Xmas-special?
sm-mta[215926]: [45.148.10.25] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v4
sm-mta[215930]: [45.148.10.29] did not issue MAIL/EXPN/VRFY/ETRN during connection to MSP-v4
sm-mta[216460]: [178.16.55.124] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA-v4
This is why I need #n4sa2e by @mwl - after reading #RYOMS, I set set up one small mail server a year or so ago (well, several temporary ones on unused domains to test without sending malformed email to anyone else and one real one) , and now am setting up a replacement on a new physical server. However, I get unexpected packet loss on IPv6 *only*, even when pinging directly from the jail host.
I've edited the names/ip addresses below, but this is all on a single physical host and a VNET jail on that host (so no external switch or router should be involved), but something is apparently inconsistently routing IPv6 (traceroute6 should be one hop, not 3, and should immediately find the route like IPv4 does).
me@jailhost:~ $ ping -4 mail
PING mail.example.com (10.0.0.54): 56 data bytes
64 bytes from 10.0.0.54: icmp_seq=0 ttl=64 time=0.039 ms
64 bytes from 10.0.0.54: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from 10.0.0.54: icmp_seq=2 ttl=64 time=0.030 ms
--- mail.example.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.030/0.034/0.039/0.004 ms
me@jailhost:~ $ ping -6 mail
PING(56=40+8+8 bytes) 2001:db8::141 --> 2001:db8::54
16 bytes from 2001:db8::54, icmp_seq=27 hlim=64 time=0.040 ms
16 bytes from 2001:db8::54, icmp_seq=28 hlim=64 time=0.027 ms
16 bytes from 2001:db8::54, icmp_seq=29 hlim=64 time=0.028 ms
--- mail.example.com ping statistics ---
30 packets transmitted, 3 packets received, 90.0% packet loss
round-trip min/avg/max/stddev = 0.027/0.032/0.040/0.006 ms
me@jailhost:~ $ traceroute mail
traceroute to mail.example.com (10.0.0.54), 64 hops max, 40 byte packets
1 mail.example.com (10.0.0.54) 0.033 ms 0.035 ms 0.017 ms
me@jailhost:~ $ traceroute6 mail
traceroute6 to mail.example.com (2001:db8::54) from 2001:db8::141, 64 hops max, 28 byte packets
1 * * *
2 * * *
3 * *
mail.example.com 0.055 ms
I'll try a non-VNET jail as the next test (based on the jails/zones call hosted by @dexter yesterday: Use a VNET jail when you NEED to, otherwise use an alias/regular jail with less networking overhead/complexity)
@nixCraft Sounds like a good opportunity to Run Your Own Mail Server 😉
@whitequark Tagging this as #ryoms.
Google is back on this again with 37 identical DMARC emails today.
They’re definitely separate transactions from their SMTP and it looks like everything is being handled appropriately.
They just really like sending me DMARC messages.
Does this happen to anyone else?
I've just revised my procmail recipes to delete useless DMARC reports due to the broken DMARC standard. Gotta have it in today's email server world. Can't avoid it.
But, I can ignore it.