> Hi Bruce,
>
> it's not fetchmail losing mail, but Exim rejecting it.
It's Exim that rejects the email, but it's fetchmail that loses the email
by deleting it from the pop3 mailbox when fetchmail knows it hasn't
successfully passed it on to Exim.
>
> If fetchmail made up addresses, that in itself would constitute data
> corruption, i. e. a grave bug. I'm not going to introduce grave bugs to
> bypass configuration issues in other software.
> So that's not going to happen.
I've taken a look at the code and fetchmail already makes up addresses
to ensure the SMTP server accepts an email. This is the block of code
in file sink.c in function open_smtp_sink() that preceeds the call to
SMTP_from. It handles the cases where
1) you don't have a return address.
2) the return address is @
3) the return address is @domain
4) the return address is a name without @domain.
It doesn't handle my case of
*) the return address is a name with @ but no domain.
In cases 1 to 3 the address it makes up is the address of the pop3 mailbox
from which it fetched the email. In case 4 the address is the name
provided followed by @ and the pop3 server.
>
> Fetchmail also cannot make up addresses since it would then have to find
> SOME domain where the mail originated from and inevitably misattribute
> the mail origin - but how? {fetchmail,[EMAIL PROTECTED] is not
> the origin and I refuse to pretend the message originated locally.
> Your mail log hints to the broken messages being spam, and you
> definitely do not want spam misattributed to some other domain, but not
> any other mail either.
>
> That's the second reason why it's not going to happen.
This is a misattribute but it does get the email delivered. You may not
agree with it but I think that the most important thing it to get email
delivered and fetchmail it correct in doing the misattribute it does.
I've patched fetchmail so that it now also uses the address of the pop3
mailbox for name with @ but no domain. See attached file.
> Keeping the message is not an option either since you want fetched
> messages flushed and there is no way fetchmail can ever make progress
> and discarding it is the right way.
No. I only want delivered messages flushed.
I think keeping the message may be possible. When using a multi-drop
pop3 mailbox does keep mail for uses where there are temporary failures
whilst delivering mail to other users. However, I don't want this; I want
the message delivered.
> This behaviour however contradicts documentation, so there are open bug
> reports:
> - <https://bugzilla.novell.com/show_bug.cgi?id=246829>
> - <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471283>
>
> So the solution alternatives are:
>
> 1 - make exim accept such mail at least from localhost and/or via local
> loopback interface
I did look to see if this was possible. I didn't see a way so have instead
patched fetchmail.
>
> 2 - use an MDA and bypass Exim and all the filtering it might do.
I haven't looked to see if this is possible.
*** sink.c.000 2008-08-12 14:51:57.000000000 +0100
--- sink.c 2008-08-12 15:26:37.000000000 +0100
*************** static int open_smtp_sink(struct query *
*** 872,878 ****
* Also, if the hostname is a dotted quad, wrap it in square brackets.
* Apparently this is required by RFC2821, section 4.1.3.
*/
! if (!msg->return_path[0] || (msg->return_path[0] == '@'))
{
if (strchr(ctl->remotename,'@') || strchr(ctl->remotename,'!'))
{
--- 872,878 ----
* Also, if the hostname is a dotted quad, wrap it in square brackets.
* Apparently this is required by RFC2821, section 4.1.3.
*/
! if (!msg->return_path[0] || (msg->return_path[0] == '@') ||
(msg->return_path[strlen(msg->return_path)-1] == '@'))
{
if (strchr(ctl->remotename,'@') || strchr(ctl->remotename,'!'))
{
