>>> Then its misconfigured and misworded..
>> its worded as i want it worded...

 RC>   And how was it worded?  I'm curious about what all the fuss is about...

it was a simple SMTP 551 errorcode with the following text...

 551 Go to hell spammer... Your mail is garbage!

it was worded that way because the only mail that address received that
didn't come from elistin was spam... i refined my "filters"
somewhat and somehow elistin didn't clear them and thus that code and
denial of connection were sent... thom's system, when it got that
errorcode, created an email message to him with the contents of that
errorcode... he never asked me if there was a problem... he immediately
jumped to the wrong conclusion(s) and attitude... my attempts at discussing
the situation as gentlemen brought the conversation into the ELIST echo
from Z1C... sadly, we've still yet to work the situation out... at least
from my standpoint... much the same way as we've never worked out the
problem with sending echoarea rules files without them getting the wrong
filename and being truncated... i've finally figured out the truncation
problem is on his end and has to do with his software's detection of a
tearline... the filename problem is something else and while there is
supposedly a solution available, it doesn't work for my updates via email
because i do not allow attachments thru the gateway and thus they get
blocked...


that 551 code has since been reworded as the following for those accounts
that get mail from one source and no other...

 551 The destination address accepts mail from only one source.



>>there was a SMTP 551 code sent back... that's a flat
>> out denial of connectivity at the SMTP server level...

 RC>   According to what I found, that means as follows:

 RC>  551 User not local; please try 


where'd you find that? here is the information that i have at hand from the
GIGOSMTP stuff...

===== snip =====

Those already familiar with GIGO's MAPPING.CFG (which specifies the
newsgroupechotag mapping for gated news) will notice a similarity
to SMTPD.OK's formula.  The format of a filter is as follows:

    action hostname sender recipient errorcode errormsg

Each of these fields may be separated by one or more spaces or tabs.
The 'errormessage' field starts at the word in that position and
continues until the end of the line.

action     This is one of '+', '-' or '=' (without the single
           quotes.

           +  Explicitly allows the session, unless any subsequent
              matching lines disallow it.

           -  Explicitly disallows the session, unless any
              subsequent matching lines disallow it.

           =  Explicitly disallows any session matching this line
              (no further matching is done).

hostname   This is the host name of the remote system. This is a
           WILDCARD field, where the asterisk character matches
           none, one or more characters.

sender     This is the sender's email address, again a WILDCARD
           field.

recipient  This is the recipient's email address, also a WILDCARD
           field.

errorcode  This is the SMTPD error number.  Unless you are familiar
           with the SMTP standard, you should use "550" or "551".

errormsg   This is a text string that is sent to the remote system
           when the errorcode rejects the session.

Note that a line 'matches' on a particular host, sender, recipient
combination if it matches ALL of the fields, not just one. A single
asterisk (*) in a field matches any entry for that field.

The errorcode and errormsg fields are only required (and used) in
a "reject" match; that is, any line commencing with either '=' or
'-'.

===== snip =====

see? there's nothing there that indicates /exactly/ what a 550 or 551 are
spec'd to be... i'll be looking into that as soon as my pipeline frees up a
bit more...


i've also pretty much decided that GIGO's SMTP stuff only works with domain
names and not ip numbers :(  that may be why the responses were blocked and
this whole mess started...

 RC>   I gather that that the text of the message is a little
 RC> different when coming from your system?


>> his own system generated those emails he is complaining about..

 RC>    In response to messages from yours, right?  That, at least, is how I
 RC> understand it...

not a /message/ from mine... an errorcode with text...

)\/(ark