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

Relevant Pages

  • Re: SMPT broken for about 19 years
    ... Remember the SPF only deals with RFC 821/2821. ... forwarding can no longer be tolerated. ... Forwarding the old way is a form of an open relay. ... The difference between RFC 821/2821 and RFC 822/2822. ...
    (comp.unix.sco.misc)
  • Re: SMPT broken for about 19 years
    ... Forwarding was broken by RFC 1123 5.3.6about 19 years ago. ... SPF doesn't work well with sites that "forward" email without the use of SRS to rewrite the "FROM" headers for bouncing email. ... which is that the "bounce" address for a message ... well integrated yet with major SMTP servers. ...
    (comp.unix.sco.misc)
  • Re: SMPT broken for about 19 years
    ... Forwarding was broken by RFC 1123 5.3.6about 19 years ago. ... If folks think it belongs here, cool, but it's not really an SCO specific issue. ... which is that the "bounce" address for a message ... well integrated yet with major SMTP servers. ...
    (comp.unix.sco.misc)
  • Re: Using Forwarders
    ... with DNS servers at different levels. ... it doesn't work well to use Forwarding ... >> actual recursion of the Internet namespace from the root down. ...
    (microsoft.public.windows.server.dns)
  • Re: Agent Forwarding Question for the list
    ... Most of the documentation I found suggests it's possible to do this, and I can already do it with ssh-3.2.9-1 on our old setup. ... I was determined to ask the experts in case it was a common mistake or something that simply is not possible under openssh. ... Say in the ideal setup for development servers I'd have a cronuser, scriptuser, monitoruser, cvsuser, and root all configured with my public key and that I could jump in and out of each not only from my own Linux Desktop, but through each user to each user on other servers in the development chain. ... After reading all the documentation and FAQs I could find, I had assumed ssh-agent on the desktop and agent forwarding on the servers would be sufficient, but something is blocking the forwarding, or I'm way off and this isn't how it's meant to work. ...
    (SSH)