https://bugs.exim.org/show_bug.cgi?id=1885
--- Comment #2 from Thaddeus H. Black <thb@???> ---
Jeremy Harris writes:
> I'm not quite seeing what you think is a bug in Exim versus what turned
> out to be either a bug in your configuration or a problem with your
> systems for which you have to enforce workaround handling in your
> configuration. Can you be more specific?
Thank you for asking. A certain configuration does indeed seem to solve my
problem. Maybe your answer will be, "Then just use that configuration!" If
so, that's fine with me.
But maybe your answer will be, "Exim could have been made more straightforward
to configure in this instance."
When a third party like Debian has packaged and redistributed Exim, I
understand that you cannot always discern whether a user's problem is Exim's
bug, is the third party's bug, or is the user's error. This is why I reported
my problem to Marc Haber of the Debian Project first. After considering, Marc
was not sure, but felt that you might be interested, so I escalate the report
to your attention on Marc's advice.
Exim handles the mail on both my laptop and my relay host. Postfix is not
involved. Before hours of trial and error discovered the secret to tune my
configuration, here was the chain of events:
[1] Exim on my laptop tried to authenticate itself (STARTTLS/plain) to Exim on
my relay server. Usually this worked, but sometimes, sporadically, the
authentication either failed or was never tried.
[2] Whenever [1] did not work, Exim on my laptop fell back to try
unauthenticated relay.
[3] Exim on my relay server, of course, is configured to refuse unauthenicated
relay.
[4] Unfortunately, the result of [3] was a permanent, unrecoverable error 550
on the laptop's end. The 5xx error was gratuitous. It was not necessary. My
laptop only needed to retry transmission; but, with a 5xx error, retry was
impossible. (One of the solutions I considered was to add 5xx error handling
to my copy of Exim's source and to recompile for local use, but this felt
wrong, so I did not actually try it.)
[5] Incidentally, my relay server (as default-configured) had been trying to
relay outward through a nonexistent IPv6 interface. I do not know whether this
was relevant to my particular problem, but Rui F. Ribeiro did make some rather
interesting remarks in the matter. I have earlier linked his remarks in case
you wish to read them.
I am inclined to agree with you that this is probably a configuration issue.
Indeed, as mentioned in point [4], while investigating the problem, I unpacked
your source and studied the 4xx error code (which is clear and easy to read, by
the way); but decided in the end that modifying the source probably was not the
best way to handle this. Still, you know so much more about the code than I
do. It seemed wise to give you the information and let you decide.
If this is indeed a configuration issue, though, then the question is whether
the problem is best ascribed to user misunderstanding, to infelicity in
Debian's default configuration, or to infelicity in your own, original default
configuration.
Consider: my use case is pretty simple. Its sole nonstandard feature that I
know is the lack of an IPv6 interface. It just seems to me that my use case
should have been easier to configure. A 10-year Debian Developer but not an
experienced mail administrator, I am reasonably agile with configurations and
fairly perseverant in efforts to figure things out on my own. I can read and
understand RFCs 2821 and 2822, and so on. Eventually, I did figure this
problem out on my own, or rather with some kind help from Mr. Ribeiro, as you
see.
Of course, this could just be a foolish misunderstanding on my part. Have I
just invented a hard solution while overlooking an easy one?
(I do not have access to my actual configuration at this instant, but if you
ask for it, I will append it within the next several days.)
--
You are receiving this mail because:
You are on the CC list for the bug.
