🚀 go-pugleaf

Many thanks for you extremely informative, cogent and polite reply,
Phil, which I leave attached below for information.

It would appear, then, that Turnpike's much-vaunted "reject mail"
option, which was the main reason why I upgraded to version 3.04, is a
very damp squib, because it relies on everybody using return-path in
their emails.  Spammers will never do this, because it gives us too much
information on reporting them to their ISPs to get them thrown off.


In article <66r4l9$2es$1@hera.tcp.net.uk>, Phil Dye <pmd@tcp.net.uk>
writes
>In <WDbn2bAG4Pk0Ew6S@tcp.co.uk> Dave Swindell <dswindell@tcp.co.uk> writes:
>
>>In article <GBb+PnAHXSj0EAAr@turnpike.com>, Richard Clayton
>><richard@turnpike.com> writes
>>>In article <0z6vqDAdcPj0EwE7@tcp.co.uk>, Dave Swindell
>>><dswindell@tcp.co.uk> writes
>>>
>>>>Whenever I try to reject mail in version 3.04 it says I can't because
>>>>there is no return-path.  This even happens when I reject a test message
>>>>to myself.  Is there something wrong with my setup?
>>>
>>>your ISP is not putting enough information in the headers when it
>>>creates your POP3 mailbox contents. We are therefore unable to determine
>>>the SMTP return path.
>>>
>>>This is not a problem with Demon's standard conformant POP3 system :)
>>>
>>Is this true?  Does TCP not conform to the POP3 standard?
>
>I can assure you that there is nothing in our mail system that breaks
>the relevant RFC's, and everything that must be implemented has been.
>
>I fail to see how POP3 has anything to do with the writing of a mailbox.
>POP3 is purely a *mail download* protocol; it has nothing whatsoever
>to do with the format that a mailbox should be written in on the mail
>servers disk (which could be anything, so long as the POP server can read
>the file).
>
>Given that Turnpike and Demon are now one and the same, and Demon's
>tradition of not particularly adhering to standards, the phrase
>"Demon's standard conformant POP3 system" makes me chuckle a bit...
>For instance, they already use a few non-standard POP commands in
>their implementation to deal with their implementation of multiple mailboxes.
>
>Return-Path is an *optional* header that can be added by the receiving 
>mail server to indicate definitive information about the address and  
>route back to the message's originator (this is basically the same
>as the 'envelope from', which is as easily forged as the 'From:' address 
>anyway). 
>
>Although Return-Path was optional, and wasn't previously added by the
>server (mostly because it serves little use), I have changed the configuration
>to add it anyway.
>

Dave     dswindell.gerbil@tcp.co.uk
For email replies remove the gerbil