SMPT broken for about 19 years - SCO

This is a discussion on SMPT broken for about 19 years - SCO ; 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 ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: SMPT broken for about 19 years

  1. SMPT broken for about 19 years


    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.

    --
    Boyd Gerber
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  2. Re: SMPT broken for about 19 years

    On 5 Mar, 22:56, Boyd Lynn Gerber 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 backa
    > 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.

    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.

  3. Re: SMPT broken for about 19 years

    Nico Kadel-Garcia wrote:
    > On 5 Mar, 22:56, Boyd Lynn Gerber 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.

    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!).

    I posted a problem, Boyd responded. Boyd posted the message you
    responded to as additional information for clueless admin's (me)
    as to why SPF is important.

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

    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.

    --
    Steve Fabac
    S.M. Fabac & Associates
    816/765-1670

  4. Re: SMPT broken for about 19 years

    Steve M. Fabac, Jr. wrote:

    > Nico Kadel-Garcia wrote:


    >> On 5 Mar, 22:56, Boyd Lynn Gerber 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.

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



    When replying to someone else's post, I try to do at least one of these
    three things:

    * Use 'reply' rather than 'new message' so that my posting contains an
    NNTP "reference" header that points to the previous posting.

    * Use the prefix "Re:" in the subject and preferably some clue that will
    help folk locate the original thread.

    * In the body of the message, make some mention, no matter how vague, of
    the thread to which my message relates.

    I expect that when I do none of the above, and discuss something
    superficially unrelated to the newsgroup in which I post, some readers
    may understandably be puzzled.

    YMMV

  5. Rant about usenet and posting was Re: SMPT broken for about 19 years

    Now that I maintain the threading this will be barried inside it. It
    really should be a new post, but to satisfy you....

    On Fri, 7 Mar 2008, RedGrittyBrick wrote:
    > Steve M. Fabac, Jr. wrote:
    > > Nico Kadel-Garcia wrote:
    > > > On 5 Mar, 22:56, Boyd Lynn Gerber 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.
    > > >
    > > > 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.


    I was offended, but I considered the source. It was clear that a new
    topic was needed, to clarify the discussion. It is not very valuable to
    have to do a body search to get the information. Usenet really has
    changed. We now see topic driffting and no change of subject. Many news
    servers only keep things for 2 weeks. These marathon threads get articles
    dropped and when you read they have not substance. I started a new thread
    to clarify what was going on. The topic needed to be changed. It was
    sparked from the discussion.

    The problem is this now is driffting and has absolutly to do with the
    thread. See below. Topic has nothing to do with the subject.

    > When replying to someone else's post, I try to do at least one of these
    > three things:
    >
    > * Use 'reply' rather than 'new message' so that my posting contains an
    > NNTP "reference" header that points to the previous posting.


    But with threading and the topic is no longer applicable. It gets barried
    inside of a thread with no reference to the subject. A new thread should
    start so that the discussion is about the subject.

    > * Use the prefix "Re:" in the subject and preferably some clue that will
    > help folk locate the original thread.


    Yes as long as the discussion is about the orignal thread.

    > * In the body of the message, make some mention, no matter how vague, of
    > the thread to which my message relates.


    That is often a good practice, but when time is short we do not always
    follow good practice.

    > I expect that when I do none of the above, and discuss something
    > superficially unrelated to the newsgroup in which I post, some readers
    > may understandably be puzzled.


    But the tread had gone beyond the original subject. I started with a
    clear subject that when referenced to the newsgroup... Assumtions.

    1. This has something to do with SCO OS's or products. So therefore what
    in the SCO OS needed to be explained.

    (A) Sending email.

    2. Assumption something in SCO that may be broken.

    (A) SMTP.


    So topic is choosen on SMTP being broken on SCO and that I should give
    inforation on about how long. But being that what I am talking about is
    also an issue with other OS, for this discussion it is not applicable. I
    want to let people know that for SCO SMTP was broken about 19 years ago.
    If I want to talk about abuse on a larger scale yes I would go to those
    news groups, but given the SCO is the issue I do it here.

    Given the source that started this drifft, has a bone to pick with SCO and
    prefers to divert the subject. I will not go on more.


    --
    Boyd Gerber
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  6. Re: SMPT broken for about 19 years

    On Fri, 7 Mar 2008, Steve M. Fabac, Jr. wrote:
    > Nico Kadel-Garcia wrote:
    > > On 5 Mar, 22:56, Boyd Lynn Gerber 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.


    No it is not. The discussion is about SCO's SMPT being broken. It just
    happens that it applies to everyone. But the target is the SCO SMTP.

    > 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.
    >
    > 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!).
    >
    > I posted a problem, Boyd responded. Boyd posted the message you
    > responded to as additional information for clueless admin's (me)
    > as to why SPF is important.


    Thanks that was my intention. For SCO admins

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


    Agreed. The information was needed. I lacked time to really go in depth
    to the issue.

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


    Thanks,

    --
    Boyd Gerber
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  7. Re: SMPT broken for about 19 years

    Steve M. Fabac, Jr. wrote:
    > Nico Kadel-Garcia wrote:
    >> On 5 Mar, 22:56, Boyd Lynn Gerber 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?

  8. Re: SMPT broken for about 19 years

    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
    ZENEZ 1042 East Fort Union #135, Midvale Utah 84047

  9. Re: SMPT broken for about 19 years

    Nico Kadel-Garcia wrote:
    > Steve M. Fabac, Jr. wrote:
    >> Nico Kadel-Garcia wrote:
    >>> On 5 Mar, 22:56, Boyd Lynn Gerber 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.


    I respect your experience and effort you have put into this subject.
    I am not trying to solve the world's spam problem. Just trying to
    protect my domain from being blacklisted due to the abuse perpetrated
    by others in faking the From: tag in their spam.

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


    Granted. But again, I'm not trying to solve the world's spam problem.
    Just trying to contribute by automating reporting to the abuse@ e-mail
    for the ISP's where the spam is originating to identify the source
    IP and give them supporting documentation to build the case to terminate
    willful offenders or contact unsuspecting (clueless) home users with
    infected machines.

    As I take the steps to implement SPF in the DNS MX record and A
    record, we may see a falloff in bounced spam reaching my domain.
    Until then, I will continue submitting abuse reports to the
    responsible ISP's.

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


    Nope. Stock SCO with whatever sendmail is provided with the original
    OS installation and applied patches.

    This is really only applicable to small clients with low to medium
    e-mail requirements. I've a lot of mom & pop businesses with legacy
    accounting, accounting services (tax preparation), Law offices,
    warehousing, or POS applications. Most have had their SCO systems before
    the Internet was widely available. Over the years, we have replaced
    old hardware with newer hardware and upgraded older versions of
    SCO as needed.

    Along with the upgrades, I've moved them from dial-up access
    to their servers to SSH over the Internet and as a consequence of
    obtaining Internet connectivity, registered their domains and tasked
    the existing SCO server to handle low volume e-mail. These clients
    were commonly using some_name@aol.com for their e-mail and now have
    e-mail with their domain name.

    I install spamassassin, fetchmail and procmail and configure them as
    necessary to work on the client's system.

    In larger environments, the client usually has on-site windows administrators
    and have installed MS Exchange for e-mail. In those environments, I take
    care of the UNIX and stand back as the MS guys do what they want to do.
    I have one local city government client. They have one SCO UNIX box that
    services the court system (well, the police department has a Unixware server
    but I'm not involved with that box). The last time I was in their data center,
    I counted over 60 Windows servers.

    I've one law office where they were forced to move to E-mail service
    provided by ElectricMail to obtain the necessary policy controls
    on outgoing e-mail expeditiously to meet their client's required time
    frame.

    I live by the maxim: "you can't be all things to everyone." If it
    fits on UNIX, I do it. If not, I network with other independent
    consults to get the job done.


    --
    Steve Fabac
    S.M. Fabac & Associates
    816/765-1670

  10. Re: SMPT broken for about 19 years

    On Sat, Mar 08, 2008, Steve M. Fabac, Jr. wrote:
    ....
    >I respect your experience and effort you have put into this subject.
    >I am not trying to solve the world's spam problem. Just trying to
    >protect my domain from being blacklisted due to the abuse perpetrated
    >by others in faking the From: tag in their spam.


    If this is your goal, forget it!

    No competent/sane admin would *EVER* block a domain based on mail
    in From: or From headers as these are almost always bogus
    in spam messages. A competent abuse person will look at Received
    headers, checking IP addresses and domains, putting real trust
    only in those inserted by their own mail servers or their trusted
    MX servers which should deliver directly to the final MX.

    If you have mail servers that host mailing lists, and send out
    fairly large numbers of messages to AOL and similar major ISPs,
    they generally have feedback loops where one can notify the ISP
    of your legitimate servers, and they will notify you of spam
    complaints from their users. Notifications will obfuscate their
    user's e-mail addresses so one should user VERP or similar means
    that create headers with the recipient's e-mail address allowing
    you to remove the complainer from your list(s).

    The URL for AOL's feedback loop is:

    http://postmaster.aol.com/fbl/index.html

    Bill
    --
    INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    The meek shall inherit the Earth, the rest of us will go to the stars...
    -Dr. Isaac Asimov

  11. Re: SMPT broken for about 19 years

    Boyd Lynn Gerber wrote:

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


    "There is no forwarding problem that needs to be solved.", and "Forwarding the
    old way is a form of an open rela.". Hmm, that sounds like a problem that
    needs to be solved to *me*.

    Unfortunately, forwarding is a default procedure of every MTA (Mail Transfer
    Agent) worldwide. We can't just wave a wand and have it evaporate.

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


    I wan't at Madrid (sorty, typo, yes). I was involved in the discussions on the
    SPF mailing lists before that. Many of us, me included, warned Meng Wong *NOT*
    to go along with Microsoft's efforts to embrace, extend, and extinguish.

    And I admit, I've been cross-writing DomainKeys and SenderID for years. I did
    seem to be having typo problems when I wrote this note, and apologize for it.


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


    Oh, man, I tried doing such hand-modified versions. It's really awkward to
    maintain such hand-built add-ons, especially if the core utilities get
    incompatible updates. It's especially bad if the modified components get
    mis-integrated with security patches, which the weird mixture of component
    packaging of SCO OpenServer and Skunkware and other contributors contribute
    to. (Don't ge tme going on the update conflicts for glib and pthreads on
    OpenServer 5.0.x: I just went through that.)

  12. Re: SMPT broken for about 19 years

    Bill Campbell wrote:
    > On Sat, Mar 08, 2008, Steve M. Fabac, Jr. wrote:
    > ....
    >> I respect your experience and effort you have put into this subject.
    >> I am not trying to solve the world's spam problem. Just trying to
    >> protect my domain from being blacklisted due to the abuse perpetrated
    >> by others in faking the From: tag in their spam.

    >
    > If this is your goal, forget it!
    >
    > No competent/sane admin would *EVER* block a domain based on mail
    > in From: or From headers as these are almost always bogus
    > in spam messages. A competent abuse person will look at Received
    > headers, checking IP addresses and domains, putting real trust
    > only in those inserted by their own mail servers or their trusted
    > MX servers which should deliver directly to the final MX.


    Heh. I've previously blocked @aol.com and @hotmail.com for entire domains,
    effectively, to reduce spam by a noticeable percentage. It seems less useful
    today as the zombie mail senders worldwide have become a larger chunk of spam,
    but it was quite helpful for a while in a 50-person company and some smaller
    environments.

  13. Re: SMPT broken for about 19 years

    Bill Campbell wrote:
    > On Sat, Mar 08, 2008, Steve M. Fabac, Jr. wrote:
    > ....
    >> I respect your experience and effort you have put into this subject.
    >> I am not trying to solve the world's spam problem. Just trying to
    >> protect my domain from being blacklisted due to the abuse perpetrated
    >> by others in faking the From: tag in their spam.

    >
    > If this is your goal, forget it!
    >
    > No competent/sane admin would *EVER* block a domain based on mail
    > in From: or From headers as these are almost always bogus
    > in spam messages. A competent abuse person will look at Received
    > headers, checking IP addresses and domains, putting real trust
    > only in those inserted by their own mail servers or their trusted
    > MX servers which should deliver directly to the final MX.


    Heh. I've previously blocked @aol.com and @hotmail.com for entire domains,
    effectively, to reduce spam by a noticeable percentage. It seems less useful
    today as the zombie mail senders worldwide have become a larger chunk of spam,
    but it was quite helpful for a while in a 50-person company and some smaller
    environments.


  14. Re: SMPT broken for about 19 years

    Nico Kadel-Garcia wrote:
    > Boyd Lynn Gerber wrote:



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

    >
    > I wan't at Madrid (sorty, typo, yes). I was involved in the discussions
    > on the SPF mailing lists before that. Many of us, me included, warned
    > Meng Wong *NOT* to go along with Microsoft's efforts to embrace, extend,
    > and extinguish.


    Doublechecking, *THIS* was not a typo on my part. It was the MARID working
    group, http://en.wikipedia.org/wiki/MARID.

  15. Re: SMPT broken for about 19 years

    On Sun, Mar 09, 2008, Nico Kadel-Garcia wrote:
    >Bill Campbell wrote:
    >> On Sat, Mar 08, 2008, Steve M. Fabac, Jr. wrote:
    >> ....
    >>> I respect your experience and effort you have put into this subject.
    >>> I am not trying to solve the world's spam problem. Just trying to
    >>> protect my domain from being blacklisted due to the abuse perpetrated
    >>> by others in faking the From: tag in their spam.

    >>
    >> If this is your goal, forget it!
    >>
    >> No competent/sane admin would *EVER* block a domain based on mail
    >> in From: or From headers as these are almost always bogus
    >> in spam messages. A competent abuse person will look at Received
    >> headers, checking IP addresses and domains, putting real trust
    >> only in those inserted by their own mail servers or their trusted
    >> MX servers which should deliver directly to the final MX.

    >
    >Heh. I've previously blocked @aol.com and @hotmail.com for entire domains,
    >effectively, to reduce spam by a noticeable percentage. It seems less useful
    >today as the zombie mail senders worldwide have become a larger chunk of spam,
    >but it was quite helpful for a while in a 50-person company and some smaller
    >environments.


    I can't say anything nice about hotmail so I won't say anything
    about them. AOL on the other hand has been *VERY* active on the
    spam fighting front, even using its 800lb gorilla status to
    ``encourage'' some major broadband providers to take effective
    steps to limit spam from the broadband provider's networks.

    Granted AOL's priority it so limit spam to their customers, they
    seem to be far better at limiting their customer's use as drop
    boxes for spam and other scams than hotmail, yahoo, et al. They
    also are not in the habit of returning abuse reports with the
    ``it's not from our network'' crap as some of the other large
    freemail providers do.

    FWIW: I have no relationship with AOL beyond having our sites
    registered on their feedback loops, and have never had an AOL
    account other than an AIM account for those rare occasions when I
    use IM. One of my favorite Dilbert cartoons was the one where he
    said ``I can tell from your e-mail address that you're either a
    goat herder or a cartoonist''.

    Bill
    --
    INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    "The man who does not read good books has no advantage over the man who
    can't read them." -- Mark Twain

+ Reply to Thread