On 2022-12-05 at 10:24:56 UTC-0500 (Mon, 5 Dec 2022 10:24:56 -0500)
John Stoffel <j...@stoffel.org>
is rumored to have said:
"Bill" == Bill Cole <postfixlists-070...@billmail.scconsult.com>
writes:
On 2022-12-04 at 20:57:49 UTC-0500 (Sun, 4 Dec 2022 20:57:49 -0500)
You are missing the point here.
NO ONE running a serious mailserver will reject mail based on a
UCEPROTECT level 3 listing. It is a waste of your energy to focus on
that listing.
I'd like to believe that.
Obviously not true, as you seem fixated on it.
Your problem is Linode. They have had a steady stream of spamming
custromers that they have failed to deal with for extended periods.
Some
mail systems have responded by rejecting all mail from all machines
on
Linode networks.
Sure, I can understand that, but I don't like it
I'm not fond of it either, but there's the reality. You or me liking it
has absolutely no effect unless we turn our dislike into action for
change. The only way this fact will change is if Linode changes their
behaviors and works to clear their reputation.
and I don't really
want to move to another hosting provider at this time, unless people
have a good suggestion?
And how long before that provider gets completely banned as well?
How long will they tolerate hordes of spamming customers?
It isn't an easily answered question, as the VPS hosters who do not
tolerate spammers don't stand out in any way. I do not know how long it
takes a hypothetical responsible VPS provider to become an adequately
large nuisance to be broadly blocked relative to your becoming a
customer. :)
And
what VPS provider do you recommend?
I have no such recommendations, as I have never asked that question
seriously, much less hunted down an answer. Linode is probably less
shunned than many others, e.g. OVH, but if I had to site a new mail
system today I do not have any idea if there is anyone in the Linode
price range whose networks are not widely shunned for email.
I'm not sure that one can host a robust mail system in any "VPS"
environment today without insurmountable reputation issues. Everyone I
know who has tried that in recent years has failed or has made
compromises that I would not make to get deliverability.
So right now I'm trying to learn how to write a milter to re-write
email sent via a specific transport.
If you're basically competent in Perl, the simple free way to do that
would be to use MailMunge or MIMEDefang, 2 closely related milters that
are configured by writing Perl subroutines for each phase of the SMTP
transaction. That makes it easier than writing all the Milter interface
parts yourself. They also have support for SpamAssassin and other
filtering tools.
So I have setup my transport
like this:
# Added to deliver mail to charter.net, 20221202
charter unix - - y - - smtp
-o smtp_tls_wrappermode=yes
-o smtp_tls_security_level=encrypt
-o smtp_generic_maps=hash:/etc/postfix/sender_charter
-o header_checks=pcre:/etc/postfix/charter_header_first
-o smtp_header_checks=pcre:/etc/postfix/charter_header_second
-o myorigin=charter.net
And I have it properly trying to send the emails, but I get bounced
with:
<jstof...@charter.net>: host mobile.charter.net[47.43.18.12] said:
550 5.1.0 <j...@stoffel.org> sender rejected (in reply to MAIL FROM
command)
so I think I need a milter to re-write my From: header on my outgoing
emails to be jstof...@charter.net.
I don't think so. At MAIL FROM the remote server hasn't seen your
headers. It cannot be rejecting something it has not seen yet. All the
Charter machine knows at that point are your EHLO hostname, client IP &
port, SASL authentication ID, and TLS status.
You probably only need to change the envelope sender, which they
probably are requiring to match your authentication identity.
Should be simple, but how to tie it in isn't quite clearcut to me
yet.
Agreed, especially since headers are irrelevant and you just need to
change the envelope sender. The easy solution is not coming to mind,
since you're needing to change the sender based (ultimately) on the
recipient, which is a bit outside of the norm for an MTA.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
