🚀 go-pugleaf

In article <34C48959.41C6@amc.de>, Chris Croughton <crough45@amc.de>
writes

[of mail relaying via post.demon.co.uk]

>Having monitored the session, what happens is:
>
>MAIL FROM:<fred@bloggs.org>
>
>and then post either does nothing or responds with some
>kind of "nameserver lookup timout" (presumably for the
>'from' address).

"451 Nameserver timeout during parsing" I expect

RFC readers will know that this behaviour is wrong :( but regulars will
know that MMDF is not the best MTA ever :(. That said, this should not
be happening - some logs of the failures would be useful. The best place
to send details of_this_particular_fault! would be postmaster@demon.net.

>This seems to be a recent change in the behaviour of post.dcu,
>possibly related to the "anti-spam" changes.  Whatever it is,
>the result is that (a) my account is useless and (b) it has
>been costing me quite a bit of money trying to send perfectly
>valid mail.

I am reliably informed that it will be nothing to do with the anti-spam
changes (which were made in October), but investigating it is of
interest (if you can produce the logs - see above).

>I have 4 options:

[snip]

You could also join the "testers" group, which would then allow you to
use post.eng.mail.net, which runs a different MTA which could give you
less problems -- different reporting arrangements exist for problems
there, which is why joining the official group is important.

-- 
richard                       writing to inform and not as company policy
        http://www.happyday.demon.co.uk/ reviews the DTI crypto proposals
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM

On Tuesday, in article <QA+FmmBrVLx0EADc@turnpike.com>
     richard@turnpike.com "Richard Clayton" wrote:

RC> In article <34C48959.41C6@amc.de>, Chris Croughton <crough45@amc.de>
RC> writes
RC> 
RC> [of mail relaying via post.demon.co.uk]
RC> 
RC> >Having monitored the session, what happens is:
RC> >
RC> >MAIL FROM:<fred@bloggs.org>
RC> >
RC> >and then post either does nothing or responds with some
RC> >kind of "nameserver lookup timout" (presumably for the
RC> >'from' address).
RC> 
RC> "451 Nameserver timeout during parsing" I expect
RC> 
RC> RFC readers will know that this behaviour is wrong :( but regulars will
RC> know that MMDF is not the best MTA ever :(. That said, this should not
RC> be happening - some logs of the failures would be useful. The best place
RC> to send details of_this_particular_fault! would be postmaster@demon.net.

    I've been seeing this for some weeks now on messages 
    forwarded to a small group via my ka9q incoming mail alias 
    file, using the % hack to go via post.d.c.u.  But being 
    attended sessions, I simply reset the socket and kick mail 
    again, after which it usually goes through without any 
    problems.  
    
    Usually, there's just no response from post to the "MAIL 
    FROM", however long I wait.  But very occasionally, I see a 
    series of timeout errors giving what appear to my ignorant 
    eyes as nonsense IP addresses.  These go on almost 
    indefinitely, though I usually reset the socket before too 
    long.  Here's the tail end of one such series which I 
    captured using Win95's cut/paste:
    
        smtp recv: Querying server (# 152) address = 0.1.65.8 
        smtp recv: timeout                                    
        smtp recv: Querying server (# 153) address = 0.0.0.0  
        smtp recv: timeout                                    
        smtp recv: Querying server (# 154) address = 0.0.0.0  
        smtp recv: timeout                                    
                                                              
   I have ka9q's smtp trace set to 3; would a higher level 
   provide more useful information?   And where are its reports 
   logged, if at all?  
   

-- 

_____________________________________________________________________
Shakib Otaqui                                         Al-Quds Consult

Richard Clayton wrote:

> "451 Nameserver timeout during parsing" I expect

That's the animal.  I can't verify the number, but I remember the
wording
(as it flashed by - only 25 lines and the message scrolled off too fast 
to capture).

> RFC readers will know that this behaviour is wrong :( but regulars will
> know that MMDF is not the best MTA ever :(. That said, this should not
> be happening - some logs of the failures would be useful. The best place
> to send details of_this_particular_fault! would be postmaster@demon.net.

OK, thanks.

> I am reliably informed that it will be nothing to do with the anti-spam
> changes (which were made in October), but investigating it is of
> interest (if you can produce the logs - see above).

Logs are a problem - I'm not there to do them, and (as far as I can
tell)
KA9Q doesn't log the SMTP traces.  Of course, I can modify the sources
and recompile with special traces in, but that will take quite a time...

I can try to do a special login from here (Germany) to get logs.

> You could also join the "testers" group, which would then allow you to
> use post.eng.mail.net, which runs a different MTA which could give you
> less problems -- different reporting arrangements exist for problems
> there, which is why joining the official group is important.

How do I do that?

Thanks,
    Chris C

Earlier, Chris Croughton <crough45@amc.de> wrote:
> > You could also join the "testers" group, which would then allow you to
> > use post.eng.mail.net, which runs a different MTA which could give you
> > less problems -- different reporting arrangements exist for problems
> > there, which is why joining the official group is important.
> 
> How do I do that?

Have a look at http://www.demon.net/external/testers/

-Dom
-- 
This posting does not represent the opinion of Demon Internet.
---- Work: hdm@demon.net ---- Play: dom@myrddin.demon.co.uk ----
"What's this?  Is this an ICEPICK IN MY FOREHEAD?  Why yes,  I think it
 is!" -- JZ