On Sun, 2009-09-20 at 21:38 +0100, Mick wrote: > On Sunday 20 September 2009, Harry Putnam wrote: > > Mick <michaelkintz...@gmail.com> writes: > > > -----The following addresses had permanent fatal errors----- > > > <email_acco...@isp.com> > > > (reason: 550 5.1.0 <nag...@myserver.mydomain.com> sender rejected : > > > invalid sender domain) > > > > > > -----Transcript of session follows ----- > > > > > > ... while talking to smtp.ISP.com: > > >>>> MAIL From:<nag...@myserver.mydomain.com> SIZE=745 AUTH=<> > > > > > > <<< 550 5.1.0 <nag...@myserver.mydomain.com> sender rejected : invalid > > > sender domain > > > 554 5.0.0 Service unavailable > > > ================================================================ > > > > > > Does this fail because the ISP's reverse DNS on my dynamically allocated > > > IP address resolves to an ISP domain instead of myserver.mydomain.com? > > > > > > Is there something I could change in the configuration of my server to > > > make this work again? > > > > I think you might avoid the problem by making sendmail Impersonate your > > isps domain. > > > > Using some or all of these settings in sendmail.mc > > MASQUERADE_AS(`yourISP.domain')dnl > > MASQUERADE_DOMAIN(`youractual.domain')dnl > > FEATURE(masquerade_entire_domain)dnl > > FEATURE(masquerade_envelope)dnl > > Yes, that should fix the reverse DNS problem alright, but then people who > receive email notifications from myserver will be confused by the domain that > these messages are sent from. I don't know this sendmail feature, but I think sendmail should not modify your message, but just the envelop. So `youractual.domain' would still be in the "To"-header, while `yourISP.domain' is in the envelop. That should make your ISP happy, and no receiver will ever notice (except if they look at the headers), because MUAs only show the "To"-header :)
Your ISP could still check the "To"-header - but that would be just plain ugly... > I could also use the ISP's domain for my IP address in the server's > /etc/hosts > file - although it would have the same problem with regards to the domain > that messages are sent from.
