On Thu, Jul 10, 2025 at 10:46:45PM -0500, Jayson Smith wrote:
> I know there are a few RFC's which specify that postmaster@ must be a valid
> address at all domains. Are there any Email or other systems that
> actually care about this, and will declare me to be an evil, non-compliant
> server administrator if such addresses do not accept mail?
Yes. And there are people who will do the same. Supporting postmaster@
has been a de facto and de jure requirement for decades, and I won't accept
ANY excuse for failure to do so. Same for abuse@, security@ and (in the
case of any domain with a web site) webmaster@ and (if used in DNS SOA
records) hostmaster@. All competent, responsible, professionals (and even
competent, responsible amateurs) support these: it's systems admin 101.
If you're having issues with excessive spam to those addresses -- as
opposed to sporadic spam -- then there are other ways. Examples:
- Use procmail to file/sort the obvious spam. I have a ruleset
of about 200 slowly-accumulated rules that grabs almost all
garden-variety spam/phish attempts. Every time I see one
that isn't covered, I add another rule. If you'd like a
copy of my ruleset, please contact me off-list; I believe
it's generic enough to be useful in other environments.
- Use procmail: set up rulesets that cover common, known,
reliable reporters. E.g.: if j...@example.com turns out to be
someone who sends accurate reports, then install a procmail
rule that prioritizes traffic from Joe. Just as the first
set of rules I suggested above will shunt most of the crap
out of your way, this will help put the traffic that you *really*
want to pay attention to where it should be. And just like the
first ruleset, this is something you can grow over time: I have
about 2500 such rules in place now, one for every email address
that has sent something notable/actionable over the past 30
years or so. I could share this with you too, but it's
likely not useful, because it's custom-tuned to what I've
been running and thus unlikely to be tuned to what you're running.
- These two measures alone almost always suffice to make RFC
2142 et.al. addresses very usable. And the work required to
maintain the rulesets steadily decreases over time, as they
gradually converge on something approaching "optimal" for your
mix of inbound traffic.
- If the spam is localized to particular networks -- and it quite
often is -- identify those networks and firewall those blocks
from (at least) access to port 25 on your MX's. In the case of
dedicated spam networks, this achieves lossless compression of
the data channel. ;) But (of course) be careful about this;
it's rather a blunt instrument and not to be used without
understanding the consequences. That said, any of the networks
mentioned in the recent threads about attacks against Mailman
instances would be a good start.
- Make sure that you're reading traffic to role addresses with as
secure-as-possible MUA on as secure-as-possible OS; I recommend
mutt on OpenBSD. This helps mitigate a lot of the threat vectors
that'll be contained in the incoming traffic.
---rsk
------------------------------------------------------
Mailman-Users mailing list -- mailman-users@python.org
To unsubscribe send an email to mailman-users-le...@python.org
https://mail.python.org/mailman3/lists/mailman-users.python.org/
Mailman FAQ: http://wiki.list.org/x/AgA3
Security Policy: http://wiki.list.org/x/QIA9
Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/
https://mail.python.org/archives/list/mailman-users@python.org/
Member address: arch...@mail-archive.com
