On Sat, 8 Mar 2008, Nico Kadel-Garcia wrote:
> > I take offense at your chastising Boyd for this post. I believe that
> > it was in response to my original post looking for help in resolving
> > the originating IP address's ISP and abuse@ values automatically in
> > the large number of bounced spam I have been receiving to my domain.
>
> Sorry, I didn't mean to chastise him for this. It's just that I don't
> reasonably expect an OS based newsgroup to have the experience and
> expertise in this particular subject that the network abuse newsgroups
> do. It's a fairly sophisticated topic, and one in which I've been
> involved since the original Canter&Siegel Usenet spams, and over which
> my wife and I had our first date.
>
> > Boyd pointed out the use of SPF of which I have been ignorant and I am
> > looking at now as a means to remedy my problem. (Thanks again Boyd!).
>
> And this is something the network abuse groups would have more expertise
> on. For example, SPF doesn't work well with sites that "forward" email
> without the use of SRS to rewrite the "FROM" headers for bouncing email.
> If folks consider it worthwhile, I was involved with SPF integration
> efforts quite early on, and would happily share that. I'm concerned that
> casual mention of it won't reveal the craziness that Microsoft has been
> doing to it with their "embrace and extend" policy and mislabeling their
> "SenderID" settings as SPF 1.

This is a bit wrong. There really is no Forwarding problem that needs to
be solved. Remember the SPF only deals with RFC 821/2821. The old mail
forwarding can no longer be tolerated. It is the same as having an open
relay. Open Relays are dead, or should be. The same with general
forwarding. Forwarding the old way is a form of an open relay. There is
not way to prevent forgery. SPF works on Mail From, sender ID works on
From. The difference between RFC 821/2821 and RFC 822/2822. SRS is just
one way to stop the forgery on forwarded mail. If the forwarder rewrites
the header to be from him then SRS is not needed. The email really his
from system, this system is acting as an open relay if it does not take
ownership of the Mail From. And as such has to change.

> It's worth a longer discussion with a more experienced group. If folks
> think it belongs here, cool, but it's not really an SCO specific issue.

Agreed.

> Well, thank you. I used to be active in the SPF discussion groups, and
> was hopping mad when its creator (Meng Wong) made his mistaken
> collaboration with Microsoft to extend it to include DomainKeys: this
> actually poisoned the attempts to get SPF supported added as an official
> standard at a meeting at Marid, due to Microsoft's patent encumbrances
> involving SenderID. The result is that Sendmail developers and Postfix
> developers refused to include it as a default component of their
> software, so it remains as an add-on utility, rather than built-in.

So your were also part of MADRID. About 6-8 months after MADRID was
closed, Meng worked with MS to give SenderID a backing of him. I too did
not like it. But SenderID is not DomainKeys! They are two different
methods of protecting the RFC 822/2822 From. MS has nothing to do with
Domain Keys.

> > As an SCO admin, administering our own SCO servers and client's SCO
> > servers, my interest is in anything impacting our machines. I welcome
> > Boyd's contributions to this news group and look forward to reading
> > anything he takes the time to post as relevant to SCO users.
>
> I'm actually startled if you're using SCO servers as your external mail
> servers. Given the awkwardness of package updates and lag time of
> updating open source components such as sendmail, unless you're building
> your own, it would seem difficult to keep SCO servers up-to-date with
> such features. Or are you suggesting you would run hand-installed
> versions of Sendmail or Postfix on such servers?

I do for the reasons given above. I prefer the milter concept. Keeps
thins modular.


--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047