Steve M. Fabac, Jr. wrote:
> Nico Kadel-Garcia wrote:
>> On 5 Mar, 22:56, Boyd Lynn Gerber <gerb...@zenez.com> wrote:
>>> After RFC 821 was mutilated by RFC 1123 email could be forged.
>>> Forwarding was broken by RFC 1123 5.3.6(a) about 19 years ago. The
>>> spammers figured it out about seven years ago. The concept of
>>> "forwarding" as it was known before RFC 1123 5.3.6(a) does not work any
>>> more, "forwarding" is now a part of the problem, like open relays.
>>>
>>> Because people want to forward email and the ability to track them was
>>> removed. People now can and do forge email. It has become a major
>>> problem just like open relays. Something has to change. SPF put back a
>>> way to tell if an email was forged.
>>
>> This is the wrong newsgroup for this topic, op on ove to the network
>> abuse discussion groups for this topic.
>
> 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.

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.

>> And there are some usable technologies to actually handle the
>> forwarding problem, which is that the "bounce" address for a message
>> does not get reset by the forwarding server to bounce back to the
>> forwarding server itself, which should then pass it back to the
>> message submitter. The result is that no one can easily tell the
>> difference between a forwarded message and a faked one with a
>> different "bounce" address, inundating the rest of us with the bounced
>> spam.
>>
>> There are technologies to store a registry of incoming email, encode
>> the "bounce" address going out, and allow the forwarding server to
>> decode the bounce message and get it back to the recipient. It's not
>> well integrated yet with major SMTP servers.
>>
>>
> And your post is interesting as well. It could have stood alone without
> the recommendation to move the discussion to another news group.

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.

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