OK, I just got another bounce.  It's from frontiernet.net again.  So, 
the problem doesn't seem to have anything to do with the 
local-host-names file.

But, it seems to have something to do with the Helo.  Not sure how to 
even begin to troubleshoot this.  Don't know if it is Squeak, or 
something with the machine configuration itself.  Anybody have any 
ideas?  The boxes are Fedora Core 2, and the MTA is sendmail.

Nevin


> Thanks, Ken.  I'm not sure if it worked, though.
>
> The email server ('aServer' argument to AdHocComposition) is a 
> different machine than the machine that hosts Squeak.  The 
> /etc/mail/local-host-names file for the email machine seems proper 
> (with the proper entries), but the /etc/mail/local-host-names file for 
> the machine running Squeak had no entries.  I'm not sure if it needed 
> one (after all, why else would AdHocComposition want me to specify a 
> server?), but I added one anyway.  We'll see if I get any bounces now.
>
> So, we'll see.  Thanks again!
>
> Nevin
>
>
>> This is a common RedHat configuration problem, for example.  Most
>> servers don't complain but a server that sends out mail starting with
>>
>> ehlo localhost.localdomain
>>
>> or
>>
>> helo localhost.localdomain
>>
>> is actually making an error.  It should be sending it's own true
>> hostname (that supports reverse lookups that match the forward lookup).
>>
>> The best way to fix this, if I remember correctly, is to fix the
>> Sendmail configuration by ensuring that the first name listed
>> in /etc/mail/local-host-names is the proper name.  I believe this is the
>> name that sendmail will use for the 'helo' command.  There are other
>> ways to fix this also.
>>
>> Of course if neither RedHat nor Sendmail are involved here then it's
>> back to step one.  It would help to have a bit more detailed information
>> about the mail path.  A little testing with 'telnet <mail server> 25'
>> and manual SMTP can help diagnose this sort of thing.
>>
>> I hope this helps somewhat.
>>
>> Ken
>>
>> On Fri, 2005-11-25 at 11:17 -0700, Nevin Pratt wrote:
>>  
>>
>>> My application sends emails out (order confirmation emails, "out of
>>> stock" notification emails, "back in stock" notification emails,
>>> etc.).  I use the AdHocComposition class (in Squeak 3.5) thusly:
>>>
>>>   (AdHocComposition celeste: aServer initialText: aStream contents)
>>> submit
>>>
>>> where 'aServer' is usually set to my own mail.bountifulbaby.net email
>>> server, and 'aStream' of course has the message to be emailed.
>>>
>>> This used to work flawlessly, but now about one email out of about 200
>>> or so get bounced.  Here is a sample of the bounce message (but with
>>> "foo at frontiernet.net" instead of the real email address being sent to,
>>> for privacy reasons):
>>>
>>> The original message was received at Fri, 25 Nov 2005 01:57:00 -0700
>>> from bountifulbaby.com [166.70.210.67]
>>>
>>>   ----- The following addresses had permanent fatal errors -----
>>> <foo at frontiernet.net>
>>>    (reason: 554 <localhost.localdomain>: Helo command rejected: You 
>>> are not me. See http://postmaster.frontiernet.net. See 
>>> http://postmaster.frontiernet.net)
>>>
>>>   ----- Transcript of session follows -----
>>> ... while talking to mx.frontiernet.net.:
>>>   
>>>
>>>>>>>>> DATA
>>>>>>>>>               
>>>>>>>>
>>>>>>              
>>>>>
>>> <<< 554 <localhost.localdomain>: Helo command rejected: You are not 
>>> me. See http://postmaster.frontiernet.net. See 
>>> http://postmaster.frontiernet.net
>>> 554 5.0.0 Service unavailable
>>> <<< 554 Error: no valid recipients
>>> Sometimes the bounce message is a little different, saying something
>>> like
>>>     <localhost.localdomain> invalid MTA
>>>
>>> But even that message seems to be related to the same Squeak email
>>> configuration issue.
>>>
>>> I don't know a whole lot about email transport protocol, but basically
>>> it looks like a configuration issue with the AdHocComposition class,
>>> where it is inserting "localhost.localdomain" as the MTA in the "Helo"
>>> field of the message?  Or something like that-- I don't really know,
>>> nor do I understand it.
>>>
>>> Can anybody shed any light on this?
>>>
>>> Nevin
>>>
>>>   
>>
>
>