fetchmail bounces

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I haven't worried about these as yet, but it's time I look at some of the error messages and clean them up.

This is the scenario (RH9 all updates):

I use sendmail to send mail VIA my ISP mail server (masquerade).
I use fetchmail in a 15 minute CRON job to fetch new mail from my ISP mail server.


All mail for my sub domain gets dumped into one account on my ISP, where my mail system then distributes it once it hits my server (fetchmail multi-drop).

Lately I've been getting these:

----- Transcript of session follows -----
... while talking to mail.m.iinet.net.au.:

>>>>>> MAIL From:<FETCHMAIL-DAEMON@xxxxxxxxxxxxxxxxxxxxx>

<<< 553 sorry, your envelope sender domain must exist (#5.7.1)
501 5.6.0 Data format error
550 5.1.1 <FETCHMAIL-DAEMON@server>... User unknown

I THINK this is what happens when I get SPAM addressed to a wrong user name here locally (it only seems to happen with spam). Fetchmail while collecting from my ISP, will attempt to bounce the message. This used to work, but I think my ISP has become tighter with security, and now all domain senders must resolve (scary it didn't matter before hey?).

Anyway, while sending via sendmail, all my addresses (*@localhost) seem to be correctly masqueraded to *@my.resolvable.domain. However, it looks like when fetchmail bounces a message back via mail.m.iinet.net.au (my ISP mail server), it does NOT masquerade the domain, resulting in the ISP bouncing fetchmail bounces back to me with the above error.

The questions I have are thus:

1> Is this a sendmail, fetchmail or procmail setting that I can easily resolve?

2> Is there a way I can turn off the bounces with sendmail, fetchmail, or procmail settings PROVIDED this is netiquette? What I mean is turning of the bounces completely will obviously stop bounces back to legitimate people who may think they have a correct e-mail address at my sub domain, meaning they will never know they have things wrong. What is the correct procedure anyway? Bouncing non-existent users or not?

3> Any other ways to stop this happening?

More info easily available (config files etc.), but I'm not going to clog the list just yet.

Regards,
Ed.





--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux