Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Andrew Church (achurch_at_achurch.org)
Date: Mon Jul 22 2002 - 22:39:13 CDT
I've written an Internet-Draft on this subject
(draft-church-dns-mail-sender-01.txt) that takes much the same approach,
but after discussion with others, allow/deny based on IP address doesn't
seem to be the best way to go about this. One example I was given is a
case where an employee sends mail through an MTA on his workstation; if the
employee has to go offsite, he suddenly becomes unable to send mail from
the company's domain normally unless he gets the DNS admin to add an entry
for his new address.
I'm planning to write a new version of the draft within the next week
or so that uses a challenge/response method, with the challenge stored in
the DNS entry and the response sent over SMTP (or something like that; I'm
still working on the details). If anyone is interested in receiving a copy
of the new draft when it is complete, please let me know.
>You bring up some good points.
>I believe that all email programs should display name and email address to
>reduce the chances of just the attack you describe.
>One of the issues bothering me is the fact that mail servers will accept what
>you tell them meaning that I can easily send mail pretending to be from any
>domain. I propose that a new type of dns entry be created for authorized
>outgoing mail servers. Mail servers will be able to discover if the IP
>address connected to them is authorized to send mail for that domain and
>either deny the message or add a warning to it.
>I wrote a brief paper describing 2 methods of doing this at
>and I would appreciate feedback on the ideas.
>If this solution were in place, forgers could not forge domains with the
>solution implemented and would be forced to use their own name or the name of
>some domain whose admin had not implemented this solution yet.
>On Wednesday 17 July 2002 03:19 pm, Intel Nop wrote:
>> (can I resubmit this, signed by the key for this email instead of the other
>> key I signed it with, thnx).
>> See below...
>> I don't know if this has been discussed on bugtraq before, but I just
>> thought it might be important to bring up. Noting Outlook Express
>> specifically, even 6, is vulnerable to certain Social Attacks and
>> interception/redirection of mail rather trivially, caused by non-disclosed
>> header/email information in the From: address box. Outlook 2000 and
>> previous versions, all have the same problem if viewed specifically from
>> the preview pane only, (I don't know the stats on how many view
>> specifically from the preview pane, but at my place of employment, it turns
>> out to be plenty). I'm not a Microsoft outlook expert, nor have I had the
>> time or effort to go and look for the cure, other than recommending to
>> enforce some openPGP or other form of digital signature system for the
>> business environment as to identify and confirm who you received mail from.
>> This attack is very simple, as someone can easily go get a free web-based
>> e-mail account and just know the name of the person they intend to
>> masquerade and send the email to the unknowing user to socially engineer
>> pertinent and possibly confidential information from the unknowing user, as
>> I notice, when hitting reply to user, it still does not disclose the email
>> address unless investigated further to the properties of the user name. Not
>> to mention, it is also rather trivial to forge email addresses, and still
>> contain a reply-address to the masquerading user who initiated the attack
>> as well. This is probably widely known, but maybe not taken as seriously as
>> it should be, and the use of One-way hash signatures for email
>> authentication would be highly recommended in general to the public, as
>> they do have certain software freely available that is quite trivial to use
>> and requires little knowledge to operate. The possibilities of this attack
>> are endless, and combined with a little social engineering, the level of
>> confidential information that could be obtained is alarming. We need to
>> have a rfc for Digital Trust on the Internet. Any takers to help establish
>> Anyway, my two cents for the day.
>> - --
>> People will do tomorrow what they did today because that is what they