Mike Yates <hctef(_at_)fonehelp(_dot_)co(_dot_)uk> writes:
Matthias Andree wrote:-
Your setup is inherently broken and cannot be fixed until the moment
where your provider stuffs one copy per recipient and keeps the original
envelope recipient into some header.
My first query included comments on the intractability of the ISP and
their software supplier. That is not an option.
If fetchmail had only never introduced Received line parsing.
Oh, no! Don't say that!
The parsing is great, just too fussy.
Does your service level agreement with your ISP include a guarantee that
they have the envelope recipient in the Received: header, always? What
happens if I Bcc the same mail to two users in your domain? Will the ISP
split this up and drop two mails into your mailbox, one with the first
Bcc:, the other with the second Bcc:? If not, multidrop will be
unreliable.
On all systems I've seen so far, more than one recipient in the same
domain made the envelope disappear from Received - and the mail end up
in the postmaster (or fallback or catchall) mailbox. The test you made
reached too short.
While we cannot control our ISPs and there seems no future hope of that
in the current geo-legal climate (corruption - hang Gates!) it is
essential that awful "workarounds" be facilitated, as long as they are
well documented and NOT the default, but configurable.
Fetchmail cannot recreate data that isn't there. And Received header
data has the nasty habit of disappearing when you need it the worst.
In any case RFC822 and its successors only make "X-envelope-to"
OPTIONAL.
Right. And they don't advertise POP3 or IMAP as suitable protocols for
transporting mail for a whole domain with multiple users.
What is needed here is a way of switching off the mailhost verification
for the "Received" line.
No. That would break your setup the day your ISP chose to insert an
additional machine that leaves Received: traces.
There is another, fully legitimate, reason (other than
server-clustering) why this could be necessary. My email to
<anybody>@fonehelp.co.uk is relayed on to my Blueyonder address by
kundenserver.de (oneandone.co.uk) and any bcc's only have their "for" in
a "Received" line from kundenserver, not blueyonder, my mailhost.
1. Check the "aka" option, it may help if you can obtain a full list of
servers in the load balancer's server pool.
2. Do not use "no dns", but use "dns" instead (default: dns)
3. Try the "checkalias" option, too.
Surely fetchmail should only be looking for a " for " in a "Received"
line?
Fetchmail first and foremost shouldn't look at a Received header at all.
It does, and for compatibility reasons, the next few versions will do so
to, but the feature should IMO be dropped
Surely there is only any need to verify that the "Received" line was
from the mailhost if there is more than one recognised local address
(after " for ") in the whole header?
That's usually the case.
mail.hatton.co.uk = 217.28.130.67
thmailsite4.services.byworkwise.com = 217.28.130.98
Probably an artifact of their DNS configuration.
No it is just server-clustering, where the " for " may have been
inserted by any of dozens of servers and the POP3 request may be handled
by another.
See (3.) above, it may help.
I see such regularly even on legitimate mail, but haven't bothered to
investigate. It's probably not worth it, and I'd suspect size
information on some POP3 servers to be off.
Well, then, there should be a configuration option to "accept mis-sized
mail", should there not?
fetchmail niggles but then accepts the mail.
--
Matthias Andree