The recipient list is a pretty poor way to deal with things when you
get mail sent to multiple lists you're on, and often the To: line ends
up with nothing at all. The Return-Path: is generally the surest way
to know which of the lists each of the messages was sent to. I've
tried lots of
Perry,
Wednesday, October 30, 2002, 1:38:54 PM, you wrote:
Perry As I use Return-Path: headers to filter my mail, this has gotten
Perry annoying, Yes, I can indeed kludge around it, but is there a
Perry particular reason for this being done?
Using return-path is a bit like paying attention to
Dave Crocker wrote:
Using return-path is a bit like paying attention to what mailbox a postal
letter is dropped into.
Or perhaps what post offices it went through on the way.
--
/===\
|John Stracke |[EMAIL PROTECTED]
On 30 Oct 2002, Perry E. Metzger wrote:
Dave Crocker [EMAIL PROTECTED] writes:
Wednesday, October 30, 2002, 1:38:54 PM, you wrote:
Perry As I use Return-Path: headers to filter my mail, this has gotten
Perry annoying, Yes, I can indeed kludge around it, but is there a
Perry particular
There are now apparently TWO servers sending out ietf-announce mail,
with different envelope senders. This started happening today.
As I use Return-Path: headers to filter my mail, this has gotten
annoying, Yes, I can indeed kludge around it, but is there a
particular reason for this being done?
Dave Crocker [EMAIL PROTECTED] writes:
Wednesday, October 30, 2002, 1:38:54 PM, you wrote:
Perry As I use Return-Path: headers to filter my mail, this has gotten
Perry annoying, Yes, I can indeed kludge around it, but is there a
Perry particular reason for this being done?
Using
Dave Crocker [EMAIL PROTECTED] writes:
...
Using return-path is a bit like paying attention to what mailbox a postal
letter is dropped into.
That analogy is quite good, and cuts both ways. While you cannot
rely completely on envelope or header return addresses or postmarks,
in practice
ahem Or the IETF could simply start using its own Proposed Standard
mechanism described in RFC 2919.
--Paul Hoffman, Director
--Internet Mail Consortium
Vernon Schryver [EMAIL PROTECTED] writes:
I see no Return-Path headers in some IETF traffic, including
[EMAIL PROTECTED] as it appears in my mailbox.
Instead I see an old UNIX-style From_.
That's because Return-Path: is frequently added at final delivery. My
MTA adds that, some other don't.
In article [EMAIL PROTECTED] you write:
The recipient list is a pretty poor way to deal with things when you
get mail sent to multiple lists you're on, and often the To: line ends
up with nothing at all.
I filter on envelope recipient. This seems to work very well,
although it does cause
I see no Return-Path headers in some IETF traffic, including
[EMAIL PROTECTED] as it appears in my mailbox.
Instead I see an old UNIX-style From_.
That's because Return-Path: is frequently added at final delivery. My
MTA adds that, some other don't. (Many Unix MTAs use the From_ line).
The recipient list is a pretty poor way to deal with things when you
get mail sent to multiple lists you're on, and often the To: line ends
up with nothing at all.
I filter on envelope recipient. This seems to work very well,
although it does cause problems with certain obnoxious lists and
Keith Moore [EMAIL PROTECTED] writes:
Note that the ones that don't add return-path are in violation of
over 20+ years of mail specificatons. See RFC 821 (top of page 22),
RFC 1123 (section 5.3.3 among others), and RFC 2821 (section 4.4).
However there's no guarantee that Return-Path is
13 matches
Mail list logo
