🚀 go-pugleaf

In article <FtjD9FAlsRk0MwLc@tcp.co.uk>, Dave Swindell
<dswindell.gerbil@tcp.co.uk> writes

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

I trust that Phil will be happy to see his private email on Usenet

>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.

Some spammers fail to set (or forge) return paths for various reasons,
mainly concerned with avoiding the processing load of handling
rejections. However, the "received" lines are the actual key to
determining who they are - the return path is irrelevant.

However the issue was actually to do with tcp.co.uk failing to add a
return path header into the email delivered to you by POP3

>In article <66r4l9$2es$1@hera.tcp.net.uk>, Phil Dye <pmd@tcp.net.uk>
>writes

>>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.

this is incorrect as stated :(

RFC1123 5.2.8 makes it clear that an SMTP server making final delivery
"MUST" record the MAIL FROM information (ie create a Return Path
header). Clearly placing the mail into a POP3 mailbox is final delivery
(otherwise all sorts of other issues would arise). 

>>I fail to see how POP3 has anything to do with the writing of a mailbox.

it hasn't really - the software at fault here was the SMTP server which
had not discharged its obligations as the email left the SMTP domain and
entered the world of POP3

>>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,

perhaps Phil would not like his mail on Usenet after all :-(

Doubtless he has a specific issue in mind. I don't understand what he
can be on about.

> 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.

These extension commands do not make the system non-compliant with
RFC1939. There is nothing in 1939 which states that it is improper to
add extra commands - and all the commands which the standard requires to
be present are indeed present.

>>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.

This is excellent news - in the jargon of 1123 (1.3.2) you have moved
one step closer to being "unconditionally compliant"

-- 
richard                      richard.clayton    @    T U R N P I K E .com
                                                     tel: +44 1306 732300
"Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM