ietf-smtp
[Top] [All Lists]

Re: CBV systems - was Re: SMTP Extensions - proper peply code for disabled commands

2004-01-14 20:33:58
On Wed, 14 Jan 2004 16:30:02 EST, Hector Santos 
<winserver(_dot_)support(_at_)winserver(_dot_)com>  said:

Return-path is intended for (non)delivery notification, not for sender
verification.  It is not reasonable to take return-path as an indicator
of sender identity.

Why not?  I believe the presumption is made in RFC 1123 and in RFC 2821 that
DNS and error reporting is to be returned to a "existing" return path.
Otherwise what is the point of using a Return-Path: header?

*exactly*.  Return-Path (which is derived from the 2821 MAIL FROM) says
*where to send the bounces*.  As such, it tells you almost nothing about who
actually *sent* it - consider that the mail I'm replying to would be considered
as being "sent" by either Hector Santos, or the ietf-smtp mailing list, 
depending
on your religion.  owner-ietf-smtp is where bounces go, not who the sender is.

I have a home-grown "probe for dead list owners" script for our Listserv system.
It sends mail with an RFC2822 From: of 
'postmaster(_at_)listserv(_dot_)vt(_dot_)edu', but the
2821 MAIL FROM: has 'dead-owners(_at_)listserv(_dot_)vt(_dot_)edu', which, not 
surprisingly
feeds into a Perl program that does the first-pass parsing of bounces for me.

Did dead-owners send the mail? No, it's just catching the bounces.

Attachment: pgpJkVh479V4g.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>