Subject: Re: Spam suggestion...
To: David Maxwell <firstname.lastname@example.org>
From: Greg A. Woods <email@example.com>
Date: 02/25/2004 15:36:12
[ On Monday, February 23, 2004 at 11:20:09 (-0500), David Maxwell wrote: ]
> Subject: Re: Spam suggestion...
> On Mon, Feb 23, 2004 at 05:22:51AM -0700, Herb Peyerl wrote:
> > > head is on the ball, here. Now, to get my mailer to recognise SPF
> > > properly
> > I'm told this won't work because lots of developers forge mail to
> > make it seem like they're sending from @netbsd.org but through their
> > own mail servers.
> > I confess I do this too but would be willing to give up this relatively
> > minor luxury if it were to decrease the amount of spam flying around.
> > However, not all developers feel this way.
> I think that developers should be convinced to adjust their behaviour.
No, they shouldn't.
It is _not_ "forgery" to use a different sender address than belongs to
the originating mail relay.
It is also not "forgery" to use a different sender address than is given
in the RFC 822 originator header(s).
These are standard and expected behaviours for RFC-822 e-mail sent
via SMTP, and often even the use of an alias or ~/.forward file will
have the same effect. These protocols were designed to work this way.
Remember that the SMTP envelope sender address has one and _only_ one
purpose: specifying the destination for non-delivery notifications.
The sender address must not be used for any other purpose, and that
includes any foolish attempts to detect forgeries.
It is merely a coicidence of convenience that major SMTP implementations
have commonly used the same sender address as is given in the RFC 822
headers. In many cases I think it would be "easier" for all involved if
the sender address for some domains was always <postmaster@domain> so
that a responsible and knowledgeable person could deal with bounces
instead of sending them to the clueless users.
(This is also why SPF is fundamentally flawed and why it breaks SMTP,
even with the added hacks of including sender address rewriting, and why
SPF will never succeed and reach "critical mass" even if some
heavy-weights like AOL try to force it through.)
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <firstname.lastname@example.org>
Planix, Inc. <email@example.com> Secrets of the Weird <firstname.lastname@example.org>