Thanks for catching me up. I am new to the list. Hopefully I don't retread
too much. Parts of this are re-hash. The ideas I think are "new" are in
points 3 and 4.
1. As you mentioned, more of a theoretical concern. This isn't a security
system per se.
2. DNS blacklists only prevent forging from domains that have it configured,
so those that "legitimately" forge email headers may continue to do so as
long as their domain's administrator allows it either by not configuring DNS
or by whitelisting *. At its worst, whitelisting the entire internet is the
same as what we have today. At its best, whitelisting only those servers
that send mail from your domain, it is a significant improvement.
Travelers should use other solutions such as reply-to headers, VPN
connections, SMTP after POP or SMTP authentication with their home servers.
Although I do feel that allowing just anyone to forge headers because it is
convenient is very bad form.
3. Mail users should be seeing this information. Some already do see it via
the "on behalf of" message and "SENDER" or "X-SENDER" headers. In my mail
server I have exposed the envelope from and envelope to addresses and found
it quite useful in rulemaking and the like.
In my mail server I add special warnings to messages sent with "must deliver"
rules. It wouldn't stop the message from being delivered but it would make
it more difficult to use SMTP frailties to impersonate users or the various
kinds of fraud as seen in spam messages.
4. The check on the "from" header should be optional and/or non-fatal and and
a "from" header that differs from the "mail from" envelope sender should be
noted and visible to the user.
I believe that with my additions that no user would see reduced functionality
except for those that want to send messages with a return address of a domain
they are not in charge of.
My biggest concerns are with the rampant fraudulent headers that are out
there. If a company is mailing from their own domain name at least they are
taking a minimum amount of responsibility and if you don't like it you can
block mail from their domain.
On Monday 17 March 2003 11:25 pm, wayne wrote:
In <200303171753(_dot_)59571(_at_)grx> David Walker
<antispam(_at_)grax(_dot_)com> writes:
My scheme for improving smtp and reducing abusive spams that contain fake
headers basically amounts to a per domain blacklist implemented in DNS.
Variations of these two solutions have been discussed extensively on
this mailing list.
See:
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00001.htm
l RMX records
(Yes, this was the very first message to this mailing list)
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00048.htm
l domain specific DNS blacklists (or whitelists)
https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00686.htm
l pros and cons of RMX (Re: [Asrg] Declaration to the world)
Summary:
1) DNS currently has certain security flaws that allow people to spoof
it and therefore let spammers get around these systems.
IMHO, this is more of a theoretical concern that a practical one.
Spammers haven't used these security flaws to spoof other DNSBLs,
and that would be a much bigger payoff for them.
2) Many people, especially those that travel a lot, like to be able to
"forge" email headers and such so that they can send email from
anywhere and make it look like it is coming from their home system.
IMHO, there are better solutions to this kind of problem, such as
SMTP AUTH or SMTP TLS, but there are a lot of people out there that
are "forging" email for legitimate reasons.
3) Checking the SMTP HELO and MAIL FROM domain information is only
mildly useful. End users generally don't see this envelope
information, and spammers can simply switch to RFC "MUST" deliver
domains such as the local host or <>.
4) Checking the mail from: header would break a lot of things like
mailing lists.
I think that per domain blacklists can be very easily implemented, as
I demonstrated in the third post I mentioned above. I am not,
however, convince that it would hinder spammers more than it would
hinder legitimate email users.
-wayne
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg