Re: SMPT broken for about 19 years
- From: "Steve M. Fabac, Jr." <smfabac@xxxxxxx>
- Date: Sat, 08 Mar 2008 14:21:19 -0600
Nico Kadel-Garcia wrote:
Steve M. Fabac, Jr. wrote:Nico Kadel-Garcia wrote:On 5 Mar, 22:56, Boyd Lynn Gerber <gerb...@xxxxxxxxx> 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 theAnd your post is interesting as well. It could have stood alone without
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.
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@xxxxxxx 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
.
- Follow-Ups:
- Re: SMPT broken for about 19 years
- From: Bill Campbell
- Re: SMPT broken for about 19 years
- References:
- SMPT broken for about 19 years
- From: Boyd Lynn Gerber
- Re: SMPT broken for about 19 years
- From: Nico Kadel-Garcia
- Re: SMPT broken for about 19 years
- From: Steve M. Fabac, Jr.
- Re: SMPT broken for about 19 years
- From: Nico Kadel-Garcia
- SMPT broken for about 19 years
- Prev by Date: Re: Remote Control a terminal or the console.
- Next by Date: Re: SMPT broken for about 19 years
- Previous by thread: Re: SMPT broken for about 19 years
- Next by thread: Re: SMPT broken for about 19 years
- Index(es):
Relevant Pages
|