On 9/25/23 17:11, Greg Wooledge wrote:
On Mon, Sep 25, 2023 at 04:49:52PM -0600, Rick Macdonald wrote:
Lastly, do I understand correctly that the root of this whole issue is
simply misformed headers in the original spam mail that I receive at my
Dreamhost account? Oh, and does all this lead to the "Frozen Message" emails
I receive (described in a prior email)?
I'm not an exim expert, but it seems the fundamental issue here is
that your actual receiving MTA (Dreamhost) accepted these messages,
but your local exim MTA refused to accept them.  Fetchmail kept trying
to move the messages from the former to the latter, which failed each
time, and caused exim to generate a new bounce message.  Each time.

The same issue would have arisen in any situation where the first MTA
and the second MTA have differing acceptance criteria.  Could be syntax
errors, could be antispam policy, could be anything that's different
between the two MTAs.

One of the big revelations in email administration in the last few
decades is that the original SMTP design, in which messages were
accepted liberally, with bounces generated after the fact if deliveries
were not possible, was flawed.  It led to many kinds of abuse by
malicious senders.

The preferred policy nowadays is to perform all possible checks *during*
the initial SMTP conversation.  If a message fails to meet acceptance
criteria for any reason, it should be rejected during that initial
conversation.  Generating a bounce message almost always ends up sending
spam to an innocent third party address, which the malicious sender has
forged.

How this relates to fetchmail and exim, specifically, I can't say.  These
aren't tools I'm deeply familiar with.  But if you can do it, try to
arrange it so that any message that can't be accepted gets dropped into
a black hole, rather than generating a bounce message.

Thanks Greg. Your summary matches my new understanding. I looked at the Dreamhost mail options and don't see where I can change anything, so the next time I get an email stuck there I'll try adding the fetchmail --nosoftbounce option which should quietly delete the bad message on the server, and stop any future bounce messages.

Rick



Reply via email to