Hi Haines,
* Haines Brown <haines@histomat.net> [2026-04-06; 12:52 -04]:
By mistake I sent a message (mutt, fetchmail, exim) that was
missing a From: line in the header. As the result I'm deluged with
frozen messages.
I understand that the command # exiqgrep -z -i | xargs exim -Mrm
removed all frozen mail. It does so but the broken message
continues to be received.
might it be that fetchmail pulls the email
again and again from the imap server?
If so, delete the email there.
Ciao; Gregor
Hi Haines,
* Haines Brown <haines@histomat.net> [2026-04-07; 06:19 -04]:
So just where are you suggesting I
delete mail?
from the IMAP server from wich your
fetchmail fetches it. There is probably
a webinterface where you can locate the
email and delete it.
Ciao; Gregor
--
-... --- .-. . -.. ..--.. ...-.-
All this is new to me. I can log in to my email provider. I find thatI'm not sure how to resolve your issue (let me re-read your original
it offers an opportunity to deny email addressses. In my case it would apparely be <>@histomat.net. I'm paranoid about loosing all email and
would appreciate your vote of confidence that blacklisting that
address would not block all email as it would with *@histomat.net.
By mistake I sent a message (mutt, fetchmail, exim) that wasI'm not sure what is happening exactly, but I think some periodic
missing a From: line in the header. As the result I'm deluged with
frozen messages.
I understand that the command # exiqgrep -z -i | xargs exim -Mrm
removed all frozen mail. It does so but the broken message
continues to be received.
On Mon Apr 6, 2026 at 5:52 PM BST, Haines Brown wrote:
By mistake I sent a message (mutt, fetchmail, exim) that was
missing a From: line in the header. As the result I'm deluged with
frozen messages.
I understand that the command # exiqgrep -z -i | xargs exim -Mrm
removed all frozen mail. It does so but the broken message
continues to be received.
I'm not sure what is happening exactly, but I think some periodic process is running and generating *new* mail. Frozen mail is not being delivered, by definition: so if you are being deluged, then the problem is not the frozen mail per se, but whatever process is generating both them, and the mail you *are* getting.
Can you share any more details about the messages you are receiving?
Ideally, the full mail (including headers) for at least two sample mails (so they can be compared to each other as well as independently examined)
From MAILER-DAEMON Tue Apr 07 10:47:07 2026Return-path: <>
From MAILER-DAEMON Tue Apr 07 10:48:12 2026Return-path: <>
My current host name is not iskra but Iskra. The host ikra is aIn the message above, I don't see an ikra, only iskra and Iskra. I'm not
different installation of the operating system on a different drive.
Pehaps I need to boot it, purge and reinstall Exim from it.
From MAILER-DAEMON Tue Apr 07 10:47:07 2026Return-path: <>
Envelope-to: postmaster@iskra.histomat.net
Delivery-date: Tue, 07 Apr 2026 10:47:07 -0400
Received: from Debian-exim by Iskra.histomat.net with local (Exim 4.96)
id 1wA7hr-0003St-1r
for postmaster@iskra.histomat.net;
Tue, 07 Apr 2026 10:47:07 -0400
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer-Daemon@iskra.histomat.net>
To: postmaster@iskra.histomat.net
References: <E1wA7hq-0003Sn-0C@Iskra.histomat.net>
Subject: Message frozen
Message-Id: <E1wA7hr-0003St-1r@Iskra.histomat.net>
Date: Tue, 07 Apr 2026 10:47:07 -0400
Message 1wA7hq-0003Sn-0C has been frozen (delivery error message).
The sender is <>.
The following address(es) have yet to be delivered:
haines@histomat.net: SMTP error from remote mail server after pipelined end of
+data: 554 5.7.1 <>: Sender address rejected: Null Sender Address is Prohibited
On Tue, Apr 07, 2026 at 11:00:21 -0400, Haines Brown wrote:
From MAILER-DAEMON Tue Apr 07 10:47:07 2026Return-path: <>
Envelope-to: postmaster@iskra.histomat.net
Delivery-date: Tue, 07 Apr 2026 10:47:07 -0400
Received: from Debian-exim by Iskra.histomat.net with local (Exim 4.96)
id 1wA7hr-0003St-1r
for postmaster@iskra.histomat.net;
Tue, 07 Apr 2026 10:47:07 -0400
This is a message generated locally on your own system. It was not
received over the network.
So, here's my guesswork -- and you should verify all of this yourself.
1) You've got "iskra.histomat.net" configured as a local delivery
domain, but NOT "histomat.net".
2) You've got "postmaster" aliased to "haines@histomat.net".
3) The remote system that received messages for @histomat.net addresses
is configured to reject messages with a null sender.
4) Your local system is stuck in a loop, because every time it tries
to send an error message to postmaster, the error message fails,
which triggers another error message, unendingly.
If you verify that all of these points are correct, then changing any of
them should break the cycle. The most viable changes would be either
to re-alias postmaster to a local account instead of a remote address,
or to configure the remote mail server to stop rejecting null senders.
(Or, I suppose, to re-alias postmaster to a different remote account,
which accepts null senders.)
On Tue Apr 7, 2026 at 4:00 PM BST, Haines Brown wrote:
My current host name is not iskra but Iskra. The host ikra is a
different installation of the operating system on a different drive.
Pehaps I need to boot it, purge and reinstall Exim from it.
In the message above, I don't see an ikra, only iskra and Iskra. I'm not
sure that Exim will differentiate between hostnames that differ only in capitalisation. Then again, maybe it will!
It looks to me like your local exim believes @histomat.net is not handled locally, and is trying to send mail for @histomat.net "off-site" (although
it may be connecting back to itself unwittingly). Should this system instead be treating @histomat.net as local?
On Tue, Apr 07, 2026 at 04:27:39PM +0100, Jonathan Dowland wrote:
On Tue Apr 7, 2026 at 4:00 PM BST, Haines Brown wrote:
My current host name is not iskra but Iskra. The host ikra is a
different installation of the operating system on a different
drive. Pehaps I need to boot it, purge and reinstall Exim from
it.
In the message above, I don't see an ikra, only iskra and Iskra.
I'm not sure that Exim will differentiate between hostnames that
differ only in capitalisation. Then again, maybe it will!
It looks to me like your local exim believes @histomat.net is not
handled locally, and is trying to send mail for @histomat.net
"off-site" (although it may be connecting back to itself
unwittingly). Should this system instead be treating @histomat.net
as local?
Sorry for the typo. It is iskar/Iskra. Never had a problem before
witn different sets pf hostnames on different hardware.
On Tue, 7 Apr 2026 11:50:49 -0400
Haines Brown <haines@histomat.net> wrote:
On Tue, Apr 07, 2026 at 04:27:39PM +0100, Jonathan Dowland wrote:
On Tue Apr 7, 2026 at 4:00 PM BST, Haines Brown wrote:
My current host name is not iskra but Iskra. The host ikra is a different installation of the operating system on a different
drive. Pehaps I need to boot it, purge and reinstall Exim from
it.
I'm fairly sure that neither the SMTP protocol nor exim in particular distinguish cases in email addresses. I have a feeling I found this for
sure with exim4, but I've run it for so many years I can no longer
remember the details.
I know you've found the problem, but this may help someone else.
--
Joe
I don't think I found the problem. I configured exim without
changing the visible domain name, but this had no effect on the
frozen messages. I don't believe needed to reboot because
reconfiguring exim restarts it. Perhaps reinstalling exim4 from
scratch on both drives would work. But not sure why.
Reonfituringf exim meant that I could not longer send mail, and
so reverted to my old conifuguration that hides the domain name.
I'm fairly sure that neither the SMTP protocol nor exim in particular distinguish cases in email addresses. I have a feeling I found this for
sure with exim4, but I've run it for so many years I can no longer
remember the details.
07.04.26, 18:29 +0100, Joe:
I'm fairly sure that neither the SMTP protocol nor exim in particular distinguish cases in email addresses. I have a feeling I found this for sure with exim4, but I've run it for so many years I can no longer
remember the details.
I don't know anything about exim, but the SMTP protocol defines the local-part of an email address to be case-sensitive:
| The local-part of a mailbox MUST BE treated as case sensitive.
| Therefore, SMTP implementations MUST take care to preserve the case
| of mailbox local-parts. In particular, for some hosts, the user
| "smith" is different from the user "Smith". However, exploiting the
| case sensitivity of mailbox local-parts impedes interoperability and
| is discouraged. Mailbox domains follow normal DNS rules and are
| hence not case sensitive.
https://www.rfc-editor.org/rfc/rfc5321.html#section-2.4
07.04.26, 18:29 +0100, Joe:Yes, officially local-part is case-sensitive, but in practicality it
I'm fairly sure that neither the SMTP protocol nor exim in particular
distinguish cases in email addresses. I have a feeling I found this for
sure with exim4, but I've run it for so many years I can no longer
remember the details.
I don't know anything about exim, but the SMTP protocol defines the local-part of an email address to be case-sensitive:
| The local-part of a mailbox MUST BE treated as case sensitive.
| Therefore, SMTP implementations MUST take care to preserve the case
| of mailbox local-parts. In particular, for some hosts, the user
| "smith" is different from the user "Smith". However, exploiting the
| case sensitivity of mailbox local-parts impedes interoperability and
| is discouraged. Mailbox domains follow normal DNS rules and are
| hence not case sensitive.
https://www.rfc-editor.org/rfc/rfc5321.html#section-2.4
On Tue, Apr 07, 2026 at 13:25:01 -0400, Haines Brown wrote:
I don't think I found the problem. I configured exim without
changing the visible domain name, but this had no effect on the
frozen messages. I don't believe needed to reboot because
reconfiguring exim restarts it. Perhaps reinstalling exim4 from
scratch on both drives would work. But not sure why.
Reonfituringf exim meant that I could not longer send mail, and
so reverted to my old conifuguration that hides the domain name.
You don't appear to have a firm grasp of how your MTA is configured
at all.
Start by looking at which domains you've declared to be local.
Does this include both "histomat.net" and "iskra.histomat.net"?
Or just one of them? Or neither?
Next, look at how your "postmaster" is configured. Is it an alias?
Is it a real user? If it's an alias, what address does it point to?
On Tue, Apr 07, 2026 at 01:46:03PM -0400, Greg Wooledge wrote:
Start by looking at which domains you've declared to be local.
Does this include both "histomat.net" and "iskra.histomat.net"?
Or just one of them? Or neither?
Is local domain name the same as what exim configuration calls
system mail name? In the field put Iskra@hstomatlnet. There is no
place for an additinoal domain name. Pehaps it can be provided in
answer to other distinations. Is that so? I usually leave blank.
Next, look at how your "postmaster" is configured. Is it an alias?
Is it a real user? If it's an alias, what address does it point to?
Exim configuration does not provide for identifying who is
postmaster. I do create a /root/.forward file with my simple
address haines@histomat.net in it. I suppose that makes me
postmaster, but this is not what you are getting at.
Am 07. Apr, 2026 schw„tzte Markus Sch”nhaber so:
07.04.26, 18:29 +0100, Joe:
I'm fairly sure that neither the SMTP protocol nor exim in particular
distinguish cases in email addresses. I have a feeling I found this for
sure with exim4, but I've run it for so many years I can no longer
remember the details.
I don't know anything about exim, but the SMTP protocol defines the
local-part of an email address to be case-sensitive:
| The local-part of a mailbox MUST BE treated as case sensitive.
| Therefore, SMTP implementations MUST take care to preserve the case
| of mailbox local-parts. In particular, for some hosts, the user
| "smith" is different from the user "Smith". However, exploiting the
| case sensitivity of mailbox local-parts impedes interoperability and
| is discouraged. Mailbox domains follow normal DNS rules and are
| hence not case sensitive.
https://www.rfc-editor.org/rfc/rfc5321.html#section-2.4
Yes, officially local-part is case-sensitive, but in practicality it
should not be treated as case-sensitive.
I haven't looked at exim for a long time, but it should default to case-insensitive for delivery. I never had to change it, but that might
have been debian defaulting to useful configuration options. To comply
with the standard it should have to ability to be case-sensitive, but I'm
not going to complain if it doesn't.
In the end, it's up to the local mail administrator, but case-sensitive local-part is counter-productive.
Are you using any other tools in the delivery chain that might be doing something case-sensitive?
On Tue Apr 7, 2026 at 4:00 PM BST, Haines Brown wrote:
My current host name is not iskra but Iskra. The host ikra is a
different installation of the operating system on a different
drive. Pehaps I need to boot it, purge and reinstall Exim from it.
On Tue, Apr 07, 2026 at 15:18:47 -0400, Haines Brown wrote:
On Tue, Apr 07, 2026 at 01:46:03PM -0400, Greg Wooledge wrote:
Start by looking at which domains you've declared to be local.
Does this include both "histomat.net" and "iskra.histomat.net"?
Or just one of them? Or neither?
Is local domain name the same as what exim configuration calls
system mail name? In the field put Iskra@hstomatlnet. There is no
place for an additinoal domain name. Pehaps it can be provided in
answer to other distinations. Is that so? I usually leave blank.
I don't use exim myself, so I did a web search. <https://www.exim.org/exim-html-current/doc/html/spec_html/ch-domain_host_address_and_local_part_lists.html#SECTnamedlists>
appears to contain the documentation for this.
Thus, you might do something like
grep -r local_domains /etc/exim*
and see what pops up.
Next, look at how your "postmaster" is configured. Is it an alias?
Is it a real user? If it's an alias, what address does it point to?
Every week bendel sends me a bounce report and every one I've looked
at contains one of Haines' messages that has been bounced by my ISP.
But I've no way to know for sure that it's just Haines' messages that
are getting bounced.
So is there something strange in the way that Haines has his mail set
up such that it might provoke such a negative response by my ISP?
I'm fairly sure that neither the SMTP protocol nor exim in particular distinguish cases in email addresses.
By mistake I sent a message (mutt, fetchmail, exim) that was
missing a From: line in the header. As the result I'm deluged with
frozen messages.
I understand that the command # exiqgrep -z -i | xargs exim -Mrm
removed all frozen mail. It does so but the broken message
continues to be received.
I went to The "timeout_frozen_after" setting is in /etc/exim4/conf.d/main/02_exim4-config_options file and changed MAIN_TIMEOUT_FROZEN_AFTER = 7d to 1 hr. That had no effect.
I purged exim4 and deleted the /etc/exi4 directory. I removed mutt
and fetchmail but assume that was not necessary. I commended the
existing mail queue and let exim build another.
I rebooted and
rebuilt my mail system from scratch to no avail.
Hi,
On Tue, Apr 07, 2026 at 09:23:56PM +0100, debian-user@howorth.org.uk
wrote:
Every week bendel sends me a bounce report and every one I've looked
at contains one of Haines' messages that has been bounced by my ISP.
But I've no way to know for sure that it's just Haines' messages
that are getting bounced.
Presumably it is only the mails from Haines that your ESP rejects as otherwise bendel would report more to you.
So is there something strange in the way that Haines has his mail
set up such that it might provoke such a negative response by my
ISP?
Is there any clue in the report that bendel gives to you? Sometimes
the SMTP-time rejection does have useful information but a lot of the
time it will just be generic.
Of course even if you do establish what your ESP doesn't like about
bendel's forward of Haines' emails, there may well be nothing that you
or Haines can do about it. It may be something that Haines' ESP is
doing, or something that bendel is doing when it forwards the mail to
your ESP.
Thanks,
Andy
Exim configuration does not provide for identifying who is
postmaster.
Does it not?
$ grep -c /etc/aliases /var/lib/dpkg/info/exim4-config.config /var/lib/dpkg/info/exim4-config.postinst
/var/lib/dpkg/info/exim4-config.config:2
/var/lib/dpkg/info/exim4-config.postinst:8
$
I do create a /root/.forward file with my simple
address haines@histomat.net in it. I suppose that makes me
postmaster, but this is not what you are getting at.
Typically, aliases looks something like:
$ cat /etc/aliases
# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: root
root: foo
$
AIUI, foo would usually default to the first user (1000). The reason
for that last line is so that root doesn't have to run a mail client.
The postmaster file holds my two email addressses. I commented them,
but the frozen message continue.
It might help to post your /etc/exim4/update-exim4.conf.conf file
as some of your earlier answers didn't seem very clear (like the
domain names).
Cheers,
David.
Andy Smith <andy@strugglers.net> wrote:
Presumably it is only the mails from Haines that your ESP rejects as otherwise bendel would report more to you.
Well I have no way to know, because bendel just sends me one and
provides no way that I've found to look at any others. That's what I've
asked postmaster and listmaster about.
It's an ISP BTW (Internet Service Provider) not an ESP (whatever that
is).
Is there any clue in the report that bendel gives to you? Sometimes
the SMTP-time rejection does have useful information but a lot of the
time it will just be generic.
I don't know; I don't understand what you're suggesting. The current
bounce report is at
https://lists.debian.org/bounces/PvURBjegyGnI_lBY9zXJNA
Of course even if you do establish what your ESP doesn't like about bendel's forward of Haines' emails, there may well be nothing that you
or Haines can do about it. It may be something that Haines' ESP is
doing, or something that bendel is doing when it forwards the mail to
your ESP.
Well hopefully if I can figure out what the problem is I'll stand some
chance of persuading whoever/whatever is responsible to change what
they're doing to provoke the rejection.
On Tue, 7 Apr 2026 21:23:56 +0100
debian-user@howorth.org.uk wrote:
Hello debian-user@howorth.org.uk,
So is there something strange in the way that Haines has his mail set
up such that it might provoke such a negative response by my ISP?
I haven't been following closely, but yes, I would say so, given that
they're asking about just that on list.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
It's not your heart, it's your bank I want to break
It's Yer Money - Wonder Stuff
Hi,
On Wed, Apr 08, 2026 at 09:33:36AM +0100, debian-user@howorth.org.uk
wrote:
Andy Smith <andy@strugglers.net> wrote:
Presumably it is only the mails from Haines that your ESP rejects
as otherwise bendel would report more to you.
Well I have no way to know, because bendel just sends me one and
provides no way that I've found to look at any others. That's what
I've asked postmaster and listmaster about.
I think when this has happened to me before I have had a report about
each failed mail, so I think you are only missing the ones from
Haines.
It's an ISP BTW (Internet Service Provider) not an ESP (whatever
that is).
Email Service Provider. Whoever handles your email service. Which in
your case seems to actually be Zen.
Is there any clue in the report that bendel gives to you?
Sometimes the SMTP-time rejection does have useful information
but a lot of the time it will just be generic.
I don't know; I don't understand what you're suggesting. The current
bounce report is at
https://lists.debian.org/bounces/PvURBjegyGnI_lBY9zXJNA
This is the part I'm talking about:
<debian-user@howorth.org.uk>: host
mailcluster.zen.co.uk[212.23.3.121] said: 550-Your message has been
rejected as it appears to be SPAM/UCE. 550-It scored 15.5 spam
points. If we have erroneously blocked your 550-email, then please
accept our apologies and try again after rephrasing 550 your email
and checking your IP [82.195.75.100] on DNSBLs (in reply to end of
DATA command)
It is the SMTP error message from mailcluster.zen.co.uk when bendel
tried to deliver ones of Haines' mail to you.
Sadly it's not that helpful as it just means "we think this is spam"
without saying why.
You could try mailing postmaster@zen.co.uk showing them the link above
and try to get them to understand that it's them rejecting non-spam
email to you and could they find a way to allowlist it, but they
probably won't understand or ignore you or otherwise make it
difficult. It's probably only mails from Haines so maybe you don't
bother, but if bendel warns you about other rejected messages then it
could suggest a more serious problem of Zen not liking mails from
bendel.
Of course even if you do establish what your ESP doesn't like
about bendel's forward of Haines' emails, there may well be
nothing that you or Haines can do about it. It may be something
that Haines' ESP is doing, or something that bendel is doing when
it forwards the mail to your ESP.
Well hopefully if I can figure out what the problem is I'll stand
some chance of persuading whoever/whatever is responsible to change
what they're doing to provoke the rejection.
Zen are saying they think it';s spam but as theyre not saying why it's
hard to know if there is anything that Debian or Haines need to fix.
I'm in contact with Zen about this problem but with very limitedI think the odds of getting Zen to change *anything* are quite low but
evidence they haven't been able to solve the problem so far.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 493851:46:05 |
| Calls: | 146 |
| Files: | 547 |
| D/L today: |
6 files (97K bytes) |
| Messages: | 76,953 |